added headers to each page which allow for better page-linking, added…

… two new site-wide replace defs and updated their usage in corresponding pages
bitcoin-dot-org · Apr 24, 2021 · 05ab6c7 · 05ab6c7
1 parent dd08d1f
commit 05ab6c7
Show file tree

Hide file tree

Showing 22 changed files with 49 additions and 10 deletions.
diff --git a/conf.py b/conf.py
@@ -194,7 +194,8 @@
 #rst_prolog = ''
 rst_epilog = """
 .. reference aliases
-.. |network| replace:: :ref:`network<p2p-network-header>`
+.. |network| replace:: :ref:`network<dev-p2p-network-header>`
+.. |peer-to-peer network| replace:: :ref:`peer-to-peer network<dev-p2p-network-header>`
 
 .. frequently-used terms with links
 .. |ECDSA| replace:: `ECDSA <https://en.wikipedia.org/wiki/Elliptic_Curve_DSA>`__

diff --git a/devguide/block_chain.rst b/devguide/block_chain.rst
@@ -1,4 +1,4 @@
-.. _block-chain-header:
+.. _dev-block-chain-header:
 
 Block Chain
 ===========

diff --git a/devguide/contracts.rst b/devguide/contracts.rst
@@ -1,3 +1,5 @@
+.. _dev-contracts-header:
+
 Contracts
 =========
 

diff --git a/devguide/index.rst b/devguide/index.rst
@@ -1,3 +1,5 @@
+.. _dev-index-header:
+
 Developer Guides
 ================
 

diff --git a/devguide/mining.rst b/devguide/mining.rst
@@ -1,3 +1,5 @@
+.. _dev-mining-header:
+
 Mining
 ======
 

diff --git a/devguide/operating_modes.rst b/devguide/operating_modes.rst
@@ -1,3 +1,5 @@
+.. _dev-operating-modes-header:
+
 Operating Modes
 ===============
 

diff --git a/devguide/p2p_network.rst b/devguide/p2p_network.rst
@@ -1,4 +1,4 @@
-.. _p2p-network-header:
+.. _dev-p2p-network-header:
 
 P2P Network
 ===========

diff --git a/devguide/payment_processing.rst b/devguide/payment_processing.rst
@@ -1,3 +1,5 @@
+.. _dev-payment-processing-header:
+
 Payment Processing
 ==================
 

diff --git a/devguide/transactions.rst b/devguide/transactions.rst
@@ -1,3 +1,5 @@
+.. _dev-transactions-header:
+
 Transactions
 ============
 

diff --git a/devguide/wallets.rst b/devguide/wallets.rst
@@ -1,3 +1,5 @@
+.. _dev-wallets-header:
+
 Wallets
 =======
 
@@ -15,7 +17,7 @@ Wallet Programs
 
 Permitting receiving and spending of satoshis is the only essential feature of wallet software—but a particular wallet program doesn’t need to do both things. Two wallet programs can work together, one program distributing public keys in order to receive satoshis and another program signing transactions spending those satoshis.
 
-Wallet programs also need to interact with the `peer-to-peer network <../devguide/p2p_network.html>`__ to get information from the block chain and to broadcast new transactions. However, the programs which distribute public keys or sign transactions don’t need to interact with the `peer-to-peer network <../devguide/p2p_network.html>`__ themselves.
+Wallet programs also need to interact with the |peer-to-peer network| to get information from the block chain and to broadcast new transactions. However, the programs which distribute public keys or sign transactions don’t need to interact with the |peer-to-peer network| themselves.
 
 This leaves us with three necessary, but separable, parts of a wallet system: a public key distribution program, a signing program, and a networked program. In the subsections below, we will describe common combinations of these parts.
 
@@ -42,7 +44,7 @@ To help protect against theft, many wallet programs offer users the option of en
 Signing-Only Wallets
 ~~~~~~~~~~~~~~~~~~~~
 
-To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the `peer-to-peer network <../devguide/p2p_network.html>`__.
+To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the |peer-to-peer network|.
 
 Signing-only wallets programs typically use deterministic key creation (described in a later subsection) to create parent private and public keys which can create child private and public keys.
 
@@ -59,7 +61,7 @@ Often, users are given a chance to review the unsigned transactions’ details (
 
 After the optional review step, the signing-only wallet uses the parent private key to derive the appropriate child private keys and signs the transactions, giving the signed transactions back to the networked wallet.
 
-The networked wallet then broadcasts the signed transactions to the `peer-to-peer network <../devguide/p2p_network.html>`__.
+The networked wallet then broadcasts the signed transactions to the |peer-to-peer network|.
 
 The following subsections describe the two most common variants of signing-only wallets: offline wallets and hardware wallets.
 
@@ -70,13 +72,13 @@ Several full-service wallets programs will also operate as two separate wallets:
 
 The offline wallet is so named because it is intended to be run on a device which does not connect to any |network|, greatly reducing the number of attack vectors. If this is the case, it is usually up to the user to handle all data transfer using removable media such as USB drives. The user’s workflow is something like:
 
-1. (Offline) Disable all |network| connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
+1. (Offline) Disable all network connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
 
 2. (Online) Install the wallet software on another device, this one connected to the Internet, and import the parent public key from the removable media. As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the output details and save the unsigned transaction generated by the wallet to removable media.
 
 3. (Offline) Open the unsigned transaction in the offline instance, review the output details to make sure they spend the correct amount to the correct address. This prevents malware on the online wallet from tricking the user into signing a transaction which pays an attacker. After review, sign the transaction and save it to removable media.
 
-4. (Online) Open the signed transaction in the online instance so it can broadcast it to the `peer-to-peer network <../devguide/p2p_network.html>`__.
+4. (Online) Open the signed transaction in the online instance so it can broadcast it to the |peer-to-peer network|.
 
 The primary advantage of offline wallets is their possibility for greatly improved security over full-service wallets. As long as the offline wallet is not compromised (or flawed) and the user reviews all outgoing transactions before signing, the user’s satoshis are safe even if the online wallet is compromised.
 
@@ -115,7 +117,7 @@ Wallet programs which run in difficult-to-secure environments, such as webserver
 
 -  Use a parent public key to create child public keys. To avoid key reuse, a method must be used to ensure the same public key isn’t distributed twice. This can be a database entry for each key distributed or an incrementing pointer to the :term:`key index` number.
 
-Neither method adds a significant amount of overhead, especially if a database is used anyway to associate each incoming payment with a separate public key for payment tracking. See the `Payment Processing <../devguide/payment_processing.html>`__ section for details.
+Neither method adds a significant amount of overhead, especially if a database is used anyway to associate each incoming payment with a separate public key for payment tracking. See the :ref:`dev-payment-processing-header` section for details.
 
 Wallet Files
 ------------
@@ -132,7 +134,7 @@ Private keys are what are used to unlock satoshis from a particular address. In
 Wallet Import Format (WIF)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In order to make copying of private keys less prone to error, :term:`Wallet Import Format` may be utilized. WIF uses base58Check encoding on a private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
+In order to make copying of private keys less prone to error, :term:`Wallet Import Format` may be utilized. WIF uses :term:`base58Check` encoding on a private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
 
 1. Take a private key.
 

diff --git a/examples/index.rst b/examples/index.rst
@@ -1,3 +1,5 @@
+.. _examples-index-header:
+
 Examples
 ========
 

diff --git a/examples/intro.rst b/examples/intro.rst
@@ -1,3 +1,5 @@
+.. _examples-intro-header:
+
 Introduction
 ============
 

diff --git a/examples/p2p_networking.rst b/examples/p2p_networking.rst
@@ -1,3 +1,5 @@
+.. _examples-p2p-networking-header:
+
 P2P Network
 -----------
 

diff --git a/examples/payment_processing.rst b/examples/payment_processing.rst
@@ -1,3 +1,5 @@
+.. _examples-payment-processing-header:
+
 Payment Processing
 ------------------
 

diff --git a/examples/testing.rst b/examples/testing.rst
@@ -1,3 +1,5 @@
+.. _examples-testing-header:
+
 Testing Applications
 --------------------
 

diff --git a/examples/transactions.rst b/examples/transactions.rst
@@ -1,3 +1,5 @@
+.. _examples-transactions-header:
+
 Transactions
 ------------
 

diff --git a/reference/block_chain.rst b/reference/block_chain.rst
@@ -1,3 +1,5 @@
+.. _reference-block-chain-header:
+
 Block Chain
 -----------
 

diff --git a/reference/index.rst b/reference/index.rst
@@ -1,3 +1,5 @@
+.. _reference-index-header:
+
 Reference
 =========
 

diff --git a/reference/intro.rst b/reference/intro.rst
@@ -1,3 +1,5 @@
+.. _reference-intro-header:
+
 Introduction
 ============
 

diff --git a/reference/p2p_networking.rst b/reference/p2p_networking.rst
@@ -1,3 +1,5 @@
+.. _reference-p2p-networking-header:
+
 P2P Network
 -----------
 

diff --git a/reference/transactions.rst b/reference/transactions.rst
@@ -1,3 +1,5 @@
+.. _reference-transactions-header:
+
 Transactions
 ------------
 

diff --git a/reference/wallets.rst b/reference/wallets.rst
@@ -1,3 +1,5 @@
+.. _reference-wallets-header:
+
 Wallets
 -------