mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Guide - transaction updates
Minor reference update Some Bitcoin -> Dash conversions in translation yml
This commit is contained in:
parent
c7b46ef228
commit
3d26a3b490
4 changed files with 50 additions and 54 deletions
|
@ -19,28 +19,28 @@ various ways the outputs/inputs are used, such as "prevout", "nextout",
|
||||||
when I'm terribly bored, I should rewrite this whole transaction section
|
when I'm terribly bored, I should rewrite this whole transaction section
|
||||||
to use those terms and then get feedback to see if it actually helps. -harding -->
|
to use those terms and then get feedback to see if it actually helps. -harding -->
|
||||||
|
|
||||||
Transactions let users spend satoshis. Each transaction is constructed
|
Transactions let users spend duffs. Each transaction is constructed
|
||||||
out of several parts which enable both simple direct payments and complex
|
out of several parts which enable both simple direct payments and complex
|
||||||
transactions. This section will describe each part and
|
transactions. This section will describe each part and
|
||||||
demonstrate how to use them together to build complete transactions.
|
demonstrate how to use them together to build complete transactions.
|
||||||
|
|
||||||
To keep things simple, this section pretends coinbase transactions do
|
To keep things simple, this section pretends coinbase transactions do
|
||||||
not exist. Coinbase transactions can only be created by Bitcoin miners
|
not exist. Coinbase transactions can only be created by Dash miners
|
||||||
and they're an exception to many of the rules listed below. Instead of
|
and they're an exception to many of the rules listed below. Instead of
|
||||||
pointing out the coinbase exception to each rule, we invite you to read
|
pointing out the coinbase exception to each rule, we invite you to read
|
||||||
about coinbase transactions in the block chain section of this guide.
|
about coinbase transactions in the block chain section of this guide.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The figure above shows the main parts of a Bitcoin transaction. Each
|
The figure above shows the main parts of a Dash transaction. Each
|
||||||
transaction has at least one input and one output. Each [input][/en/glossary/input]{:#term-input}{:.term} spends the
|
transaction has at least one input and one output. Each [input][/en/glossary/input]{:#term-input}{:.term} spends the
|
||||||
satoshis paid to a previous output. Each [output][/en/glossary/output]{:#term-output}{:.term} then waits as an Unspent
|
duffs paid to a previous output. Each [output][/en/glossary/output]{:#term-output}{:.term} then waits as an Unspent
|
||||||
Transaction Output (UTXO) until a later input spends it. When your
|
Transaction Output (UTXO) until a later input spends it. When your
|
||||||
Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really
|
Dash wallet tells you that you have a 10,000 duff balance, it really
|
||||||
means that you have 10,000 satoshis waiting in one or more UTXOs.
|
means that you have 10,000 duffs waiting in one or more UTXOs.
|
||||||
|
|
||||||
Each transaction is prefixed by a four-byte [transaction version number][]{:#term-transaction-version-number}{:.term} which tells
|
Each transaction is prefixed by a four-byte [transaction version number][]{:#term-transaction-version-number}{:.term} which tells
|
||||||
Bitcoin peers and miners which set of rules to use to validate it. This
|
Dash peers and miners which set of rules to use to validate it. This
|
||||||
lets developers create new rules for future transactions without
|
lets developers create new rules for future transactions without
|
||||||
invalidating previous transactions.
|
invalidating previous transactions.
|
||||||
|
|
||||||
|
@ -48,9 +48,9 @@ invalidating previous transactions.
|
||||||
|
|
||||||
An output has an implied index number based on its location in the
|
An output has an implied index number based on its location in the
|
||||||
transaction---the first output is output zero. The output also has an
|
transaction---the first output is output zero. The output also has an
|
||||||
amount in satoshis which it pays to a conditional pubkey script. Anyone
|
amount in duffs which it pays to a conditional pubkey script. Anyone
|
||||||
who can satisfy the conditions of that pubkey script can spend up to the
|
who can satisfy the conditions of that pubkey script can spend up to the
|
||||||
amount of satoshis paid to it.
|
amount of duffs paid to it.
|
||||||
|
|
||||||
An input uses a transaction identifier (txid) and an output index number
|
An input uses a transaction identifier (txid) and an output index number
|
||||||
(often called "vout" for output vector) to identify a particular output to
|
(often called "vout" for output vector) to identify a particular output to
|
||||||
|
@ -63,14 +63,14 @@ The figures below help illustrate how these features are used by
|
||||||
showing the workflow Alice uses to send Bob a transaction and which Bob
|
showing the workflow Alice uses to send Bob a transaction and which Bob
|
||||||
later uses to spend that transaction. Both Alice and Bob will use the
|
later uses to spend that transaction. Both Alice and Bob will use the
|
||||||
most common form of the standard Pay-To-Public-Key-Hash (P2PKH) transaction
|
most common form of the standard Pay-To-Public-Key-Hash (P2PKH) transaction
|
||||||
type. [P2PKH][/en/glossary/p2pkh-address]{:#term-p2pkh}{:.term} lets Alice spend satoshis to a typical Bitcoin address,
|
type. [P2PKH][/en/glossary/p2pkh-address]{:#term-p2pkh}{:.term} lets Alice spend duffs to a typical Dash address,
|
||||||
and then lets Bob further spend those satoshis using a simple
|
and then lets Bob further spend those duffs using a simple
|
||||||
cryptographic key pair.
|
cryptographic key pair.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the
|
Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the
|
||||||
first transaction. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with
|
first transaction. Dash uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with
|
||||||
the secp256k1 curve; secp256k1 [private keys][/en/glossary/private-key]{:#term-private-key}{:.term} are 256 bits of random
|
the secp256k1 curve; secp256k1 [private keys][/en/glossary/private-key]{:#term-private-key}{:.term} are 256 bits of random
|
||||||
data. A copy of that data is deterministically transformed into an secp256k1 [public
|
data. A copy of that data is deterministically transformed into an secp256k1 [public
|
||||||
key][/en/glossary/public-key]{:#term-public-key}{:.term}. Because the transformation can be reliably repeated later, the
|
key][/en/glossary/public-key]{:#term-public-key}{:.term}. Because the transformation can be reliably repeated later, the
|
||||||
|
@ -89,12 +89,12 @@ different states of a public key and to help the text better match the
|
||||||
space-constrained diagrams where "public-key hash" wouldn't fit. -harding -->
|
space-constrained diagrams where "public-key hash" wouldn't fit. -harding -->
|
||||||
|
|
||||||
Bob provides the pubkey hash to Alice. Pubkey hashes are almost always
|
Bob provides the pubkey hash to Alice. Pubkey hashes are almost always
|
||||||
sent encoded as Bitcoin [addresses][/en/glossary/address]{:#term-address}{:.term}, which are base58-encoded strings
|
sent encoded as Dash [addresses][/en/glossary/address]{:#term-address}{:.term}, which are base58-encoded strings
|
||||||
containing an address version number, the hash, and an error-detection
|
containing an address version number, the hash, and an error-detection
|
||||||
checksum to catch typos. The address can be transmitted
|
checksum to catch typos. The address can be transmitted
|
||||||
through any medium, including one-way mediums which prevent the spender
|
through any medium, including one-way mediums which prevent the spender
|
||||||
from communicating with the receiver, and it can be further encoded
|
from communicating with the receiver, and it can be further encoded
|
||||||
into another format, such as a QR code containing a `bitcoin:`
|
into another format, such as a QR code containing a `dash:`
|
||||||
URI.
|
URI.
|
||||||
|
|
||||||
Once Alice has the address and decodes it back into a standard hash, she
|
Once Alice has the address and decodes it back into a standard hash, she
|
||||||
|
@ -143,13 +143,13 @@ broadcast them over the peer-to-peer network.
|
||||||
As illustrated in the figure above, the data Bob signs includes the
|
As illustrated in the figure above, the data Bob signs includes the
|
||||||
txid and output index of the previous transaction, the previous
|
txid and output index of the previous transaction, the previous
|
||||||
output's pubkey script, the pubkey script Bob creates which will let the next
|
output's pubkey script, the pubkey script Bob creates which will let the next
|
||||||
recipient spend this transaction's output, and the amount of satoshis to
|
recipient spend this transaction's output, and the amount of duffs to
|
||||||
spend to the next recipient. In essence, the entire transaction is
|
spend to the next recipient. In essence, the entire transaction is
|
||||||
signed except for any signature scripts, which hold the full public keys and
|
signed except for any signature scripts, which hold the full public keys and
|
||||||
secp256k1 signatures.
|
secp256k1 signatures.
|
||||||
|
|
||||||
After putting his signature and public key in the signature script, Bob
|
After putting his signature and public key in the signature script, Bob
|
||||||
broadcasts the transaction to Bitcoin miners through the peer-to-peer
|
broadcasts the transaction to Dash miners through the peer-to-peer
|
||||||
network. Each peer and miner independently validates the transaction
|
network. Each peer and miner independently validates the transaction
|
||||||
before broadcasting it further or attempting to include it in a new block of
|
before broadcasting it further or attempting to include it in a new block of
|
||||||
transactions.
|
transactions.
|
||||||
|
@ -257,7 +257,7 @@ Pubkey scripts are created by spenders who have little interest what
|
||||||
that script does. Receivers do care about the script conditions and, if
|
that script does. Receivers do care about the script conditions and, if
|
||||||
they want, they can ask spenders to use a particular pubkey script.
|
they want, they can ask spenders to use a particular pubkey script.
|
||||||
Unfortunately, custom pubkey scripts are less convenient than short
|
Unfortunately, custom pubkey scripts are less convenient than short
|
||||||
Bitcoin addresses and there was no standard way to communicate them
|
Dash addresses and there was no standard way to communicate them
|
||||||
between programs prior to widespread implementation of the BIP70 Payment
|
between programs prior to widespread implementation of the BIP70 Payment
|
||||||
Protocol discussed later.
|
Protocol discussed later.
|
||||||
|
|
||||||
|
@ -285,7 +285,7 @@ Bob spend the output if the redeem script does not return false.
|
||||||

|

|
||||||
|
|
||||||
The hash of the redeem script has the same properties as a pubkey
|
The hash of the redeem script has the same properties as a pubkey
|
||||||
hash---so it can be transformed into the standard Bitcoin address format
|
hash---so it can be transformed into the standard Dash address format
|
||||||
with only one small change to differentiate it from a standard address.
|
with only one small change to differentiate it from a standard address.
|
||||||
This makes collecting a P2SH-style address as simple as collecting a
|
This makes collecting a P2SH-style address as simple as collecting a
|
||||||
P2PKH-style address. The hash also obfuscates any public keys in the
|
P2PKH-style address. The hash also obfuscates any public keys in the
|
||||||
|
@ -307,11 +307,11 @@ is the `IsStandard()` test, and transactions which pass it are called
|
||||||
standard transactions.
|
standard transactions.
|
||||||
|
|
||||||
Non-standard transactions---those that fail the test---may be accepted
|
Non-standard transactions---those that fail the test---may be accepted
|
||||||
by nodes not using the default Bitcoin Core settings. If they are
|
by nodes not using the default Dash Core settings. If they are
|
||||||
included in blocks, they will also avoid the IsStandard test and be
|
included in blocks, they will also avoid the IsStandard test and be
|
||||||
processed.
|
processed.
|
||||||
|
|
||||||
Besides making it more difficult for someone to attack Bitcoin for
|
Besides making it more difficult for someone to attack Dash for
|
||||||
free by broadcasting harmful transactions, the standard transaction
|
free by broadcasting harmful transactions, the standard transaction
|
||||||
test also helps prevent users from creating transactions today that
|
test also helps prevent users from creating transactions today that
|
||||||
would make adding new transaction features in the future more
|
would make adding new transaction features in the future more
|
||||||
|
@ -321,7 +321,7 @@ number, it would become useless as a tool for introducing
|
||||||
backwards-incompatible features.
|
backwards-incompatible features.
|
||||||
|
|
||||||
|
|
||||||
As of Bitcoin Core 0.9, the standard pubkey script types are:
|
As of Dash Core 0.12.2, the standard pubkey script types are:
|
||||||
|
|
||||||
{% endautocrossref %}
|
{% endautocrossref %}
|
||||||
|
|
||||||
|
@ -332,7 +332,7 @@ As of Bitcoin Core 0.9, the standard pubkey script types are:
|
||||||
{% autocrossref %}
|
{% autocrossref %}
|
||||||
|
|
||||||
P2PKH is the most common form of pubkey script used to send a transaction to one
|
P2PKH is the most common form of pubkey script used to send a transaction to one
|
||||||
or multiple Bitcoin addresses.
|
or multiple Dash addresses.
|
||||||
|
|
||||||
{% endautocrossref %}
|
{% endautocrossref %}
|
||||||
|
|
||||||
|
@ -439,9 +439,9 @@ Consensus rules allow null data outputs up to the maximum allowed pubkey
|
||||||
script size of 10,000 bytes provided they follow all other consensus
|
script size of 10,000 bytes provided they follow all other consensus
|
||||||
rules, such as not having any data pushes larger than 520 bytes.
|
rules, such as not having any data pushes larger than 520 bytes.
|
||||||
|
|
||||||
Bitcoin Core 0.9.x to 0.10.x will, by default, relay and mine null data
|
Dash Core 0.11.x will, by default, relay and mine null data
|
||||||
transactions with up to 40 bytes in a single data push and only one null
|
transactions with up to 40 bytes in a single data push and only one null
|
||||||
data output that pays exactly 0 satoshis:
|
data output that pays exactly 0 duffs:
|
||||||
|
|
||||||
{% endautocrossref %}
|
{% endautocrossref %}
|
||||||
|
|
||||||
|
@ -450,16 +450,13 @@ Pubkey Script: OP_RETURN <0 to 40 bytes of data>
|
||||||
(Null data scripts cannot be spent, so there's no signature script.)
|
(Null data scripts cannot be spent, so there's no signature script.)
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
Bitcoin Core 0.11.x increases this default to 80 bytes, with the other
|
Dash Core 0.12.1 defaults
|
||||||
rules remaining the same.
|
|
||||||
|
|
||||||
Bitcoin Core 0.12.0 defaults
|
|
||||||
to relaying and mining null data outputs with up to 83 bytes with any
|
to relaying and mining null data outputs with up to 83 bytes with any
|
||||||
number of data pushes, provided the total byte limit is not exceeded.
|
number of data pushes, provided the total byte limit is not exceeded.
|
||||||
There must still only be a single null data output and it must still pay
|
There must still only be a single null data output and it must still pay
|
||||||
exactly 0 satoshis.
|
exactly 0 duffs.
|
||||||
|
|
||||||
The `-datacarriersize` Bitcoin Core configuration option allows you to
|
The `-datacarriersize` Dash Core configuration option allows you to
|
||||||
set the maximum number of bytes in null data outputs that you will relay
|
set the maximum number of bytes in null data outputs that you will relay
|
||||||
or mine.
|
or mine.
|
||||||
|
|
||||||
|
@ -469,7 +466,7 @@ or mine.
|
||||||
{% autocrossref %}
|
{% autocrossref %}
|
||||||
|
|
||||||
If you use anything besides a standard pubkey script in an output, peers
|
If you use anything besides a standard pubkey script in an output, peers
|
||||||
and miners using the default Bitcoin Core settings will neither
|
and miners using the default Dash Core settings will neither
|
||||||
accept, broadcast, nor mine your transaction. When you try to broadcast
|
accept, broadcast, nor mine your transaction. When you try to broadcast
|
||||||
your transaction to a peer running the default settings, you will
|
your transaction to a peer running the default settings, you will
|
||||||
receive an error.
|
receive an error.
|
||||||
|
@ -485,10 +482,9 @@ that don't follow the standard mempool policy.
|
||||||
|
|
||||||
Note: standard transactions are designed to protect and help the
|
Note: standard transactions are designed to protect and help the
|
||||||
network, not prevent you from making mistakes. It's easy to create
|
network, not prevent you from making mistakes. It's easy to create
|
||||||
standard transactions which make the satoshis sent to them unspendable.
|
standard transactions which make the duffs sent to them unspendable.
|
||||||
|
|
||||||
As of Bitcoin Core 0.9.3, standard transactions must also meet the following
|
Standard transactions must also meet the following conditions:
|
||||||
conditions:
|
|
||||||
|
|
||||||
* The transaction must be finalized: either its locktime must be in the
|
* The transaction must be finalized: either its locktime must be in the
|
||||||
past (or less than or equal to the current block height), or all of its sequence
|
past (or less than or equal to the current block height), or all of its sequence
|
||||||
|
@ -511,9 +507,9 @@ conditions:
|
||||||
|
|
||||||
* The transaction must not include any outputs which receive fewer than
|
* The transaction must not include any outputs which receive fewer than
|
||||||
1/3 as many satoshis as it would take to spend it in a typical input.
|
1/3 as many satoshis as it would take to spend it in a typical input.
|
||||||
That's [currently 546 satoshis][bitcoin core fee drop commit] for a
|
That's currently 5460 duffs for a
|
||||||
P2PKH or P2SH output on a Bitcoin Core node with the default relay fee.
|
P2PKH or P2SH output on a Dash Core node with the default relay fee.
|
||||||
Exception: standard null data outputs must receive zero satoshis.
|
Exception: standard null data outputs must receive zero duffs.
|
||||||
|
|
||||||
{% endautocrossref %}
|
{% endautocrossref %}
|
||||||
|
|
||||||
|
|
|
@ -68,7 +68,7 @@ As of Dash Core 0.12.2.0, the most recent protocol version is 70208.
|
||||||
| Version | Initial Release | Major Changes
|
| Version | Initial Release | Major Changes
|
||||||
|---------|------------------------------------|--------------
|
|---------|------------------------------------|--------------
|
||||||
| 70208 | Dash Core 0.12.2.x <br>(Nov 2017) | • DIP-0001 (2MB blocks)<br>• Fee reduction (10x)<br>• InstantSend fix<br>• PrivateSend improvements<br>• _Experimental_ HD wallet
|
| 70208 | Dash Core 0.12.2.x <br>(Nov 2017) | • DIP-0001 (2MB blocks)<br>• Fee reduction (10x)<br>• InstantSend fix<br>• PrivateSend improvements<br>• _Experimental_ HD wallet
|
||||||
| 70206 | Dash Core 0.12.1.x <br>(Mar 2017) | • BIP-0065 (CheckLockTimeVerify)<br>• BIP-0112 (CheckSequenceVerify)
|
| 70206 | Dash Core 0.12.1.x <br>(Mar 2017) | • Switch to Bitcoin Core 0.12.1<br>• BIP-0065 (CheckLockTimeVerify)<br>• BIP-0112 (CheckSequenceVerify)
|
||||||
| 70103 | Dash Core 0.12.0.x <br>(Aug 2015) | • Switch to Bitcoin Core 0.10<br>• Decentralized budget system<br>• New IX implementation
|
| 70103 | Dash Core 0.12.0.x <br>(Aug 2015) | • Switch to Bitcoin Core 0.10<br>• Decentralized budget system<br>• New IX implementation
|
||||||
| 70076 | Dash Core 0.11.2.x <br>(Mar 2015) | • Masternode enhancements<br>• Mining/relay policy enhancements<br>• BIP-66 - strict DER encoding for signatures
|
| 70076 | Dash Core 0.11.2.x <br>(Mar 2015) | • Masternode enhancements<br>• Mining/relay policy enhancements<br>• BIP-66 - strict DER encoding for signatures
|
||||||
| 70066 | Dash Core 0.11.1.x <br>(Feb 2015) | • InstantX fully implemented<br>• Spork fully implemented<br>• Masternode payment updates<br>• Rebrand to Dash (0.11.1.26)
|
| 70066 | Dash Core 0.11.1.x <br>(Feb 2015) | • InstantX fully implemented<br>• Spork fully implemented<br>• Masternode payment updates<br>• Rebrand to Dash (0.11.1.26)
|
||||||
|
|
|
@ -27,7 +27,7 @@ http://opensource.org/licenses/MIT.
|
||||||
{% when "bcc help" %}<a href="/en/bitcoin-core/help">Help</a>
|
{% when "bcc help" %}<a href="/en/bitcoin-core/help">Help</a>
|
||||||
{% when "bcc news" %}<a href="/en/version-history">News</a>
|
{% when "bcc news" %}<a href="/en/version-history">News</a>
|
||||||
{% when "bitcoin" %}<a href="/{{page.lang}}/">{% translate bitcoin vocabulary %}</a>
|
{% when "bitcoin" %}<a href="/{{page.lang}}/">{% translate bitcoin vocabulary %}</a>
|
||||||
{% when "dev docs" %}<a href="/en/developer-documentation">Dev Docs</a>
|
{% when "dev docs" %}<a href="/en/developer-documentation">Developer Documentation</a>
|
||||||
{% when "glossary" %}<a href="/en/developer-glossary">Glossary</a>
|
{% when "glossary" %}<a href="/en/developer-glossary">Glossary</a>
|
||||||
{% else %}{% die "Breadcrumb not found in _includes/layout/breadcrumbs.html" %}
|
{% else %}{% die "Breadcrumb not found in _includes/layout/breadcrumbs.html" %}
|
||||||
{% endcase %}
|
{% endcase %}
|
||||||
|
|
|
@ -62,23 +62,23 @@ en:
|
||||||
transparency: "Accounting transparency"
|
transparency: "Accounting transparency"
|
||||||
transparencytext: "Many organizations are required to produce accounting documents about their activity. Using Bitcoin allows you to offer the highest level of transparency since you can provide information your members can use to verify your balances and transactions. Non-profit organizations can also allow the public to see how much they receive in donations."
|
transparencytext: "Many organizations are required to produce accounting documents about their activity. Using Bitcoin allows you to offer the highest level of transparency since you can provide information your members can use to verify your balances and transactions. Non-profit organizations can also allow the public to see how much they receive in donations."
|
||||||
bitcoin-for-developers:
|
bitcoin-for-developers:
|
||||||
title: "Bitcoin for Developers - Bitcoin"
|
title: "Dash for Developers - Dash"
|
||||||
pagetitle: "Bitcoin for Developers"
|
pagetitle: "Dash for Developers"
|
||||||
summary: "Bitcoin can be used to build amazing things or just answer common needs."
|
summary: "Dash can be used to build amazing things or just answer common needs."
|
||||||
simple: "The simplest of all payment systems"
|
simple: "The simplest of all payment systems"
|
||||||
simpletext: "Unless payment needs to be associated with automatic invoices, accepting money is as simple as sending a bitcoin: link or displaying a QR code. This simple setup is within reach of any user and can fulfill the needs of a good range of clients. When done publicly, it is especially suitable for transparent donations and tips."
|
simpletext: "Unless payment needs to be associated with automatic invoices, accepting money is as simple as sending Dash: link or displaying a QR code. This simple setup is within reach of any user and can fulfill the needs of a good range of clients. When done publicly, it is especially suitable for transparent donations and tips."
|
||||||
api: "Many third party APIs"
|
api: "Many third party APIs"
|
||||||
apitext: "There are many third party payment processing services that provide APIs; you don't need to store bitcoins on your server and handle the security that this implies. Additionally, most of these APIs allow you to process invoices and exchange your bitcoins into your local currency at competitive costs."
|
apitext: "There are many third party payment processing services that provide APIs; you don't need to store Dash on your server and handle the security that this implies. Additionally, most of these APIs allow you to process invoices and exchange your Dash into your local currency at competitive costs."
|
||||||
own: "You can be your own financial system"
|
own: "You can be your own financial system"
|
||||||
owntext: >
|
owntext: >
|
||||||
If you don't use any third party APIs, you can integrate a Bitcoin
|
If you don't use any third party APIs, you can integrate a Dash
|
||||||
node directly into your applications, allowing you to become your
|
node directly into your applications, allowing you to become your
|
||||||
own bank and payment processor. With all the responsibilities that
|
own bank and payment processor. With all the responsibilities that
|
||||||
this implies, you can build amazing systems that process Bitcoin
|
this implies, you can build amazing systems that process Dash
|
||||||
transactions however you would like.
|
transactions however you would like.
|
||||||
|
|
||||||
invoice: "Bitcoin addresses to track invoices"
|
invoice: "Dash addresses to track invoices"
|
||||||
invoicetext: "Bitcoin creates a unique address for each transaction. So if you were to build a payment system associated with an invoice, you simply need to generate and monitor a Bitcoin address for each payment. You should never use the same address for more than one transaction."
|
invoicetext: "Dash creates a unique address for each transaction. So if you were to build a payment system associated with an invoice, you simply need to generate and monitor a Dash address for each payment. You should never use the same address for more than one transaction."
|
||||||
security: "Most of the security is on client side"
|
security: "Most of the security is on client side"
|
||||||
securitytext: >
|
securitytext: >
|
||||||
Most security is handled by the protocol, eliminating the need for
|
Most security is handled by the protocol, eliminating the need for
|
||||||
|
@ -86,13 +86,13 @@ en:
|
||||||
monitoring a single variable: the <a
|
monitoring a single variable: the <a
|
||||||
href="#you-need-to-know##instant">confirmation score</a>. Beyond
|
href="#you-need-to-know##instant">confirmation score</a>. Beyond
|
||||||
that, keeping
|
that, keeping
|
||||||
your bitcoins secure is mainly a matter of <a
|
your Dash secure is mainly a matter of <a
|
||||||
href="#secure-your-wallet#">securing your wallet</a> and using
|
href="#secure-your-wallet#">securing your wallet</a> and using
|
||||||
HTTPS or other secure protocols to send payment requests to customers.
|
HTTPS or other secure protocols to send payment requests to customers.
|
||||||
|
|
||||||
micro: "New payment possibilities"
|
micro: "New payment possibilities"
|
||||||
microtext: >
|
microtext: >
|
||||||
Bitcoin allows you to design new and creative online services
|
Dash allows you to design new and creative online services
|
||||||
that couldn't exist before because of financial limitations. This
|
that couldn't exist before because of financial limitations. This
|
||||||
includes tipping systems, automated payment solutions,
|
includes tipping systems, automated payment solutions,
|
||||||
distributed crowd-funding services, time locked payment
|
distributed crowd-funding services, time locked payment
|
||||||
|
@ -588,12 +588,12 @@ en:
|
||||||
readmoretxt: "This is only a very short and concise summary of the system. If you want to get into the details, you can <a href=\"#bitcoin-paper#\">read the original paper</a> that describes the system's design, read the <a href=\"/en/developer-documentation\">developer documentation</a>, and explore the <a href=\"https://en.bitcoin.it/wiki/Main_Page\">Bitcoin wiki</a>."
|
readmoretxt: "This is only a very short and concise summary of the system. If you want to get into the details, you can <a href=\"#bitcoin-paper#\">read the original paper</a> that describes the system's design, read the <a href=\"/en/developer-documentation\">developer documentation</a>, and explore the <a href=\"https://en.bitcoin.it/wiki/Main_Page\">Bitcoin wiki</a>."
|
||||||
index:
|
index:
|
||||||
title: "Dash - Open source P2P money"
|
title: "Dash - Open source P2P money"
|
||||||
metadescription: "Bitcoin is an innovative payment network and a new kind of money. Find all you need to know and get started with Bitcoin on bitcoin.org."
|
metadescription: "Dash is an innovative payment network and a new kind of money. Find all you need to know and get started with Dash on dash.org."
|
||||||
listintro: "Bitcoin is an innovative payment network and a new kind of money."
|
listintro: "Dash is an innovative payment network and a new kind of money."
|
||||||
list1: "Fast peer-to-peer<br>transactions"
|
list1: "Fast peer-to-peer<br>transactions"
|
||||||
list2: "Worldwide<br>payments"
|
list2: "Worldwide<br>payments"
|
||||||
list3: "Low<br>processing fees"
|
list3: "Low<br>processing fees"
|
||||||
desc: "Bitcoin uses peer-to-peer technology to operate with no central authority or banks; managing transactions and the issuing of bitcoins is carried out collectively by the network. <b>Bitcoin is open-source; its design is public, nobody owns or controls Bitcoin and <a href=\"#support-bitcoin#\">everyone can take part</a></b>. Through many of its unique properties, Bitcoin allows exciting uses that could not be covered by any previous payment system."
|
desc: "Dash uses peer-to-peer technology to operate with no central authority or banks; managing transactions and the issuing of Dash is carried out collectively by the network. <b>Dash is open-source; its design is public, nobody owns or controls Dash and <a href=\"#support-bitcoin#\">everyone can take part</a></b>. Through many of its unique properties, Dash allows exciting uses that could not be covered by any previous payment system."
|
||||||
overview: "Or get a quick overview for"
|
overview: "Or get a quick overview for"
|
||||||
innovation:
|
innovation:
|
||||||
title: "Innovation - Bitcoin"
|
title: "Innovation - Bitcoin"
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue