diff --git a/devguide/payment_processing.rst b/devguide/payment_processing.rst index 2d6a964..3ed9b21 100644 --- a/devguide/payment_processing.rst +++ b/devguide/payment_processing.rst @@ -215,7 +215,7 @@ If a `refund <../devguide/payment_processing.html#issuing-refunds>`__ needs to b Verifying Payment ----------------- -As explained in the `Transactions <../devguide/transactions.html>`__ and `Block Chain <../devguide/blockchain.html>`__ sections, broadcasting a transaction to the `network <../devguide/p2p_network.html>`__ doesn’t ensure that the receiver gets paid. A malicious spender can create one transaction that pays the receiver and a second one that pays the same input back to himself. Only one of these transactions will be added to the block chain, and nobody can say for sure which one it will be. +As explained in the `Transactions <../devguide/transactions.html>`__ and `Block Chain <../devguide/block_chain.html>`__ sections, broadcasting a transaction to the `network <../devguide/p2p_network.html>`__ doesn’t ensure that the receiver gets paid. A malicious spender can create one transaction that pays the receiver and a second one that pays the same input back to himself. Only one of these transactions will be added to the block chain, and nobody can say for sure which one it will be. Two or more transactions spending the same input are commonly referred to as a :term:`double spend`. @@ -243,7 +243,7 @@ An interesting source of double-spend risk analysis can be acquired by connectin 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 block chain. For more details, see the `Detecting Forks subsection <../devguide/blockchain.html#detecting-forks>`__. +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 <../devguide/block_chain.html#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 basis. diff --git a/devguide/transactions.rst b/devguide/transactions.rst index 24c7e7f..99d6f0b 100644 --- a/devguide/transactions.rst +++ b/devguide/transactions.rst @@ -305,7 +305,7 @@ Locktime itself is an unsigned 4-byte integer which can be parsed two ways: Transaction Fees And Change --------------------------- -Transactions pay fees based on the total byte size of the signed transaction. Fees per byte are calculated based on current demand for space in mined blocks with fees rising as demand increases. The transaction fee is given to the Bitcoin miner, as explained in the `block chain section <../devguide/blockchain.html>`__, and so it is ultimately up to each miner to choose the minimum transaction fee they will accept. +Transactions pay fees based on the total byte size of the signed transaction. Fees per byte are calculated based on current demand for space in mined blocks with fees rising as demand increases. The transaction fee is given to the Bitcoin miner, as explained in the `block chain section <../devguide/block_chain.html>`__, and so it is ultimately up to each miner to choose the minimum transaction fee they will accept. There is also a concept of so-called “:term:`high-priority transactions `” which spend satoshis that have not moved for a long time. @@ -315,7 +315,7 @@ As of Bitcoin Core 0.9, a :term:`minimum fee ` (currently 1,0 Since each transaction spends Unspent Transaction Outputs (UTXOs) and because a UTXO can only be spent once, the full value of the included UTXOs must be spent or given to a miner as a transaction fee. Few people will have UTXOs that exactly match the amount they want to pay, so most transactions include a change output. -:term:`Change outputs ` are regular outputs which spend the surplus satoshis from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash or P2SH script hash as was used in the UTXO, but for the reasons described in the `next subsection <../transactions.html#avoiding-key-reuse>`__, it is highly recommended that change outputs be sent to a new P2PKH or P2SH address. +:term:`Change outputs ` are regular outputs which spend the surplus satoshis from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash or P2SH script hash as was used in the UTXO, but for the reasons described in the `next subsection <../devguide/transactions.html#avoiding-key-reuse>`__, it is highly recommended that change outputs be sent to a new P2PKH or P2SH address. Avoiding Key Reuse ------------------ diff --git a/examples/payment_processing.rst b/examples/payment_processing.rst index 1c93b49..48d3e13 100644 --- a/examples/payment_processing.rst +++ b/examples/payment_processing.rst @@ -32,7 +32,7 @@ The full sequence of events is illustrated below, starting with the spender clic BIP70 Payment Protocol -For the script to use the `protocol buffer `__, you will need a copy of Google’s `Protocol Buffer `__ compiler (``protoc``), which is available in most modern Linux package managers and `directly from Google. `__ Non-Google `protocol buffer `__ compilers are available for a variety of programming languages. You will also need a copy of the :ref:`PaymentRequest ` `Protocol Buffer description `__ from the Bitcoin Core source code. +For the script to use the `protocol buffer `__, you will need a copy of Google’s `Protocol Buffer `__ compiler (``protoc``), which is available in most modern Linux package managers and `directly from Google. `__ Non-Google `protocol buffer `__ compilers are available for a variety of programming languages. You will also need a copy of the :ref:`PaymentRequest ` `Protocol Buffer description `__ from the Bitcoin Core source code. Initialization Code ''''''''''''''''''' diff --git a/helpers/post_processor_rst.rb b/helpers/post_processor_rst.rb index 4269b1b..8eb0f72 100644 --- a/helpers/post_processor_rst.rb +++ b/helpers/post_processor_rst.rb @@ -180,7 +180,7 @@ def process_link(link) elsif target =~ /\/en\/developer-reference/ replace_reference_link(text, target) elsif target == "#avoiding-key-reuse" - "`#{text} <../transactions.html#avoiding-key-reuse>`__" + "`#{text} <../devguide/transactions.html#avoiding-key-reuse>`__" elsif target =~ /\/en\/release\/(.*)/ "`#{text} `__" elsif target =~ /\/en\/download/