combined a few more repetitive references into single definitions

Author: turkycat

conf.py

@@ -197,8 +197,8 @@
 .. |network| replace:: :ref:`network<p2p-network-header>`
 
 .. frequently-used terms with links
-.. |ECDSA| replace:: `ECDSA <https://en.wikipedia.org/wiki/Elliptic_Curve_DSA>`
-.. |secp256k1| replace:: `secp256k1 <http://www.secg.org/sec2-v2.pdf>`
+.. |ECDSA| replace:: `ECDSA <https://en.wikipedia.org/wiki/Elliptic_Curve_DSA>`__
+.. |secp256k1| replace:: `secp256k1 <http://www.secg.org/sec2-v2.pdf>`__
 
 .. OP codes
 .. |OP_CHECKMULTISIG| replace:: :term:`“OP_CHECKMULTISIG” <OP_CHECKMULTISIG>`

devguide/contracts.rst

@@ -17,7 +17,7 @@ Charlie-the-customer wants to buy a product from Bob-the-businessman, but neithe
 
 A simple contract could say that Charlie will spend satoshis to an output which can only be spent if Charlie and Bob both sign the input spending it. That means Bob won’t get paid unless Charlie gets his merchandise, but Charlie can’t get the merchandise and keep his payment.
 
-This simple contract isn’t much help if there’s a dispute, so Bob and Charlie enlist the help of Alice-the-arbitrator to create an :term:`escrow contract`. Charlie spends his satoshis to an output which can only be spent if two of the three people sign the input. Now Charlie can pay Bob if everything is ok, Bob can `refund <../devguide/payment_processing.html#issuing-refunds>`__ Charlie’s money if there’s a problem, or Alice can arbitrate and decide who should get the satoshis if there’s a dispute.
+This simple contract isn’t much help if there’s a dispute, so Bob and Charlie enlist the help of Alice-the-arbitrator to create an :term:`escrow contract`. Charlie spends his satoshis to an output which can only be spent if two of the three people sign the input. Now Charlie can pay Bob if everything is ok, Bob can `refund <../devguide/payment_processing.html#issuing-refunds>`_ Charlie’s money if there’s a problem, or Alice can arbitrate and decide who should get the satoshis if there’s a dispute.
 
 To create a multiple-signature (:term:`multisig`) output, they each give the others a public key. Then Bob creates the following :term:`P2SH multisig` redeem script:
 
@@ -31,9 +31,9 @@ To create a multiple-signature (:term:`multisig`) output, they each give the oth
 
 Bob gives the redeem script to Charlie, who checks to make sure his public key and Alice’s public key are included. Then he hashes the redeem script to create a P2SH redeem script and pays the satoshis to it. Bob sees the payment get added to the block chain and ships the merchandise.
 
-Unfortunately, the merchandise gets slightly damaged in transit. Charlie wants a full `refund <../devguide/payment_processing.html#issuing-refunds>`__, but Bob thinks a 10% `refund <../devguide/payment_processing.html#issuing-refunds>`__ is sufficient. They turn to Alice to resolve the issue. Alice asks for photo evidence from Charlie along with a copy of the redeem script Bob created and Charlie checked.
+Unfortunately, the merchandise gets slightly damaged in transit. Charlie wants a full refund_, but Bob thinks a 10% refund_ is sufficient. They turn to Alice to resolve the issue. Alice asks for photo evidence from Charlie along with a copy of the redeem script Bob created and Charlie checked.
 
-After looking at the evidence, Alice thinks a 40% `refund <../devguide/payment_processing.html#issuing-refunds>`__ is sufficient, so she creates and signs a transaction with two outputs, one that spends 60% of the satoshis to Bob’s public key and one that spends the remaining 40% to Charlie’s public key.
+After looking at the evidence, Alice thinks a 40% refund_ is sufficient, so she creates and signs a transaction with two outputs, one that spends 60% of the satoshis to Bob’s public key and one that spends the remaining 40% to Charlie’s public key.
 
 In the signature script Alice puts her signature and a copy of the unhashed serialized redeem script that Bob created. She gives a copy of the incomplete transaction to both Bob and Charlie. Either one of them can complete it by adding his signature to create the following signature script:
 
@@ -56,20 +56,20 @@ Alice also works part time moderating forum posts for Bob. Every time someone po
 
 Bob asks Alice for her public key and then creates two transactions. The first transaction pays 100 millibitcoins to a P2SH output whose 2-of-2 multisig redeem script requires signatures from both Alice and Bob. This is the bond transaction. Broadcasting this transaction would let Alice hold the millibitcoins hostage, so Bob keeps this transaction private for now and creates a second transaction.
 
-The second transaction spends all of the first transaction’s millibitcoins (minus a transaction fee) back to Bob after a 24 hour delay enforced by locktime. This is the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction. Bob can’t sign the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction by himself, so he gives it to Alice to sign, as shown in the illustration below.
+The second transaction spends all of the first transaction’s millibitcoins (minus a transaction fee) back to Bob after a 24 hour delay enforced by locktime. This is the refund_ transaction. Bob can’t sign the refund_ transaction by himself, so he gives it to Alice to sign, as shown in the illustration below.
 
 .. figure:: /img/dev/en-micropayment-channel.svg
    :alt: Micropayment Channel Example
 
    Micropayment Channel Example
 
-Alice checks that the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction’s locktime is 24 hours in the future, signs it, and gives a copy of it back to Bob. She then asks Bob for the bond transaction and checks that the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction spends the output of the bond transaction. She can now broadcast the bond transaction to the |network| to ensure Bob has to wait for the time lock to expire before further spending his millibitcoins. Bob hasn’t actually spent anything so far, except possibly a small transaction fee, and he’ll be able to broadcast the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction in 24 hours for a full `refund <../devguide/payment_processing.html#issuing-refunds>`__.
+Alice checks that the refund_ transaction’s locktime is 24 hours in the future, signs it, and gives a copy of it back to Bob. She then asks Bob for the bond transaction and checks that the refund_ transaction spends the output of the bond transaction. She can now broadcast the bond transaction to the |network| to ensure Bob has to wait for the time lock to expire before further spending his millibitcoins. Bob hasn’t actually spent anything so far, except possibly a small transaction fee, and he’ll be able to broadcast the refund_ transaction in 24 hours for a full refund_.
 
-Now, when Alice does some work worth 1 millibitcoin, she asks Bob to create and sign a new version of the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction. Version two of the transaction spends 1 millibitcoin to Alice and the other 99 back to Bob; it does not have a locktime, so Alice can sign it and spend it whenever she wants. (But she doesn’t do that immediately.)
+Now, when Alice does some work worth 1 millibitcoin, she asks Bob to create and sign a new version of the refund_ transaction. Version two of the transaction spends 1 millibitcoin to Alice and the other 99 back to Bob; it does not have a locktime, so Alice can sign it and spend it whenever she wants. (But she doesn’t do that immediately.)
 
-Alice and Bob repeat these work-and-pay steps until Alice finishes for the day, or until the time lock is about to expire. Alice signs the final version of the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction and broadcasts it, paying herself and refunding any remaining balance to Bob. The next day, when Alice starts work, they create a new :term:`micropayment channel`.
+Alice and Bob repeat these work-and-pay steps until Alice finishes for the day, or until the time lock is about to expire. Alice signs the final version of the refund_ transaction and broadcasts it, paying herself and refunding any remaining balance to Bob. The next day, when Alice starts work, they create a new :term:`micropayment channel`.
 
-If Alice fails to broadcast a version of the `refund <../devguide/payment_processing.html#issuing-refunds>`__ transaction before its time lock expires, Bob can broadcast the first version and receive a full `refund <../devguide/payment_processing.html#issuing-refunds>`__. This is one reason :term:`micropayment channels <micropayment channel>` are best suited to small payments—if Alice’s Internet service goes out for a few hours near the time lock expiry, she could be cheated out of her payment.
+If Alice fails to broadcast a version of the refund_ transaction before its time lock expires, Bob can broadcast the first version and receive a full refund_. This is one reason :term:`micropayment channels <micropayment channel>` are best suited to small payments—if Alice’s Internet service goes out for a few hours near the time lock expiry, she could be cheated out of her payment.
 
 Transaction malleability, discussed above in the Transactions section, is another reason to limit the value of :term:`micropayment channels <micropayment channel>`. If someone uses transaction malleability to break the link between the two transactions, Alice could hold Bob’s 100 millibitcoins hostage even if she hadn’t done any work.
 

devguide/payment_processing.rst

@@ -6,7 +6,7 @@ Payment processing encompasses the steps spenders and receivers perform to make
 Introduction
 ------------
 
-This section will explain how receivers and spenders can, respectively, request and make payments using Bitcoin—and how they can deal with complications such as `refunds <../devguide/payment_processing.html#issuing-refunds>`__ and `recurrent rebilling <../devguide/payment_processing.html#rebilling-recurring-payments>`__.
+This section will explain how receivers and spenders can, respectively, request and make payments using Bitcoin—and how they can deal with complications such as `refunds <../devguide/payment_processing.html#issuing-refunds>`_ and `recurrent rebilling <../devguide/payment_processing.html#rebilling-recurring-payments>`__.
 
 .. figure:: /img/dev/en-payment-processing.svg
    :alt: Bitcoin Payment Processing
@@ -34,7 +34,7 @@ Exchange rates lie outside the control of Bitcoin and related technologies, so t
 
 Because the exchange rate fluctuates over time, order totals pegged to :term:`fiat` must expire to prevent spenders from delaying payment in the hope that satoshis will drop in price. Most widely-used payment processing systems currently expire their invoices after 10 to 20 minutes.
 
-Shorter expiration periods increase the chance the invoice will expire before payment is received, possibly necessitating manual intervention to request an additional payment or to issue a `refund <../devguide/payment_processing.html#issuing-refunds>`__. Longer expiration periods increase the chance that the exchange rate will fluctuate a significant amount before payment is received.
+Shorter expiration periods increase the chance the invoice will expire before payment is received, possibly necessitating manual intervention to request an additional payment or to issue a refund_. Longer expiration periods increase the chance that the exchange rate will fluctuate a significant amount before payment is received.
 
 Requesting Payments
 -------------------
@@ -51,7 +51,7 @@ The next subsections will describe in detail the following four compatible ways
 
 3. Most mobile wallets support scanning |Bitcoin URIs| encoded in a QR code, and almost all wallets can display them for accepting payment. While also handy for online orders, QR Codes are especially useful for in-person purchases.
 
-4. Recent wallet updates add support for the new payment protocol providing increased security, authentication of a receiver’s identity using `X.509 <https://en.wikipedia.org/wiki/X.509>`__ certificates, and other important features such as `refunds <../devguide/payment_processing.html#issuing-refunds>`__.
+4. Recent wallet updates add support for the new payment protocol providing increased security, authentication of a receiver’s identity using `X.509 <https://en.wikipedia.org/wiki/X.509>`__ certificates, and other important features such as refunds_.
 
 |Warning icon| **Warning:** Special care must be taken to avoid the theft of incoming payments. In particular, private keys should not be stored on web servers, and payment requests should be sent over HTTPS or other secure methods to prevent `man-in-the-middle <https://en.wikipedia.org/wiki/Man-in-the-middle_attack>`__ attacks from replacing your Bitcoin address with the attacker’s address.
 
@@ -198,7 +198,7 @@ Charlie’s wallet receives the |PaymentRequest|  message, checks its signature,
 
 -  An optional memo Charlie can send to Bob. (There’s no guarantee that Bob will read it.)
 
--  A `refund <../devguide/payment_processing.html#issuing-refunds>`__ address (pubkey script) which Bob can pay if he needs to return some or all of Charlie’s satoshis.
+-  A `refund <../devguide/payment_processing.html#issuing-refunds>`_ address (pubkey script) which Bob can pay if he needs to return some or all of Charlie’s satoshis.
 
 Bob’s server receives the Payment message, verifies the transaction pays the requested amount to the address provided, and then broadcasts the transaction to the |network|. It also replies to the HTTP POSTed Payment message with a PaymentACK message, which includes an optional memo from Bob’s server thanking Charlie for his patronage and providing other information about the order, such as the expected arrival date.
 
@@ -210,7 +210,7 @@ In the case of a dispute, Charlie can generate a cryptographically proven :term:
 
 -  The Bitcoin block chain can prove that the pubkey script specified by Bob was paid the specified number of satoshis.
 
-If a `refund <../devguide/payment_processing.html#issuing-refunds>`__ needs to be issued, Bob’s server can safely pay the `refund <../devguide/payment_processing.html#issuing-refunds>`__-to pubkey script provided by Charlie. See the `Refunds <../devguide/payment_processing.html#issuing-refunds>`__ section below for more details.
+If a refund_ needs to be issued, Bob’s server can safely pay the refund-to pubkey script provided by Charlie. See the `Issuing Refunds`_ section below for more details.
 
 Verifying Payment
 -----------------
@@ -250,23 +250,23 @@ Another good source of double-spend protection can be human intelligence. For ex
 Issuing Refunds
 ---------------
 
-Occasionally receivers using your applications will need to issue `refunds <../devguide/payment_processing.html#issuing-refunds>`__. The obvious way to do that, which is very unsafe, is simply to return the satoshis to the pubkey script from which they came. For example:
+Occasionally receivers using your applications will need to issue refunds_. The obvious way to do that, which is very unsafe, is simply 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.
 
 -  Alice opens her wallet program and sends some satoshis to that address. Her wallet program automatically chooses to spend those satoshis from one of its unspent outputs, an output corresponding to the Bitcoin address mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN.
 
--  Bob discovers Alice paid too many satoshis. Being an honest fellow, Bob `refunds <../devguide/payment_processing.html#issuing-refunds>`__ the extra satoshis to the mjSk… address.
+-  Bob discovers Alice paid too many satoshis. Being an honest fellow, Bob refunds_ the extra satoshis to the mjSk… address.
 
-This seems like it should work, but Alice is using a centralized multi-user web wallet which doesn’t give :term:`unique addresses` to each user, so it has no way to know that Bob’s `refund <../devguide/payment_processing.html#issuing-refunds>`__ is meant for Alice. Now the `refund <../devguide/payment_processing.html#issuing-refunds>`__ is a unintentional donation to the company behind the centralized wallet, unless Alice opens a support ticket and proves those satoshis were meant for her.
+This seems like it should work, but Alice is using a centralized multi-user web wallet which doesn’t give :term:`unique addresses` to each user, so it has no way to know that Bob’s refund_ is meant for Alice. Now the refund_ is a unintentional donation to the company behind the centralized wallet, unless Alice opens a support ticket and proves those satoshis were meant for her.
 
-This leaves receivers only two correct ways to issue `refunds <../devguide/payment_processing.html#issuing-refunds>`__:
+This leaves receivers only two correct ways to issue refunds_:
 
--  If an address was copy-and-pasted or a basic |Bitcoin URI| was used, contact the spender directly and ask them to provide a `refund <../devguide/payment_processing.html#issuing-refunds>`__ address.
+-  If an address was copy-and-pasted or a basic |Bitcoin URI| was used, contact the spender directly and ask them to provide a refund_ address.
 
--  If the payment protocol was used, send the `refund <../devguide/payment_processing.html#issuing-refunds>`__ to the output listed in the ``refund_to`` field of the Payment message.
+-  If the payment protocol was used, send the refund_ to the output listed in the ``refund_to`` field of the Payment message.
 
-Note: it would be wise to contact the spender directly if the `refund <../devguide/payment_processing.html#issuing-refunds>`__ is being issued a long time after the original payment was made. This allows you to ensure the user still has access to the key or keys for the ``refund_to`` address.
+Note: it would be wise to contact the spender directly if the refund_ is being issued a long time after the original payment was made. This allows you to ensure the user still has access to the key or keys for the ``refund_to`` address.
 
 Disbursing Income (Limiting Forex Risk)
 ---------------------------------------