mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Minor layout reorg
This commit is contained in:
thephez
parent
07cd97f08c
commit
c119e2fc14
3 changed files with 66 additions and 60 deletions
|
|
@ -8,6 +8,8 @@ http://opensource.org/licenses/MIT.
|
|||
{% include helpers/subhead-links.md %}
|
||||
|
||||
{% autocrossref %}
|
||||
<!-- __ -->
|
||||
<!-- https://dashpay.atlassian.net/wiki/spaces/DOC/pages/86278547/Dash+Payment+Processor-->
|
||||
|
||||
Payment processing encompasses the steps spenders and receivers perform
|
||||
to make and accept payments in exchange for products or services. The
|
||||
|
|
@ -285,12 +287,12 @@ bitcoin:mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN\
|
|||
None of the parameters provided above, except `r`, are required for the
|
||||
payment protocol---but your applications may include them for backwards
|
||||
compatibility with wallet programs which don't yet handle the payment
|
||||
protocol.
|
||||
protocol.
|
||||
|
||||
The [`r`][r]{:#term-r-parameter}{:.term} parameter tells payment-protocol-aware wallet programs to ignore
|
||||
the other parameters and fetch a PaymentRequest from the URL provided.
|
||||
The browser, QR code reader, or other program processing the URI opens
|
||||
the spender's Bitcoin wallet program on the URI.
|
||||
the spender's Bitcoin wallet program on the URI.
|
||||
|
||||
|
||||
|
||||
|
|
@ -321,7 +323,7 @@ invoice database:
|
|||
before used) secp256k1 public key.
|
||||
|
||||
After adding all that information to the database, Bob's server displays
|
||||
a `bitcoin:` URI for Charlie to click to pay.
|
||||
a `bitcoin:` URI for Charlie to click to pay.
|
||||
|
||||
Charlie clicks on the `bitcoin:` URI in his browser. His browser's URI
|
||||
handler sends the URI to his wallet program. The wallet is aware of the
|
||||
|
|
@ -429,79 +431,79 @@ to as a [double spend][/en/glossary/double-spend]{:#term-double-spend}{:.term}.
|
|||
Once the transaction is included in a block, double spends are
|
||||
impossible without modifying block chain history to replace the
|
||||
transaction, which is quite difficult. Using this system,
|
||||
the Bitcoin protocol can give each of your transactions an updating confidence
|
||||
score based on the number of blocks which would need to be modified to replace
|
||||
the Bitcoin protocol can give each of your transactions an updating confidence
|
||||
score based on the number of blocks which would need to be modified to replace
|
||||
a transaction. For each block, the transaction gains one [confirmation][/en/glossary/confirmation-score]{:#term-confirmation}{:.term}. Since
|
||||
modifying blocks is quite difficult, higher confirmation scores indicate
|
||||
modifying blocks is quite difficult, higher confirmation scores indicate
|
||||
greater protection.
|
||||
|
||||
**0 confirmations**: The transaction has been broadcast but is still not
|
||||
**0 confirmations**: The transaction has been broadcast but is still not
|
||||
included in any block. Zero confirmation transactions (unconfirmed
|
||||
transactions) should generally not be
|
||||
trusted without risk analysis. Although miners usually confirm the first
|
||||
trusted without risk analysis. Although miners usually confirm the first
|
||||
transaction they receive, fraudsters may be able to manipulate the
|
||||
network into including their version of a transaction.
|
||||
|
||||
**1 confirmation**: The transaction is included in the latest block and
|
||||
**1 confirmation**: The transaction is included in the latest block and
|
||||
double-spend risk decreases dramatically. Transactions which pay
|
||||
sufficient transaction fees need 10 minutes on average to receive one
|
||||
confirmation. However, the most recent block gets replaced fairly often by
|
||||
accident, so a double spend is still a real possibility.
|
||||
|
||||
**2 confirmations**: The most recent block was chained to the block which
|
||||
includes the transaction. As of March 2014, two block replacements were
|
||||
exceedingly rare, and a two block replacement attack was impractical without
|
||||
**2 confirmations**: The most recent block was chained to the block which
|
||||
includes the transaction. As of March 2014, two block replacements were
|
||||
exceedingly rare, and a two block replacement attack was impractical without
|
||||
expensive mining equipment.
|
||||
|
||||
**6 confirmations**: The network has spent about an hour working to protect
|
||||
the transaction against double spends and the transaction is buried under six
|
||||
blocks. Even a reasonably lucky attacker would require a large percentage of
|
||||
the total network hashing power to replace six blocks. Although this number is
|
||||
somewhat arbitrary, software handling high-value transactions, or otherwise at
|
||||
risk for fraud, should wait for at least six confirmations before treating a
|
||||
**6 confirmations**: The network has spent about an hour working to protect
|
||||
the transaction against double spends and the transaction is buried under six
|
||||
blocks. Even a reasonably lucky attacker would require a large percentage of
|
||||
the total network hashing power to replace six blocks. Although this number is
|
||||
somewhat arbitrary, software handling high-value transactions, or otherwise at
|
||||
risk for fraud, should wait for at least six confirmations before treating a
|
||||
payment as accepted.
|
||||
|
||||
Bitcoin Core provides several RPCs which can provide your program with the
|
||||
confirmation score for transactions in your wallet or arbitrary transactions.
|
||||
For example, the `listunspent` RPC provides an array of every satoshi you can
|
||||
Bitcoin Core provides several RPCs which can provide your program with the
|
||||
confirmation score for transactions in your wallet or arbitrary transactions.
|
||||
For example, the `listunspent` RPC provides an array of every satoshi you can
|
||||
spend along with its confirmation score.
|
||||
|
||||
Although confirmations provide excellent double-spend protection most of the
|
||||
time, there are at least three cases where double-spend risk analysis can be
|
||||
Although confirmations provide excellent double-spend protection most of the
|
||||
time, there are at least three cases where double-spend risk analysis can be
|
||||
required:
|
||||
|
||||
1. In the case when the program or its user cannot wait for a confirmation and
|
||||
1. In the case when the program or its user cannot wait for a confirmation and
|
||||
wants to accept unconfirmed payments.
|
||||
|
||||
2. In the case when the program or its user is accepting high value
|
||||
2. In the case when the program or its user is accepting high value
|
||||
transactions and cannot wait for at least six confirmations or more.
|
||||
|
||||
3. In the case of an implementation bug or prolonged attack against Bitcoin
|
||||
3. In the case of an implementation bug or prolonged attack against Bitcoin
|
||||
which makes the system less reliable than expected.
|
||||
|
||||
An interesting source of double-spend risk analysis can be acquired by
|
||||
connecting to large numbers of Bitcoin peers to track how transactions and
|
||||
blocks differ from each other. Some third-party APIs can provide you with this
|
||||
An interesting source of double-spend risk analysis can be acquired by
|
||||
connecting to large numbers of Bitcoin peers to track how transactions and
|
||||
blocks differ from each other. Some third-party APIs can provide you with this
|
||||
type of service.
|
||||
|
||||
<!-- TODO Example of double spend risk analysis using bitcoinj, eventually? -->
|
||||
|
||||
For example, unconfirmed transactions can be compared among all connected peers
|
||||
to see if any UTXO is used in multiple unconfirmed transactions, indicating a
|
||||
double-spend attempt, in which case the payment can be refused until it is
|
||||
For example, unconfirmed transactions can be compared among all connected peers
|
||||
to see if any UTXO is used in multiple unconfirmed transactions, indicating a
|
||||
double-spend attempt, in which case the payment can be refused until it is
|
||||
confirmed. Transactions can also be ranked by their transaction fee to
|
||||
estimate the amount of time until they're added to a block.
|
||||
|
||||
Another example could be to detect a fork when multiple peers report differing
|
||||
block header hashes at the same block height. Your program can go into a safe mode if the
|
||||
fork extends for more than two blocks, indicating a possible problem with the
|
||||
Another example could be to detect a fork when multiple peers report differing
|
||||
block header hashes at the same block height. Your program can go into a safe mode if the
|
||||
fork extends for more than two blocks, indicating a possible problem with the
|
||||
block chain. For more details, see the [Detecting Forks
|
||||
subsection][section detecting forks].
|
||||
|
||||
Another good source of double-spend protection can be human intelligence. For
|
||||
example, fraudsters may act differently from legitimate customers, letting
|
||||
savvy merchants manually flag them as high risk. Your program can provide a
|
||||
safe mode which stops automatic payment acceptance on a global or per-customer
|
||||
Another good source of double-spend protection can be human intelligence. For
|
||||
example, fraudsters may act differently from legitimate customers, letting
|
||||
savvy merchants manually flag them as high risk. Your program can provide a
|
||||
safe mode which stops automatic payment acceptance on a global or per-customer
|
||||
basis.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
|
@ -517,7 +519,7 @@ to return the satoshis to the pubkey script from which they came.
|
|||
For example:
|
||||
|
||||
* Alice wants to buy a widget from Bob, so Bob gives Alice a price and
|
||||
Bitcoin address.
|
||||
Bitcoin address.
|
||||
|
||||
* Alice opens her wallet program and sends some satoshis to that
|
||||
address. Her wallet program automatically chooses to spend those
|
||||
|
|
@ -629,7 +631,7 @@ There are two closely-related downsides to LIFO:
|
|||
|
||||
* If you spend an output from one unconfirmed transaction in a second
|
||||
transaction, the second transaction becomes invalid if transaction
|
||||
malleability changes the first transaction.
|
||||
malleability changes the first transaction.
|
||||
|
||||
* If you spend an output from one unconfirmed transaction in a second
|
||||
transaction and the first transaction's output is successfully double
|
||||
|
|
|
|||
|
|
@ -42,10 +42,11 @@ end_of_page: |
|
|||
</div>
|
||||
<div>
|
||||
<div>
|
||||
<h2 id="contracts"><span class="fa fa-sitemap fa-lg fa-rotate-270"></span> Contracts</h2>
|
||||
<p><a href="/en/developer-guide#contracts">Contracts Guide</a></p>
|
||||
<p><a href="https://en.bitcoin.it/wiki/Contracts"><span class="fa fa-external-link"></span> More Contracts</a> - Wiki</p>
|
||||
<p><a href="https://bitcoinj.github.io/working-with-micropayments"><span class="fa fa-external-link"></span> Micropayment Channel Example</a> - bitcoinj</p>
|
||||
<h2 id="p2p-network"><span class="fa fa-share-alt fa-lg"></span> P2P Network</h2>
|
||||
<p><a href="/en/developer-guide#p2p-network">P2P Network Guide</a></p>
|
||||
<p><a href="/en/developer-reference#p2p-network">P2P Network Reference</a></p>
|
||||
<p><a href="/en/developer-examples#p2p-network">P2P Network Examples</a></p>
|
||||
<!--<p><a href="https://en.bitcoin.it/wiki/Protocol_specification"><span class="fa fa-external-link"></span> Full Protocol Specification</a> - Wiki</p>-->
|
||||
</div><div>
|
||||
<h2 id="wallets"><span class="fa fa-btc fa-lg"></span> Wallets</h2>
|
||||
<p><a href="/en/developer-guide#wallets">Wallets Guide</a></p>
|
||||
|
|
@ -56,10 +57,12 @@ end_of_page: |
|
|||
</div>
|
||||
<div>
|
||||
<div>
|
||||
<h2 id="payment-processing"><span class="fa fa-cart-plus fa-lg"></span> Payment Processing</h2>
|
||||
<p><a href="/en/developer-guide#payment-processing">Payment Processing Guide</a></p>
|
||||
<p><a href="/en/developer-examples#payment-processing">Payment Processing Examples</a></p>
|
||||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki"><span class="fa fa-external-link"></span> Payment Protocol</a> - BIP70</p>
|
||||
<h2 id="contracts"><span class="fa fa-sitemap fa-lg fa-rotate-270"></span> Contracts</h2>
|
||||
<p><a href="/en/developer-guide#contracts">Contracts Guide</a></p>
|
||||
<!--
|
||||
<p><a href="https://en.bitcoin.it/wiki/Contracts"><span class="fa fa-external-link"></span> More Contracts</a> - Wiki</p>
|
||||
<p><a href="https://bitcoinj.github.io/working-with-micropayments"><span class="fa fa-external-link"></span> Micropayment Channel Example</a> - bitcoinj</p>
|
||||
-->
|
||||
</div><div>
|
||||
<h2 id="operating_modes"><span class="fa fa-cogs fa-lg"></span> Operating Modes</h2>
|
||||
<p><a href="/en/developer-guide#operating-modes">Operating Modes Guide</a></p>
|
||||
|
|
@ -67,11 +70,10 @@ end_of_page: |
|
|||
</div>
|
||||
<div>
|
||||
<div>
|
||||
<h2 id="p2p-network"><span class="fa fa-share-alt fa-lg"></span> P2P Network</h2>
|
||||
<p><a href="/en/developer-guide#p2p-network">P2P Network Guide</a></p>
|
||||
<p><a href="/en/developer-reference#p2p-network">P2P Network Reference</a></p>
|
||||
<p><a href="/en/developer-examples#p2p-network">P2P Network Examples</a></p>
|
||||
<p><a href="https://en.bitcoin.it/wiki/Protocol_specification"><span class="fa fa-external-link"></span> Full Protocol Specification</a> - Wiki</p>
|
||||
<h2 id="payment-processing"><span class="fa fa-cart-plus fa-lg"></span> Payment Processing</h2>
|
||||
<p><a href="/en/developer-guide#payment-processing">Payment Processing Guide</a></p>
|
||||
<p><a href="/en/developer-examples#payment-processing">Payment Processing Examples</a></p>
|
||||
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki"><span class="fa fa-external-link"></span> Payment Protocol</a> - BIP70</p>
|
||||
</div><div>
|
||||
<h2 id="mining"><span class="fa fa-puzzle-piece fa-lg"></span> Mining</h2>
|
||||
<p><a href="/en/developer-guide#mining">Mining Guide</a></p>
|
||||
|
|
@ -83,10 +85,12 @@ end_of_page: |
|
|||
|
||||
<div class="resourcesmore"><div>
|
||||
<h2 id="additional-resources"><span class="fa fa-link fa-lg"></span> Additional resources</h2>
|
||||
<p><a href="https://dashpay.atlassian.net/wiki/spaces/DOC/pages/5472261/Whitepaper"><span class="fa fa-external-link"></span> Dash Whitepaper</a> - Official Wiki</p>
|
||||
<p><a href="https://github.com/dashpay/dips#readme"><span class="fa fa-external-link"></span> Dash Improvement Proposals</a> - GitHub</p>
|
||||
<p><a href="https://dashpay.atlassian.net/wiki/spaces/DOC/pages"><span class="fa fa-external-link"></span> Dash Official Documentation</a> - Wiki</p>
|
||||
<p><a href="/en/bitcoin-paper"><span class="fa fa-external-link"></span> Bitcoin: A Peer-to-Peer Electronic Cash System</a> - Satoshi Nakamoto</p>
|
||||
<p><a href="https://github.com/bitcoin/bips#readme"><span class="fa fa-external-link"></span> Bitcoin Improvement Proposals</a> - GitHub</p>
|
||||
<p><a href="https://github.com/minium/Bitcoin-Spec"><span class="fa fa-external-link"></span> Bitcoin Developer Reference (working paper)</a> - Krzysztof Okupski</p>
|
||||
<p><a href="https://bitcoinj.github.io/#documentation"><span class="fa fa-external-link"></span> Bitcoinj Developer Documentation</a> - bitcoinj.org</p>
|
||||
<p><a href="https://programmingblockchain.gitbooks.io/programmingblockchain/content/"><span class="fa fa-external-link"></span> The C# Bitcoin book (NBitcoin Developer Documentation)</a> - Nicolas Dorier</p>
|
||||
<p><a href="https://en.bitcoin.it/wiki/Category:Technical"><span class="fa fa-external-link"></span> Technical Pages</a> - Wiki</p>
|
||||
<!--<p><a href="https://github.com/minium/Bitcoin-Spec"><span class="fa fa-external-link"></span> Bitcoin Developer Reference (working paper)</a> - Krzysztof Okupski</p>-->
|
||||
<!--<p><a href="https://bitcoinj.github.io/#documentation"><span class="fa fa-external-link"></span> Bitcoinj Developer Documentation</a> - bitcoinj.org</p>-->
|
||||
<!--<p><a href="https://programmingblockchain.gitbooks.io/programmingblockchain/content/"><span class="fa fa-external-link"></span> The C# Bitcoin book (NBitcoin Developer Documentation)</a> - Nicolas Dorier</p>-->
|
||||
</div></div>
|
||||
|
|
|
|||
|
|
@ -53,14 +53,14 @@ of the following file. -->
|
|||
|
||||
{% include devdoc/guide_wallets.md %}
|
||||
|
||||
{% include devdoc/guide_payment_processing.md %}
|
||||
|
||||
{% include devdoc/guide_operating_modes.md %}
|
||||
|
||||
{% include devdoc/guide_p2p_network.md %}
|
||||
|
||||
{% include devdoc/guide_mining.md %}
|
||||
|
||||
{% include devdoc/guide_payment_processing.md %}
|
||||
|
||||
{% include references.md %}
|
||||
{{site.glossary_links}}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue