Minor layout reorg

_includes/devdoc/guide_payment_processing.md

@@ -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.
 
 ![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.
 
 <!-- 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