diff --git a/_includes/devdoc/guide_payment_processing.md b/_includes/devdoc/guide_payment_processing.md index 10ec3ca2..d65ef27e 100644 --- a/_includes/devdoc/guide_payment_processing.md +++ b/_includes/devdoc/guide_payment_processing.md @@ -8,6 +8,8 @@ http://opensource.org/licenses/MIT. {% include helpers/subhead-links.md %} {% autocrossref %} + + 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. ![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg) @@ -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. -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 diff --git a/en/developer-documentation.md b/en/developer-documentation.md index 78fb041e..3eb591ad 100644 --- a/en/developer-documentation.md +++ b/en/developer-documentation.md @@ -42,10 +42,11 @@ end_of_page: |
-

Contracts

-

Contracts Guide

-

More Contracts - Wiki

-

Micropayment Channel Example - bitcoinj

+

P2P Network

+

P2P Network Guide

+

P2P Network Reference

+

P2P Network Examples

+

Wallets

Wallets Guide

@@ -56,10 +57,12 @@ end_of_page: |
-

Payment Processing

-

Payment Processing Guide

-

Payment Processing Examples

-

Payment Protocol - BIP70

+

Contracts

+

Contracts Guide

+

Operating Modes

Operating Modes Guide

@@ -67,11 +70,10 @@ end_of_page: |
-

P2P Network

-

P2P Network Guide

-

P2P Network Reference

-

P2P Network Examples

-

Full Protocol Specification - Wiki

+

Payment Processing

+

Payment Processing Guide

+

Payment Processing Examples

+

Payment Protocol - BIP70

Mining

Mining Guide

@@ -83,10 +85,12 @@ end_of_page: | diff --git a/en/developer-guide.md b/en/developer-guide.md index b6c2ad81..b6c7040f 100644 --- a/en/developer-guide.md +++ b/en/developer-guide.md @@ -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}}