Merge pull request bitcoin-dot-org#104 from tushar-1728/master

Fixed sphinx build warnings

.gitignore

@@ -1 +1,2 @@
-_build
+_build/
+.vscode

devguide/contracts.rst

@@ -17,9 +17,9 @@ 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 <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 <p2sh multisig>` redeem script:
+To create a multiple-signature (:term:`multisig <Multisig>`) output, they each give the others a public key. Then Bob creates the following :term:`P2SH multisig <P2SH multisig>` redeem script:
 
 ::
 

devguide/p2p_network.rst

@@ -15,7 +15,7 @@ To provide practical examples of the Bitcoin `peer-to-peer network <../devguide/
 Peer Discovery
 --------------
 
-When started for the first time, programs don’t know the IP addresses of any active full nodes. In order to discover some IP addresses, they query one or more DNS names (called :term:`DNS seeds <dns seed>`) hardcoded into Bitcoin Core and `BitcoinJ <http://bitcoinj.github.io>`__. The response to the lookup should include one or more `DNS A records <http://tools.ietf.org/html/rfc1035#section-3.2.2>`__ with the IP addresses of full nodes that may accept new incoming connections. For example, using the `Unix ``dig`` command <https://en.wikipedia.org/wiki/Dig_%28Unix_command%29>`__:
+When started for the first time, programs don’t know the IP addresses of any active full nodes. In order to discover some IP addresses, they query one or more DNS names (called :term:`DNS seeds <DNS seed>`) hardcoded into Bitcoin Core and `BitcoinJ <http://bitcoinj.github.io>`__. The response to the lookup should include one or more `DNS A records <http://tools.ietf.org/html/rfc1035#section-3.2.2>`__ with the IP addresses of full nodes that may accept new incoming connections. For example, using the `Unix ``dig`` command <https://en.wikipedia.org/wiki/Dig_%28Unix_command%29>`__:
 
 ::
 
@@ -155,7 +155,7 @@ All of these problems are addressed in part or in full by the headers-first IBD
 Headers-First
 ~~~~~~~~~~~~~
 
-`Bitcoin Core 0.10.0 <https://bitcoin.org/en/release/v0.10.0>`__ uses an initial block download (IBD) method called *headers-first*. The goal is to download the headers for the best :term:`header chain`, partially validate them as best as possible, and then download the corresponding blocks in parallel. This solves several problems with the older blocks-first IBD method.
+`Bitcoin Core 0.10.0 <https://bitcoin.org/en/release/v0.10.0>`__ uses an initial block download (IBD) method called *headers-first*. The goal is to download the headers for the best :term:`header chain <Header chain>`, partially validate them as best as possible, and then download the corresponding blocks in parallel. This solves several problems with the older blocks-first IBD method.
 
 .. figure:: /img/dev/en-headers-first-flowchart.svg
    :alt: Overview Of Headers-First Method
@@ -230,7 +230,7 @@ When a miner discovers a new block, it broadcasts the new block to its peers usi
 
    The miner replies to each request accordingly by sending the block in a `“block” message <../reference/p2p_networking.html#block>`__, one or more headers in a `“headers” message <../reference/p2p_networking.html#headers>`__, or the merkle block and transactions relative to the SPV client’s bloom filter in a `“merkleblock” message <../reference/p2p_networking.html#merkleblock>`__ followed by zero or more `“tx” messages <../reference/p2p_networking.html#tx>`__.
 
--  :term:`Direct Headers Announcement <block header>`\ **:** a relay node may skip the round trip overhead of an `“inv” message <../reference/p2p_networking.html#inv>`__ followed by ``getheaders`` by instead immediately sending a `“headers” message <../reference/p2p_networking.html#headers>`__ containing the full header of the new block. A HF peer receiving this message will partially validate the block header as it would during headers-first IBD, then request the full block contents with a `“getdata” message <../reference/p2p_networking.html#getdata>`__ if the header is valid. The relay node then responds to the ``getdata`` request with the full or filtered block data in a ``block`` or `“merkleblock” message <../reference/p2p_networking.html#merkleblock>`__, respectively. A HF node may signal that it prefers to receive ``headers`` instead of ``inv`` announcements by sending a special `“sendheaders” message <../reference/p2p_networking.html#sendheaders>`__ during the connection handshake.
+-  :term:`Direct Headers Announcement <Block header>`\ **:** a relay node may skip the round trip overhead of an `“inv” message <../reference/p2p_networking.html#inv>`__ followed by ``getheaders`` by instead immediately sending a `“headers” message <../reference/p2p_networking.html#headers>`__ containing the full header of the new block. A HF peer receiving this message will partially validate the block header as it would during headers-first IBD, then request the full block contents with a `“getdata” message <../reference/p2p_networking.html#getdata>`__ if the header is valid. The relay node then responds to the ``getdata`` request with the full or filtered block data in a ``block`` or `“merkleblock” message <../reference/p2p_networking.html#merkleblock>`__, respectively. A HF node may signal that it prefers to receive ``headers`` instead of ``inv`` announcements by sending a special `“sendheaders” message <../reference/p2p_networking.html#sendheaders>`__ during the connection handshake.
 
    This protocol for block broadcasting was proposed in BIP 130 and has been implemented in Bitcoin Core since version 0.12.
 

devguide/payment_processing.rst

@@ -126,7 +126,7 @@ Payment Protocol
 
 |Warning icon| **Warning:** The payment protocol is considered to be deprecated and will be removed in a later version of Bitcoin Core. The protocol has multiple security design flaws and implementation flaws in some wallets. Users will begin receiving deprecation warnings in Bitcoin Core version 0.18 when using `BIP70 <https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki>`__ URI’s. Merchants should transition away from `BIP70 <https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki>`__ to more secure options such as `BIP21 <https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki>`__. Merchants should never require `BIP70 <https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki>`__ payments and should provide `BIP21 <https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki>`__ fallbacks.
 
-Bitcoin Core 0.9 supports the new :term:`payment protocol`. The payment protocol adds many important features to payment requests:
+Bitcoin Core 0.9 supports the new :term:`payment protocol <Payment protocol>`. The payment protocol adds many important features to payment requests:
 
 -  Supports `X.509 <https://en.wikipedia.org/wiki/X.509>`__ certificates and SSL encryption to verify receivers’ identity and help prevent `man-in-the-middle <https://en.wikipedia.org/wiki/Man-in-the-middle_attack>`__ attacks.
 
@@ -217,9 +217,9 @@ Verifying Payment
 
 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`.
+Two or more transactions spending the same input are commonly referred to as a :term:`double spend <Double spend>`.
 
-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 a transaction. For each block, the transaction gains one :term:`confirmation <confirmation score>`. Since modifying blocks is quite difficult, higher confirmation scores indicate greater protection.
+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 a transaction. For each block, the transaction gains one :term:`confirmation <Confirmation score>`. Since modifying blocks is quite difficult, higher confirmation scores indicate greater protection.
 
 **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 transaction they receive, fraudsters may be able to manipulate the `network <../devguide/p2p_network.html>`__ into including their version of a transaction.