Merge pull request bitcoin-dot-org#90 from bitcoin-dot-org/wbnns-reso…

…lve-89

Update / correct links

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.
 

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 <high-priority transaction>`” 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 <minimum relay 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 <change address>` 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 <change address>` 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
 ------------------

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 <https://developers.google.com/protocol-buffers/>`__, you will need a copy of Google’s `Protocol Buffer <https://developers.google.com/protocol-buffers/>`__ compiler (``protoc``), which is available in most modern Linux package managers and `directly from Google. <https://developers.google.com/protocol-buffers/>`__ Non-Google `protocol buffer <https://developers.google.com/protocol-buffers/>`__ compilers are available for a variety of programming languages. You will also need a copy of the :ref:`PaymentRequest <term-paymentrequest>` `Protocol Buffer description <https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentrequest.proto>`__ from the Bitcoin Core source code.
+For the script to use the `protocol buffer <https://developers.google.com/protocol-buffers/>`__, you will need a copy of Google’s `Protocol Buffer <https://developers.google.com/protocol-buffers/>`__ compiler (``protoc``), which is available in most modern Linux package managers and `directly from Google. <https://developers.google.com/protocol-buffers/>`__ Non-Google `protocol buffer <https://developers.google.com/protocol-buffers/>`__ compilers are available for a variety of programming languages. You will also need a copy of the :ref:`PaymentRequest <term-paymentrequest>` `Protocol Buffer description <https://github.com/bitcoin/bitcoin/blob/0.19/src/qt/paymentrequest.proto>`__ from the Bitcoin Core source code.
 
 Initialization Code
 '''''''''''''''''''

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} <https://bitcoin.org/en/release/#{$1}>`__"
     elsif target =~ /\/en\/download/