joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Minor layout reorg

Browse source
This commit is contained in:
thephez 2017-11-20 15:27:43 -05:00
parent 07cd97f08c
commit c119e2fc14
3 changed files with 66 additions and 60 deletions
Download patch file Download diff file Expand all files Collapse all files

84
_includes/devdoc/guide_payment_processing.md
View file

@ -8,6 +8,8 @@ http://opensource.org/licenses/MIT.
{% include helpers/subhead-links.md %} {% include helpers/subhead-links.md %}
{% autocrossref %} {% autocrossref %}
<!-- __ -->
<!-- https://dashpay.atlassian.net/wiki/spaces/DOC/pages/86278547/Dash+Payment+Processor-->
Payment processing encompasses the steps spenders and receivers perform Payment processing encompasses the steps spenders and receivers perform
to make and accept payments in exchange for products or services. The 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 None of the parameters provided above, except `r`, are required for the
payment protocol---but your applications may include them for backwards payment protocol---but your applications may include them for backwards
compatibility with wallet programs which don't yet handle the payment 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 [`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 other parameters and fetch a PaymentRequest from the URL provided.
The browser, QR code reader, or other program processing the URI opens 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.
![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg) ![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg)
@ -321,7 +323,7 @@ invoice database:
before used) secp256k1 public key. before used) secp256k1 public key.
After adding all that information to the database, Bob's server displays 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 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 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 Once the transaction is included in a block, double spends are
impossible without modifying block chain history to replace the impossible without modifying block chain history to replace the
transaction, which is quite difficult. Using this system, transaction, which is quite difficult. Using this system,
the Bitcoin protocol can give each of your transactions an updating confidence 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 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 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. 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 included in any block. Zero confirmation transactions (unconfirmed
transactions) should generally not be 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 transaction they receive, fraudsters may be able to manipulate the
network into including their version of a transaction. 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 double-spend risk decreases dramatically. Transactions which pay
sufficient transaction fees need 10 minutes on average to receive one sufficient transaction fees need 10 minutes on average to receive one
confirmation. However, the most recent block gets replaced fairly often by confirmation. However, the most recent block gets replaced fairly often by
accident, so a double spend is still a real possibility. accident, so a double spend is still a real possibility.
**2 confirmations**: The most recent block was chained to the block which **2 confirmations**: The most recent block was chained to the block which
includes the transaction. As of March 2014, two block replacements were includes the transaction. As of March 2014, two block replacements were
exceedingly rare, and a two block replacement attack was impractical without exceedingly rare, and a two block replacement attack was impractical without
expensive mining equipment. expensive mining equipment.
**6 confirmations**: The network has spent about an hour working to protect **6 confirmations**: The network has spent about an hour working to protect
the transaction against double spends and the transaction is buried under six the transaction against double spends and the transaction is buried under six
blocks. Even a reasonably lucky attacker would require a large percentage of 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 the total network hashing power to replace six blocks. Although this number is
somewhat arbitrary, software handling high-value transactions, or otherwise at somewhat arbitrary, software handling high-value transactions, or otherwise at
risk for fraud, should wait for at least six confirmations before treating a risk for fraud, should wait for at least six confirmations before treating a
payment as accepted. payment as accepted.
Bitcoin Core provides several RPCs which can provide your program with the Bitcoin Core provides several RPCs which can provide your program with the
confirmation score for transactions in your wallet or arbitrary transactions. confirmation score for transactions in your wallet or arbitrary transactions.
For example, the `listunspent` RPC provides an array of every satoshi you can For example, the `listunspent` RPC provides an array of every satoshi you can
spend along with its confirmation score. spend along with its confirmation score.
Although confirmations provide excellent double-spend protection most of the Although confirmations provide excellent double-spend protection most of the
time, there are at least three cases where double-spend risk analysis can be time, there are at least three cases where double-spend risk analysis can be
required: 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. 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. 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. which makes the system less reliable than expected.
An interesting source of double-spend risk analysis can be acquired by An interesting source of double-spend risk analysis can be acquired by
connecting to large numbers of Bitcoin peers to track how transactions and 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 blocks differ from each other. Some third-party APIs can provide you with this
type of service. type of service.
<!-- TODO Example of double spend risk analysis using bitcoinj, eventually? --> <!-- TODO Example of double spend risk analysis using bitcoinj, eventually? -->
For example, unconfirmed transactions can be compared among all connected peers For example, unconfirmed transactions can be compared among all connected peers
to see if any UTXO is used in multiple unconfirmed transactions, indicating a 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 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 confirmed. Transactions can also be ranked by their transaction fee to
estimate the amount of time until they're added to a block. 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 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 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 fork extends for more than two blocks, indicating a possible problem with the
block chain. For more details, see the [Detecting Forks block chain. For more details, see the [Detecting Forks
subsection][section detecting forks]. subsection][section detecting forks].
Another good source of double-spend protection can be human intelligence. For Another good source of double-spend protection can be human intelligence. For
example, fraudsters may act differently from legitimate customers, letting example, fraudsters may act differently from legitimate customers, letting
savvy merchants manually flag them as high risk. Your program can provide a 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 safe mode which stops automatic payment acceptance on a global or per-customer
basis. basis.
{% endautocrossref %} {% endautocrossref %}
@ -517,7 +519,7 @@ to return the satoshis to the pubkey script from which they came.
For example: For example:
* Alice wants to buy a widget from Bob, so Bob gives Alice a price and * 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 * Alice opens her wallet program and sends some satoshis to that
address. Her wallet program automatically chooses to spend those 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 * If you spend an output from one unconfirmed transaction in a second
transaction, the second transaction becomes invalid if transaction 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 * If you spend an output from one unconfirmed transaction in a second
transaction and the first transaction's output is successfully double transaction and the first transaction's output is successfully double

38
en/developer-documentation.md
View file

@ -42,10 +42,11 @@ end_of_page: |
</div> </div>
<div> <div>
<div> <div>
<h2 id="contracts"><span class="fa fa-sitemap fa-lg fa-rotate-270"></span> Contracts</h2> <h2 id="p2p-network"><span class="fa fa-share-alt fa-lg"></span> P2P Network</h2>
<p><a href="/en/developer-guide#contracts">Contracts Guide</a></p> <p><a href="/en/developer-guide#p2p-network">P2P Network 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="/en/developer-reference#p2p-network">P2P Network Reference</a></p>
<p><a href="https://bitcoinj.github.io/working-with-micropayments"><span class="fa fa-external-link"></span> Micropayment Channel Example</a> - bitcoinj</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> </div><div>
<h2 id="wallets"><span class="fa fa-btc fa-lg"></span> Wallets</h2> <h2 id="wallets"><span class="fa fa-btc fa-lg"></span> Wallets</h2>
<p><a href="/en/developer-guide#wallets">Wallets Guide</a></p> <p><a href="/en/developer-guide#wallets">Wallets Guide</a></p>
@ -56,10 +57,12 @@ end_of_page: |
</div> </div>
<div> <div>
<div> <div>
<h2 id="payment-processing"><span class="fa fa-cart-plus fa-lg"></span> Payment Processing</h2> <h2 id="contracts"><span class="fa fa-sitemap fa-lg fa-rotate-270"></span> Contracts</h2>
<p><a href="/en/developer-guide#payment-processing">Payment Processing Guide</a></p> <p><a href="/en/developer-guide#contracts">Contracts 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> <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> </div><div>
<h2 id="operating_modes"><span class="fa fa-cogs fa-lg"></span> Operating Modes</h2> <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> <p><a href="/en/developer-guide#operating-modes">Operating Modes Guide</a></p>
@ -67,11 +70,10 @@ end_of_page: |
</div> </div>
<div> <div>
<div> <div>
<h2 id="p2p-network"><span class="fa fa-share-alt fa-lg"></span> P2P Network</h2> <h2 id="payment-processing"><span class="fa fa-cart-plus fa-lg"></span> Payment Processing</h2>
<p><a href="/en/developer-guide#p2p-network">P2P Network Guide</a></p> <p><a href="/en/developer-guide#payment-processing">Payment Processing Guide</a></p>
<p><a href="/en/developer-reference#p2p-network">P2P Network Reference</a></p> <p><a href="/en/developer-examples#payment-processing">Payment Processing Examples</a></p>
<p><a href="/en/developer-examples#p2p-network">P2P Network 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>
<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> </div><div>
<h2 id="mining"><span class="fa fa-puzzle-piece fa-lg"></span> Mining</h2> <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> <p><a href="/en/developer-guide#mining">Mining Guide</a></p>
@ -83,10 +85,12 @@ end_of_page: |
<div class="resourcesmore"><div> <div class="resourcesmore"><div>
<h2 id="additional-resources"><span class="fa fa-link fa-lg"></span> Additional resources</h2> <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="/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/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://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://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://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>
</div></div> </div></div>

4
en/developer-guide.md
View file

@ -53,14 +53,14 @@ of the following file. -->
{% include devdoc/guide_wallets.md %} {% include devdoc/guide_wallets.md %}
{% include devdoc/guide_payment_processing.md %}
{% include devdoc/guide_operating_modes.md %} {% include devdoc/guide_operating_modes.md %}
{% include devdoc/guide_p2p_network.md %} {% include devdoc/guide_p2p_network.md %}
{% include devdoc/guide_mining.md %} {% include devdoc/guide_mining.md %}
{% include devdoc/guide_payment_processing.md %}
{% include references.md %} {% include references.md %}
{{site.glossary_links}} {{site.glossary_links}}