removing 2e index tags

applications.adoc

@@ -14,7 +14,7 @@ routed payment channels (Lightning Network).
 === Building Blocks (Primitives)
 
 ((("blockchain applications", "building blocks for
-(primitives)")))((("primitives")))When operating correctly and over the
+(primitives)")))When operating correctly and over the
 long term, the Bitcoin system offers certain guarantees, which can be
 used as building blocks to create applications. These include:
 
@@ -107,13 +107,13 @@ new feature introduced into Bitcoin.
 
 === Applications from Building Blocks
 
-((("blockchain applications", "examples of")))The building blocks
+The building blocks
 offered by Bitcoin are elements of a trust platform that can be used to
 compose applications. Here are some examples of applications that exist
 today and the building blocks they use:
 
 Proof-of-Existence (Digital Notary):: ((("digital notary
-services")))((("Proof of Existence")))Immutability + Timestamp + Durability.
+services")))Immutability + Timestamp + Durability.
 A transaction on the blockchain can commit to a value,
 proving that a piece of data existed at the time
 it was recorded (Timestamp). The commitment cannot be modified ex-post-facto
@@ -136,17 +136,17 @@ Double-Spend) the settlement on a shorter timelock (Timelock).
 === Colored Coins
 
 ((("blockchain applications", "colored coins",
-id="BCAcoins12")))((("colored coins", id="color12")))The first
+id="BCAcoins12")))The first
 blockchain application we will discuss is _colored coins_.
 
-((("extrinsic asset management")))Colored coins refers to a set of
+Colored coins refers to a set of
 similar technologies that use Bitcoin transactions to record the
 creation, ownership, and transfer of extrinsic assets other than
 bitcoin. By "extrinsic" we mean assets that are not stored directly on
 the bitcoin blockchain, as opposed to bitcoin itself, which is an asset
 intrinsic to the blockchain.
 
-((("digital asset management")))Colored coins are used to track digital
+Colored coins are used to track digital
 assets as well as physical assets held by third parties and traded
 through colored coins certificates of ownership. Digital asset colored
 coins can represent intangible assets such as a stock certificate,
@@ -155,7 +155,7 @@ intellectual property (trademarks, copyrights, etc.). Tangible asset
 colored coins can represent certificates of ownership of commodities
 (gold, silver, oil), land title, automobiles, boats, aircraft, etc.
 
-((("Enhanced Padded-Order-Based Coloring (EPOBC)")))The term derives
+The term derives
 from the idea of "coloring" or marking a nominal amount of bitcoin, for
 example, a single satoshi, to represent something other than the bitcoin
 amount itself. As an analogy, consider stamping a $1 note with a message
@@ -379,7 +379,7 @@ underlying data transport mechanism is not the channel. We use the term
 channel to represent the relationship and shared state between two
 parties, outside of the blockchain.
 
-((("payment (state) channels", "concept of")))To further explain this
+To further explain this
 concept, think of a TCP stream. From the perspective of higher-level
 protocols it is a "socket" connecting two applications across the
 internet. But if you look at the network traffic, a TCP stream is just a
@@ -406,7 +406,7 @@ the state being altered is the balance of a virtual currency.
 
 ==== State Channels—Basic Concepts and Terminology
 
-((("payment (state) channels", "terminology")))A state channel is
+A state channel is
 established between two parties, through a transaction that locks a
 shared state on the blockchain. This is called the _funding transaction_.
 This single transaction must be transmitted to
@@ -453,7 +453,7 @@ image::images/mbc2_1204.png["A payment channel between Bob and Alice, showing th
 
 ==== Simple Payment Channel Example
 
-((("payment (state) channels", "example of", id="PSCexample12")))To
+To
 explain state channels, we start with a very simple example. We
 demonstrate a one-way channel, meaning that value is flowing in one
 direction only. We will also start with the naive assumption that no one
@@ -547,7 +547,7 @@ the commitment transactions that update the balance of the channel.
 In the end, only two transactions are recorded on the blockchain: the
 funding transaction that established the channel and a settlement
 transaction that allocated the final balance correctly between the two
-participants.((("", startref="PSCexample12")))
+participants.
 
 [[video_payment_channel]]
 .Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
@@ -698,7 +698,7 @@ settlement transaction they can close the channel and redeem their
 balance immediately. Worst case, one of the parties can be petty, refuse
 to cooperate, and force the other party to do a unilateral close with
 the most recent commitment transaction. But if they do that, they have
-to wait for their funds too.((("", startref="PSCtrust12")))
+to wait for their funds too.
 
 ==== Asymmetric Revocable Commitments
 
@@ -922,7 +922,7 @@ channel.
 
 ==== Hash Time Lock Contracts (HTLC)
 
-((("Hash Time Lock Contracts (HTLC)")))((("payment (state) channels",
+((("payment (state) channels",
 "Hash Time Lock Contracts (HTLC)")))Payment channels can be further
 extended with a special type of smart contract that allows the
 participants to commit funds to a redeemable secret, with an expiration
@@ -973,7 +973,7 @@ redeemed by _anyone_ who has the secret +R+. An HTLC can take many
 different forms with slight variations to the script. For example,
 adding a +CHECKSIG+ operator and a public key in the first clause
 restricts redemption of the hash to a particular recipient, who must also
-know the secret +R+.((("", startref="BCApayment12")))
+know the secret +R+.
 
 [[lightning_network]]
 === Routed Payment Channels (Lightning Network)
@@ -998,7 +998,7 @@ https://github.com/lightning/bolts/blob/master/00-introduction.md[_Basics of Lig
 
 ==== Basic Lightning Network Example
 
-((("Lightning Network", "basic example")))Let's see how this works.
+Let's see how this works.
 
 In this example, we have five participants: Alice, Bob, Carol, Diana,
 and Eric. These five participants have opened payment channels with each
@@ -1114,7 +1114,7 @@ refund if the channel was closed or the routed payment failed.
 
 ==== Lightning Network Transport and Pathfinding
 
-((("Lightning Network", "transport and pathfinding")))All communications
+All communications
 between LN nodes are encrypted point-to-point. In addition, nodes have a
 long-term public key that they use as an
 identifier and to authenticate each other.
@@ -1204,7 +1204,7 @@ hops to go.
 
 ==== Lightning Network Benefits
 
-((("Lightning Network", "benefits of")))A Lightning Network is a
+A Lightning Network is a
 second-layer routing technology. It can be applied to any blockchain
 that supports some basic capabilities, such as multisignature
 transactions, timelocks, and basic smart contracts.

authorization-authentication.adoc

@@ -37,7 +37,7 @@ Script is a very simple language.  It requires minimal processing and
 cannot easily do many of the fancy things modern programming languages
 can do.
 
-((("Pay-to-Public-Key-Hash (P2PKH)")))When legacy transactions were the
+When legacy transactions were the
 most commonly used type of transaction, the majority of transactions processed
 through the Bitcoin network had the form "Payment to Bob's Bitcoin
 address" and used a script called a Pay-to-Public-Key-Hash script.
@@ -53,7 +53,7 @@ conditions for spending and how those conditions can be satisfied.
 
 [TIP]
 ====
-((("programmable money")))Bitcoin transaction validation is not based on
+Bitcoin transaction validation is not based on
 a static pattern, but instead is achieved through the execution of a
 scripting language. This language allows for a nearly infinite variety
 of conditions to be expressed.
@@ -61,14 +61,14 @@ of conditions to be expressed.
 
 ==== Turing Incompleteness
 
-((("Turing incompleteness")))The Bitcoin transaction script language
+The Bitcoin transaction script language
 contains many operators, but is deliberately limited in one important
 way--there are no loops or complex flow control capabilities other than
 conditional flow control. This ensures that the language is not _Turing
 Complete_, meaning that scripts have limited complexity and predictable
 execution times. Script is not a general-purpose language.
-((("denial-of-service attacks")))((("denial-of-service attacks",
-see="also security")))((("security", "denial-of-service attacks")))These
+((("denial-of-service attacks",
+see="also security")))These
 limitations ensure that the language cannot be used to create an
 infinite loop or other form of "logic bomb" that could be embedded in a
 transaction in a way that causes a denial-of-service attack against the
@@ -78,7 +78,7 @@ validation mechanism from being used as a vulnerability.
 
 ==== Stateless Verification
 
-((("stateless verification")))The Bitcoin transaction script language is
+The Bitcoin transaction script language is
 stateless, in that there is no state prior to execution of the script,
 or state saved after execution of the script. All the
 information needed to execute a script is contained within the script
@@ -205,7 +205,7 @@ to know that the number 2 satisfies the script.
 
 [TIP]
 ====
-((("transactions", "valid and invalid")))Transactions are valid if the
+Transactions are valid if the
 top result on the stack is +TRUE+, which is any
 non-zero value.
 Transactions are invalid if the top value on the stack is +FALSE+ (the
@@ -261,7 +261,7 @@ failed to satisfy the spending conditions placed on the output.
 [[p2pkh]]
 ==== Pay-to-Public-Key-Hash (P2PKH)
 
-((("Pay-to-Public-Key-Hash (P2PKH)")))
+
 A Pay-to-Public-Key-Hash or "P2PKH" script uses an output script that
 contains a hash which commits to a public key.  P2PKH is best known as
 the basis for a legacy Bitcoin address. A P2PKH output can be spent by
@@ -301,7 +301,7 @@ data-xrefstyle="select: labelnumber">#P2PubKHash1</a>] and pass:[<a
 data-type="xref" href="#P2PubKHash2" data-xrefstyle="select:
 labelnumber">#P2PubKHash2</a>] show (in two parts) a step-by-step
 execution of the combined script, which will prove this is a valid
-transaction.((("", startref="Tsript06")))((("",
+transaction.((("",
 startref="Stransact06")))
 
 [[P2PubKHash1]]
@@ -316,7 +316,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
 === Scripted multisignatures
 
 ((("transactions", "advanced", "multisignature
-scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting",
+scripts")))((("scripting",
 "multisignature scripts", id="Smulti07")))((("multisignature
 scripts")))Multisignature scripts set a condition where _k_ public keys
 are recorded in the script and at least _t_ of those must provide
@@ -389,7 +389,7 @@ script may include multiple of those opcodes.
 ==== An oddity in CHECKMULTISIG execution
 
 ((("scripting", "multisignature scripts", "OP_CHECKMULTISIG
-oddity")))((("OP_CHECKMULTISIG oddity workaround")))There is an oddity in
+oddity")))There is an oddity in
 ++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When
 +OP_CHECKMULTISIG+ executes, it should consume t+k+2 items on the stack as
 parameters. However, due to the oddity, +OP_CHECKMULTISIG+ will pop an extra
@@ -476,13 +476,13 @@ startref="Smulti07")))
 [[p2sh]]
 === Pay-to-Script-Hash (P2SH)
 
-((("transactions", "advanced", "Pay-to-Script-Hash")))((("scripting",
+((("scripting",
 "Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was
 introduced in 2012 as a powerful new type of operation that greatly
 simplifies the use of complex scripts. To explain the need
 for P2SH, let's look at a practical example.
 
-((("use cases", "import/export", id="mohamseven")))((("scripting",
+((("scripting",
 "Pay-to-Script-Hash", "import/export example")))((("Pay-to-Script-Hash
 (P2SH)", "import/export example")))
 Mohammed is an electronics importer based in Dubai. Mohammed's
@@ -525,7 +525,7 @@ matches the commitment in addition to the data which satisfies the script. In si
 P2SH means "pay to a script matching this hash, a script that will be
 presented later when this output is spent."
 
-((("redeem scripts")))((("scripting", "redeem scripts")))In P2SH
+In P2SH
 transactions, the script that is replaced by a hash is referred
 to as the _redeem script_ because it is presented to the system at
 redemption time rather than as an output script. <<without_p2sh>> shows
@@ -618,7 +618,7 @@ If the redeem script hash matches, the redeem script is executed:
 ==== P2SH Addresses
 
 ((("scripting", "Pay-to-Script-Hash",
-"addresses")))((("Pay-to-Script-Hash (P2SH)", "addresses")))((("bitcoin
+"addresses")))((("bitcoin
 improvement proposals", "Address Format for P2SH (BIP13)")))Another
 important part of the P2SH feature is the ability to encode a script
 hash as an address, as defined in BIP13. P2SH addresses are Base58Check
@@ -643,7 +643,7 @@ payment does not see the script.
 ==== Benefits of P2SH
 
 ((("scripting", "Pay-to-Script-Hash", "benefits
-of")))((("Pay-to-Script-Hash (P2SH)", "benefits of")))The P2SH feature
+of")))The P2SH feature
 offers the following benefits compared to the direct use of complex
 scripts in outputs:
 
@@ -679,7 +679,7 @@ risk, because you can send bitcoin to a P2SH address that cannot be spent later.
 
 [WARNING]
 ====
-((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts
+P2SH output scripts
 contain the hash of a redeem script, which gives no clues as to
 the content of the redeem script. The P2SH output will be
 considered valid and accepted even if the redeem script is invalid. You
@@ -690,10 +690,10 @@ spent.
 [[op_return]]
 === Data Recording Output (OP_RETURN)
 
-((("transactions", "advanced", "data recording output")))((("scripting",
-"data recording output")))((("OP_RETURN operator")))((("data recording
-(nonpayment data)")))((("nonpayment data")))((("blockchain (the)",
-"nonpayment data recording")))((("digital notary services")))Bitcoin's
+((("scripting",
+"data recording output")))((("data recording
+(nonpayment data)")))((("blockchain (the)",
+"nonpayment data recording")))Bitcoin's
 distributed and timestamped blockchain has potential uses
 beyond payments. Many developers have tried to use the transaction
 scripting language to take advantage of the security and resilience of
@@ -705,8 +705,8 @@ to a file in such a way that anyone could establish
 proof-of-existence of that file on a specific date by reference to that
 transaction.
 
-((("blockchain bloat")))((("bloat")))((("unspent transaction outputs
-(UTXO)")))((("UTXO sets")))The use of Bitcoin's blockchain to store data
+((("unspent transaction outputs
+(UTXO)")))The use of Bitcoin's blockchain to store data
 unrelated to Bitcoin payments is a controversial subject. Many
 people consider such use abusive and want to discourage it. Others
 view it as a demonstration of the powerful capabilities of blockchain
@@ -739,7 +739,7 @@ expensive database operations.
 OP_RETURN <data>
 ----
 
-((("Proof of Existence")))((("DOCPROOF prefix")))The data portion
+The data portion
 often represents a hash, such as the output
 from the SHA256 algorithm (32 bytes). Some applications put a prefix in
 front of the data to help identify the application. For example, the
@@ -769,7 +769,7 @@ being included in a block until a specific block height, but it does not
 prevent spending the funds in another transaction earlier than that.
 Let's explain that with the following example.
 
-((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
+Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
 
 * Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
 * Bob may transmit the transaction after 3 months.
@@ -783,7 +783,7 @@ It is important to understand the limitations of transaction lock time. The only
 
 ==== Check Lock Time Verify (OP_CLTV)
 
-((("Check Lock Time Verify (OP_CLTV)", id="cltv07")))((("timelocks", "Check
+((("timelocks", "Check
 Lock Time Verify (OP_CLTV)")))((("scripting", "timelocks", "Check Lock Time
 Verify (OP_CLTV)")))((("bitcoin improvement proposals",
 "OP_CHECKLOCKTIMEVERIFY (BIP65)")))In December 2015, a new form of
@@ -891,7 +891,7 @@ expired.
 
 By introducing timelock functionality directly into the scripting
 language, +OP_CLTV+ allows us to develop some very interesting complex
-scripts.((("", startref="cltv07")))
+scripts.
 
 The standard is defined in
 https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
@@ -902,7 +902,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
 
 Lock time and +OP_CLTV+ are ((("timelocks", "relative timelocks",
 id="Trelative07")))((("scripting", "timelocks", "relative
-timelocks")))((("relative timelocks", id="relativetime07")))both
+timelocks")))both
 _absolute timelocks_ in that they specify an absolute point in time. The
 next two timelock features we will examine are _relative timelocks_ in
 that they specify, as a condition of spending an output, an elapsed time
@@ -938,7 +938,7 @@ the consensus rules.
 ==== Relative Timelocks with OP_CSV
 
 ((("scripting", "timelocks", "relative timelocks with
-CHECKSEQUENCEVERIFY")))((("CHECKSEQUENCEVERIFY (CSV)")))Just like OP_CLTV
+CHECKSEQUENCEVERIFY")))Just like OP_CLTV
 and lock time, there is a script opcode for relative timelocks that
 leverages the sequence value in scripts. That opcode is
 +OP_CHECKSEQUENCEVERIFY+, commonly referred to as +OP_CSV+ for short.
@@ -970,7 +970,7 @@ is, they're kept off the blockchain (_offchain_). A child transaction cannot be
 parent transaction has been propagated, mined, and aged by the time
 specified in the relative timelock. One application of this use case can
 be seen in <<state_channels>> and <<lightning_network>>.((("",
-startref="relativetime07")))((("", startref="Trelative07")))
+startref="relativetime07")))
 
 +OP_CSV+ is defined in detail in
 https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
@@ -978,9 +978,9 @@ CHECKSEQUENCEVERIFY].
 
 === Scripts with Flow Control (Conditional Clauses)
 
-((("transactions", "advanced", "flow control scripts")))((("scripting",
+((("scripting",
 "flow control scripts", id="Sflow07")))((("conditional clauses",
-id="condition07")))((("flow control", id="flow07")))One of the more
+id="condition07")))One of the more
 powerful features of Bitcoin Script is flow control, also known as
 conditional clauses. You are probably familiar with flow control in
 various programming languages that use the construct +IF...THEN...ELSE+.
@@ -1041,13 +1041,13 @@ comes _before_ the +IF+ opcode.
 
 ==== Conditional Clauses with VERIFY Opcodes
 
-((("VERIFY opcodes")))((("IF clauses")))((("opcodes", "VERIFY")))Another
+Another
 form of conditional in Bitcoin Script is any opcode that ends in
 +VERIFY+. The +VERIFY+ suffix means that if the condition evaluated is
 not +TRUE+, execution of the script terminates immediately and the
 transaction is deemed invalid.
 
-((("guard clauses")))Unlike an +IF+ clause, which offers alternative
+Unlike an +IF+ clause, which offers alternative
 execution paths, the +VERIFY+ suffix acts as a _guard clause_,
 continuing only if a precondition is met.
 
@@ -1104,7 +1104,7 @@ A very common use for flow control in Bitcoin Script is to construct a
 script that offers multiple execution paths, each a different way
 of redeeming the UTXO.
 
-((("use cases", "buying coffee")))Let's look at a simple example, where
+Let's look at a simple example, where
 we have two signers, Alice and Bob, and either one is able to redeem.
 With multisig, this would be expressed as a 1-of-2 multisig script. For
 the sake of demonstration, we will do the same thing with an +OP_IF+
@@ -1178,12 +1178,12 @@ Using this construct, we can build redeem scripts with tens or hundreds
 of execution paths, each offering a different way to redeem the UTXO. To
 spend, we construct an input script that navigates the execution
 path by putting the appropriate +TRUE+ and +FALSE+ values on the stack
-at each flow control point.((("", startref="Sflow07")))((("",
-startref="flow07")))((("", startref="condition07")))
+at each flow control point.((("",
+startref="flow07")))
 
 === Complex Script Example
 
-((("transactions", "advanced", "example")))((("scripting", "complex
+((("scripting", "complex
 script example", id="Scomplex07")))In this section we combine many of
 the concepts from this chapter into a single example.
 
@@ -1378,7 +1378,7 @@ to the receiver in the manner that the receiver indicated.
 [[p2wsh]]
 ===== Pay-to-Witness-Script-Hash (P2WSH)
 
-The ((("use cases", "import/export", id="mohamappd")))second type of
+The second type of
 segwit v0 witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We
 saw this type of script in <<p2sh>>. In that example, P2SH was used by
 Mohammed's company to express a multisignature script. Payments to

bips.adoc

@@ -2,7 +2,7 @@
 [appendix]
 == Bitcoin Improvement Proposals
 
-((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
+Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
 
 As per BIP1 _BIP Purpose and Guidelines_, there are three kinds of BIPs:
 
@@ -10,7 +10,7 @@ _Standard_ BIP:: Describes any change that affects most or all Bitcoin implement
 _Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
 _Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
 
-((("bitcoin improvement proposals", "repository of")))BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
+BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
 An MIT-licensed document from the open source Bitcoin Core project,
 reproduced here in edited form, describes which BIPs it implements, including listing
 the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or

bitcoin-core.adoc

@@ -25,7 +25,7 @@ create and examine data related to the blockchain and network.
 
 === From Bitcoin to Bitcoin Core
 
-((("open source licenses")))((("Nakamoto, Satoshi")))Bitcoin is an _open
+Bitcoin is an _open
 source_ project and the source code is available under an open (MIT)
 license, free to download and use for any purpose.  More than just being
 open source, Bitcoin is developed by
@@ -35,7 +35,7 @@ contributors with about a dozen developers working on the code almost
 full-time and several dozen more on a part-time basis. Anyone can
 contribute to the code—including you!
 
-((("bitcoin whitepaper")))((("Satoshi client")))((("reference
+((("reference
 implementation", see="Bitcoin Core")))((("Bitcoin Core", "reference
 implementation")))When Bitcoin was created by Satoshi Nakamoto, the
 software was mostly completed before publication of the whitepaper reproduced in
@@ -51,7 +51,7 @@ wallets, a transaction and block validation engine, tools for block construction
 of Bitcoin peer-to-peer communication.
 
 <<bitcoin_core_architecture>> shows the architecture of Bitcoin
-Core.((("Bitcoin Core", "architecture")))
+Core.
 
 [[bitcoin_core_architecture]]
 .Bitcoin Core architecture (Source: Eric Lombrozo)
@@ -68,7 +68,7 @@ several major upgrades to Bitcoin.
 
 === Bitcoin Development Environment
 
-((("development environment", "setup", see="Bitcoin Core")))If you're a
+If you're a
 developer, you will want to set up a development environment with all
 the tools, libraries, and support software for writing Bitcoin
 applications. In this highly technical chapter, we'll walk through that
@@ -81,7 +81,7 @@ next chapter, which is less technical.
 
 ((("Bitcoin Core", "compiling from source code",
 id="BCsource03")))((("Bitcoin Core", "compiling from source code",
-"downloading")))((("code examples, obtaining and using")))Bitcoin Core's
+"downloading")))Bitcoin Core's
 source code can be downloaded as an archive or by cloning the
 source repository from GitHub.  ((("Bitcoin Core
 downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download
@@ -93,7 +93,7 @@ https://github.com/bitcoin/bitcoin[GitHub bitcoin page].
 
 [TIP]
 ====
-((("$ symbol")))((("shell commands")))((("terminal applications")))In
+In
 many of the examples in this chapter we will be using the operating
 system's command-line interface (also known as a "shell"), accessed via
 a "terminal" application. The shell will display a prompt; you type a
@@ -107,7 +107,7 @@ system's responses to that command. When you see the next +$+ prefix,
 you'll know it's a new command and you should repeat the process.
 ====
 
-((("cloning source code")))((("source code, cloning", seealso="Bitcoin
+((("source code, cloning", seealso="Bitcoin
 Core")))In this example, we are using the +git+ command to create a
 local copy ("clone") of the source code:
 
@@ -124,7 +124,7 @@ Resolving deltas: 100% (175649/175649), done.
 
 [TIP]
 ====
-((("distributed version control systems")))Git is the most widely used
+Git is the most widely used
 distributed version control system, an essential part of any software
 developer's toolkit. You may need to install the +git+ command, or a
 graphical user interface for git, on your operating system if you do not
@@ -192,7 +192,7 @@ nothing to commit, working tree clean
 ==== Configuring the Bitcoin Core Build
 
 ((("Bitcoin Core", "compiling from source code", "build
-configuration")))((("documentation")))((("build documentation",
+configuration")))((("build documentation",
 seealso="Bitcoin Core")))The source code includes documentation, which
 can be found in a number of files. Review the main documentation located
 in _README.md_ in the _bitcoin_ directory.
@@ -303,7 +303,7 @@ fixes the error.
 ==== Building the Bitcoin Core Executables
 
 ((("Bitcoin Core", "compiling from source code", "core
-executables")))((("core executables", seealso="Bitcoin Core")))Next, you
+executables")))Next, you
 will compile the source code, a process that can take up to an hour to
 complete, depending on the speed of your CPU and available memory.
 If an error
@@ -343,7 +343,7 @@ libtool: install: /usr/bin/install -c bitcoin-tx /usr/local/bin/bitcoin-tx
 ...
 ----
 
-((("", startref="BCsource03")))The default installation of +bitcoind+
+The default installation of +bitcoind+
 puts it in _/usr/local/bin_. You can confirm that Bitcoin Core is
 correctly installed by asking the system for the path of the
 executables, as follows:
@@ -358,7 +358,7 @@ $ which bitcoin-cli
 
 === Running a Bitcoin Core Node
 
-((("Bitcoin Core", "running core nodes", id="BCnode03")))((("Bitcoin
+((("Bitcoin
 nodes", "running core nodes", id="BNcore03")))Bitcoin's peer-to-peer
 network is composed of network "nodes," run mostly by individuals and
 some of the businesses that provide Bitcoin services. Those running
@@ -393,7 +393,7 @@ https://blockstream.com/satellite/[Blockstream Satellite].
 [TIP]
 ====
 ((("warnings and cautions", "core node resource
-requirements")))((("resource requirements")))Bitcoin Core keeps a full
+requirements")))Bitcoin Core keeps a full
 copy of the blockchain by default, with nearly every transaction that has ever
 been confirmed on the Bitcoin network since its inception in 2009. This
 dataset is hundreds of gigabytes in size and is downloaded incrementally
@@ -437,9 +437,9 @@ node.
 
 ==== Configuring the Bitcoin Core Node
 
-((("Bitcoin Core", "running core nodes", "configuring")))((("warnings
+((("warnings
 and cautions", "password creation")))((("passwords",
-"creating")))((("security", "passwords")))Bitcoin Core will look for a
+"creating")))Bitcoin Core will look for a
 configuration file in its data directory on every start. In this section
 we will examine the various configuration options and set up a
 configuration file. To locate the configuration file, run +bitcoind
@@ -488,7 +488,7 @@ Options:
 [many more options]
 ----
 
-((("configuration options", seealso="Bitcoin Core")))Here are some of
+Here are some of
 the most important options that you can set in the configuration file,
 or as command-line parameters to +bitcoind+:
 
@@ -532,7 +532,7 @@ Use it to reduce memory use on memory-constrained nodes.
 ****
 ((("Bitcoin Core", "running core nodes", "database
 options")))((("transactions", "database configuration
-options")))((("txindex option")))((("full indexing option")))By default,
+options")))By default,
 Bitcoin Core builds a database containing _only_ the transactions
 related to the user's wallet. If you want to be able to access _any_
 transaction with commands like +getrawtransaction+ (see
@@ -654,11 +654,11 @@ that it runs continuously and restarts when the operating system
 restarts. You will find a number of example startup scripts for various
 operating systems in Bitcoin Core's source directory under _contrib/init_ and
 a _README.md_ file showing which system uses which script.((("",
-startref="BCnode03")))((("", startref="BNcore03")))
+startref="BCnode03")))
 
 === Bitcoin Core Application Programming Interface (API)
 
-((("Bitcoin Core", "Bitcoin Core API", id="BCapi03")))Bitcoin Core
+Bitcoin Core
 implements a JSON-RPC interface that can also be accessed using
 the command-line helper +bitcoin-cli+. The command line allows us to
 experiment interactively with the capabilities that are also available
@@ -723,7 +723,7 @@ and their expected output.
 
 ==== Getting Information on Bitcoin Core's Status
 
-((("Bitcoin Core", "Bitcoin Core API", "status information")))Bitcoin
+Bitcoin
 Core provides status reports on different modules through the JSON-RPC
 interface. The most important commands include +getblockchaininfo+,
 +getmempoolinfo+, +getnetworkinfo+ and +getwalletinfo+.
@@ -811,7 +811,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
 
 [TIP]
 ====
-((("transaction IDs (txd)")))((("malleability")))A transaction ID (txid)
+A transaction ID (txid)
 is not authoritative. Absence of a txid in the blockchain does not mean
 the transaction was not processed. This is known as "transaction
 malleability," because transactions can be modified prior to
@@ -905,7 +905,7 @@ transmitted from one owner to the next.
 
 ==== Exploring Blocks
 
-((("blocks", "block height")))((("blocks", "block hash")))Exploring
+Exploring
 blocks is similar to exploring transactions. However, blocks can be
 referenced either by the block _height_ or by the block _hash_. First,
 let's find a block by its height.
@@ -985,7 +985,7 @@ we'll examine those in detail in <<mining>>.
 ==== Using Bitcoin Core's Programmatic Interface
 
 ((("Bitcoin Core", "Bitcoin Core API", "using programmatic
-interface")))((("programmatic interface", id="progint03")))The
+interface")))The
 +bitcoin-cli+ helper is very useful for exploring the Bitcoin Core API
 and testing functions. But the whole point of an application programming
 interface is to access functions programmatically. In this section we
@@ -1102,7 +1102,7 @@ and more clearly demonstrates the use of a programmatic interface.
 In <<rpc_block>>, we first retrieve a block, then retrieve each of
 the transactions within it by reference to each transaction ID. Next,
 we iterate through each of the transaction's outputs and add up the
-value.((("", startref="alicethree")))
+value.
 
 [[rpc_block]]
 .Retrieving a block and adding all the transaction outputs
@@ -1126,16 +1126,16 @@ block is 10,322.07722534 BTC (including 25 BTC reward and 0.0909 BTC in
 fees). Compare that to the amount reported by a block explorer site by
 searching for the block hash or height. Some block explorers report the
 total value excluding the reward and excluding the fees. See if you can
-spot the difference.((("", startref="BCapi03")))((("",
+spot the difference.((("",
 startref="progint03")))
 
 [[alt_libraries]]
 === Alternative Clients, Libraries, and Toolkits
 
-((("Bitcoin Core", "alternatives to", id="BCalt03")))((("clients,
+((("clients,
 libraries, and toolkits", id="clients03")))((("libraries, clients, and
 toolkits", id="librar03")))((("toolkits, libraries, and clients",
-id="toolkit03")))((("third-party API clients", id="thirdpart03")))There
+id="toolkit03")))There
 are many alternative clients, libraries, toolkits, and even full-node
 implementations in the bitcoin ecosystem. These are implemented in a
 variety of programming languages, offering programmers native interfaces
@@ -1172,9 +1172,9 @@ https://bitcoin-s.org/[bitcoin-s]:: A Bitcoin implementation in Scala
 https://github.com/MetacoSA/NBitcoin[NBitcoin]:: Comprehensive bitcoin library for the .NET framework
 
 Many more libraries exist in a variety of other programming languages
-and more are created all the time.((("", startref="BCalt03")))((("",
-startref="clients03")))((("", startref="thirdpart03")))((("",
-startref="toolkit03")))((("", startref="librar03")))
+and more are created all the time.((("",
+startref="clients03")))((("",
+startref="toolkit03")))
 
 If you followed the instructions in this chapter, you now have Bitcoin
 Core running and have begun exploring the network and blockchain using

blockchain.adoc

@@ -8,19 +8,19 @@ structure of the blockchain and see how it uses cryptographic
 commitments and other clever tricks to make every part of it easy for
 full nodes (and sometimes light clients) to validate.
 
-((("blockchain (the)", "overview of")))The blockchain data structure is
+The blockchain data structure is
 an ordered, back-linked list of blocks of transactions.  The blockchain
 can be stored as a flat file, or in a simple database.
 Blocks are linked "back," each referring to the previous block in the
-chain. ((("blocks", "block height")))The blockchain is often visualized
+chain. The blockchain is often visualized
 as a vertical stack, with blocks layered on top of each other and the
 first block serving as the foundation of the stack. The visualization of
 blocks stacked on top of each other results in the use of terms such as
 "height" to refer to the distance from the first block, and "top" or
 "tip" to refer to the most recently added block.
 
-((("blocks", "block hash")))((("blocks", "genesis block")))((("blocks",
-"parent blocks")))((("genesis block")))((("parent blocks")))Each block
+((("blocks",
+"parent blocks")))Each block
 within the blockchain is identified by a hash, generated using the
 SHA256 cryptographic hash algorithm on the header of the block. Each
 block also commits to the previous block, known as the _parent_ block,
@@ -58,7 +58,7 @@ years. In the blockchain, the most recent few blocks might be revised if
 there is a chain reorganization due to a fork. The top six blocks are
 like a few inches of topsoil. But once you go more deeply into the
 blockchain, beyond six blocks, blocks are less and less likely to
-change. ((("transactions", "coinbase transactions")))((("coinbase
+change. ((("coinbase
 transactions")))After 100 blocks back there is so much stability that
 the coinbase transaction--the transaction containing the reward in
 bitcoin for creating a new block--can be spent.
@@ -70,7 +70,7 @@ infinitesimal.
 
 === Structure of a Block
 
-((("blocks", "structure of")))((("blockchain (the)", "block
+((("blockchain (the)", "block
 structure")))A block is a container data structure that aggregates
 transactions for inclusion in the blockchain. The
 block is made of a header, containing metadata, followed by a long list
@@ -95,8 +95,8 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
 [[block_header]]
 === Block Header
 
-((("blocks", "headers")))((("blockchain (the)", "block
-headers")))((("headers")))The block header consists of
+((("blockchain (the)", "block
+headers")))The block header consists of
 block metadata as shown in <<block_header_structure_ch09>>.
 
 [[block_header_structure_ch09]]
@@ -118,8 +118,8 @@ process and will be discussed in more detail in <<mining>>.
 [[block_hash]]
 === Block Identifiers: Block Header Hash and Block Height
 
-((("blockchain (the)", "block identifiers")))((("blocks", "block
-height")))((("blocks", "block hash")))The primary identifier of a block
+((("blocks", "block
+height")))The primary identifier of a block
 is its cryptographic hash, a commitment made by hashing the
 block header twice through the SHA256 algorithm. The resulting 32-byte
 hash is called the _block hash_ but is more accurately the _block header
@@ -178,7 +178,7 @@ the blockchain.
 
 === The Genesis Block
 
-((("blocks", "genesis block")))((("blockchain (the)", "genesis
+((("blockchain (the)", "genesis
 block")))The first block in the blockchain is called the _genesis block_
 and was created in 2009. It is the common ancestor of all the blocks in
 the blockchain, meaning that if you start at any block and follow the
@@ -250,7 +250,7 @@ first block by Satoshi Nakamoto, Bitcoin's creator.
 
 === Linking Blocks in the Blockchain
 
-((("blocks", "linking blocks in the blockchain")))((("blockchain (the)",
+((("blockchain (the)",
 "linking blocks in the blockchain")))Bitcoin full nodes validate every
 block in the blockchain after the genesis block. Their local view of
 the blockchain is constantly updated as new blocks are found and used to
@@ -307,11 +307,11 @@ image::images/mbc2_0901.png[]
 [[merkle_trees]]
 === Merkle Trees
 
-((("merkle trees", id="merkle09")))((("blockchain (the)", "merkle
+((("blockchain (the)", "merkle
 trees", id="BCTmerkle09")))Each block in the Bitcoin blockchain contains
 a summary of all the transactions in the block using a _merkle tree_.
 
-((("binary hash trees", see="merkle trees")))A _merkle tree_, also known
+A _merkle tree_, also known
 as a _binary hash tree_, is a data structure used for efficiently
 summarizing and verifying the integrity of large sets of data. Merkle
 trees are binary trees containing cryptographic hashes. The term "tree"
@@ -369,7 +369,7 @@ of the nodes.
 .Calculating the nodes in a merkle tree
 image::images/mbc2_0902.png["merkle_tree"]
 
-((("balanced trees")))Because the merkle tree is a binary tree, it needs
+Because the merkle tree is a binary tree, it needs
 an even number of leaf nodes. If there is an odd number of transactions
 to summarize, the last transaction hash will be duplicated to create an
 even number of leaf nodes, also known as a _balanced tree_. This is
@@ -434,7 +434,7 @@ size, just 32 bytes. Whether there is one transaction or ten
 thousand transactions in the block, the merkle root always summarizes
 them into 32 bytes.
 
-((("authentication paths")))To prove that a specific transaction is
+To prove that a specific transaction is
 included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte
 hashes, constituting an _authentication path_ or _merkle path_
 connecting the specific transaction to the root of the tree. This is
@@ -497,18 +497,18 @@ transaction is recorded in the blockchain. All in all, the lightweight client wi
 have received less than a kilobyte of data for the block header and
 merkle path, an amount of data that is more than a thousand times less
 than a full block (about 2 megabytes currently).((("",
-startref="BCTmerkle09")))((("", startref="merkle09")))
+startref="BCTmerkle09")))
 
 === Bitcoin's Test Blockchains
 
 ((("blockchain (the)", "test blockchains",
-id="BCTtest09")))((("mainnet", seealso="blockchain (the)")))You might be
+id="BCTtest09")))You might be
 surprised to learn that there is more than one blockchain used with Bitcoin. The
 "main" Bitcoin blockchain, the one created by Satoshi Nakamoto on
 January 3rd, 2009, the one with the genesis block we studied in this
 chapter, is called _mainnet_.  There are other Bitcoin blockchains that
 are used for testing purposes: at this time _testnet_, _signet_, and
-_regtest_. Let's look at each in turn.((("testnet", id="testnet09")))
+_regtest_. Let's look at each in turn.
 
 ==== Testnet: Bitcoin's Testing Playground
 
@@ -588,7 +588,7 @@ experiment and learn in other programming languages and frameworks.
 
 Testnet3 supports all the features of mainnet, including
 Segregated Witness v0 and v1 (see <<segwit>> and <<taproot>>). Therefore, testnet3 can also be
-used to test Segregated Witness features.((("", startref="testnet09")))
+used to test Segregated Witness features.
 
 ===== Problems With Testnet
 
@@ -695,7 +695,7 @@ $ bitcoin-cli -signet getblockchaininfo
 
 ==== Regtest&#x2014;The Local Blockchain
 
-((("regtest (Regression Testing)")))Regtest, which stands for
+Regtest, which stands for
 "Regression Testing," is a Bitcoin Core feature that allows you to
 create a local blockchain for testing purposes. Unlike signet and testnet3, which
 are a public and shared test blockchain, the regtest blockchains are
@@ -767,7 +767,7 @@ $ bitcoin-cli -regtest getbalance
 
 === Using Test Blockchains for Development
 
-((("development environment", "test blockchains and")))Bitcoin's various
+Bitcoin's various
 blockchains (+regtest+, +signet+, +testnet3+, +mainnet+) offer a range
 of testing environments for bitcoin development. Use the test
 blockchains whether you are developing for Bitcoin Core, or another
@@ -783,7 +783,7 @@ applications. Finally, once you are confident your code works as
 expected, switch to +mainnet+ to deploy it in production. As you make
 changes, improvements, bug fixes, etc., start the pipeline again,
 deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally
-into production.((("", startref="BCTtest09")))
+into production.
 
 Now that we know what data the blockchain contains and how cryptographic
 commitments securely tie the various parts together, we will look at the

fees.adoc

@@ -611,7 +611,7 @@ and make a miner very happy, this is probably not what you intended.
 
 [WARNING]
 ====
-((("warnings and cautions", "change outputs")))If you forget to add a
+If you forget to add a
 change output in a manually constructed transaction, you will be paying
 the change as a transaction fee. "Keep the change!" might not be what
 you intended.
@@ -622,8 +622,8 @@ you intended.
 
 ((("scripting", "timelocks", "defense against
 fee-sniping")))((("timelocks", "defense against
-fee-sniping")))((("fees", "fee sniping")))((("security", "defense
-against fee-sniping")))((("sniping")))Fee-sniping is a theoretical
+fee-sniping")))((("security", "defense
+against fee-sniping")))Fee-sniping is a theoretical
 attack scenario, where miners attempting to rewrite past blocks "snipe"
 higher-fee transactions from future blocks to maximize their
 profitability.

glossary.asciidoc

@@ -192,7 +192,7 @@ RIPEMD-160::
     RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more.
 
 satoshi::
-    A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("satoshi")))
+    A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. 
 
 Satoshi Nakamoto::
     Satoshi Nakamoto is the name used by the person or people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown.

intro.adoc

@@ -2,7 +2,7 @@
 [[ch01_intro_what_is_bitcoin]]
 == Introduction
 
-((("bitcoin", "defined", id="GSdefine01")))Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible.
+Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible.
 
 [TIP]
 ====
@@ -71,18 +71,18 @@ Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer netw
 
 * A decentralized peer-to-peer network (the Bitcoin protocol)
 * A public transaction journal (the blockchain)
-* ((("mining and consensus", "consensus rules", "satisfying")))A set of rules for independent transaction validation and currency issuance (consensus rules)
+* A set of rules for independent transaction validation and currency issuance (consensus rules)
 * A mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm)
 
 As a developer, I see Bitcoin as akin to the internet of money, a network for propagating value and securing the ownership of digital assets via distributed computation. There's a lot more to Bitcoin than first meets the eye.
 
-In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol.((("", startref="GSdefine01")))
+In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol.
 
 [role="pagebreak-before less_space"]
 .Digital Currencies Before Bitcoin
 ****
 
-((("digital currencies", "prior to bitcoin")))The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
+The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
 
 1.     Can I trust that the money is authentic and not counterfeit?
 2.     Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
@@ -92,13 +92,13 @@ Issuers of paper money are constantly battling the counterfeiting problem by usi
 
 When cryptography started becoming more broadly available and understood in the late 1980s, many researchers began trying to use cryptography to build digital currencies. These early digital currency projects issued digital money, usually backed by a national currency or precious metal such as gold.
 
-((("decentralized systems", "vs. centralized", secondary-sortas="centralized")))Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted.
+Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted.
 
 ****
 
 === History of Bitcoin
 
-((("Nakamoto, Satoshi")))((("distributed computing")))((("bitcoin",
+((("bitcoin",
 "history of")))Bitcoin was first described in 2008 with the publication of a
 paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
 System,"footnote:["Bitcoin: A Peer-to-Peer Electronic Cash System,"
@@ -107,13 +107,13 @@ alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
 combined several prior inventions such as digital signatures and Hashcash to create
 a completely decentralized electronic cash system that does not rely on
 a central authority for currency issuance or settlement and validation
-of transactions. ((("Proof-of-Work algorithm")))((("decentralized
+of transactions. ((("decentralized
 systems", "consensus in")))((("mining and consensus", "Proof-of-Work
 algorithm")))A key innovation was to use a distributed computation
 system (called a "Proof-of-Work" algorithm) to conduct a global
 lottery every 10 minutes on average, allowing the decentralized network to
 arrive at _consensus_ about the state of transactions. ((("double-spend
-problem")))((("spending bitcoin", "double-spend problem")))This
+problem")))This
 elegantly solves the issue of double-spend where a single currency unit
 can be spent twice. Previously, the double-spend problem was a weakness
 of digital currency and was addressed by clearing all transactions
@@ -127,12 +127,12 @@ increased exponentially, and their combined computational power now
 exceeds the combined number of computing operations of the
 world's top supercomputers.
 
-Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. ((("open source licenses")))However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
+Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
 
 
 .A Solution to a Distributed Computing Problem
 ****
-((("Byzantine Generals&#x27; Problem")))Satoshi Nakamoto's invention is
+Satoshi Nakamoto's invention is
 also a practical and novel solution to a problem in distributed
 computing, known as the "Byzantine Generals' Problem." Briefly, the
 problem consists of trying to get multiple participants without a leader
@@ -162,7 +162,7 @@ derived from the original implementation written by Satoshi Nakamoto.
 
 ==== Choosing a Bitcoin Wallet
 
-((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
+Bitcoin wallets are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
 
 ===== Types of Bitcoin wallets
 Bitcoin wallets can be categorized as follows, according to the platform:
@@ -204,7 +204,7 @@ hardware signing device.
 ===== Full-node vs. Lightweight
 Another way to categorize Bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network:
 
-Full-node:: ((("full-node")))A full node is a program that validates the
+Full-node:: A full node is a program that validates the
 entire history of Bitcoin transactions (every transaction by every user,
 ever).  Optionally, full nodes can also store previously validated
 transactions and serve data to other Bitcoin programs, either on the
@@ -213,14 +213,14 @@ computer resources--about the same as watching an hour-long streaming
 video for each day of Bitcoin transactions--but the full node offers
 complete autonomy to its users.
 
-Lightweight client:: ((("lightweight clients")))
+Lightweight client:: 
 A lightweight client, also known as a simplified-payment-verification (SPV) client,
 connects to a full node or other remote server for receiving and sending
 Bitcoin transaction information, but stores the user wallet locally,
 partially validates the transactions it receives, and independently
 creates outgoing transactions.
 
-Third-party API client:: ((("third-party API clients")))A third-party
+Third-party API client:: A third-party
 API client is one that interacts with Bitcoin through a third-party
 system of application programming interfaces (APIs), rather than by
 connecting to the Bitcoin network directly. The wallet may be stored by
@@ -363,11 +363,11 @@ ensure you aren't being phished.
 
 ==== Bitcoin addresses
 
-Alice is now ready to start using her new Bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
+Alice is now ready to start using her new Bitcoin wallet.  Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
 
 [TIP]
 ====
-((("addresses", "security of")))((("security", "bitcoin addresses")))There
+There
 are a variety of Bitcoin addresses and invoice formats.  Addresses and
 invoices can be shared with other Bitcoin users
 who can use them to send bitcoins directly to your wallet.  You can share
@@ -402,7 +402,7 @@ bitcoin-accepting charity.
 [[getting_first_bitcoin]]
 ==== Getting Your First Bitcoin
 
-((("getting started", "acquiring bitcoin")))The first task for new users is to acquire some bitcoin.
+The first task for new users is to acquire some bitcoin.
 
 Bitcoin transactions are irreversible. Most electronic payment networks such as credit cards, debit cards, PayPal, and bank account transfers are reversible. For someone selling bitcoin, this difference introduces a very high risk that the buyer will reverse the electronic payment after they have received bitcoin, in effect defrauding the seller. To mitigate this risk, companies accepting traditional electronic payments in return for bitcoin usually require buyers to undergo identity verification and credit-worthiness checks, which may take several days or weeks. As a new user, this means you cannot buy bitcoin instantly with a credit card. With a bit of patience and creative thinking, however, you won't need to.
 
@@ -411,15 +411,15 @@ Here are some methods for acquiring bitcoin as a new user:
 
 * Find a friend who has bitcoins and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoins is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com].
 * Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoins.
-* ((("Coin ATM Radar")))((("ATMs, locating")))Use a Bitcoin ATM in your city.  A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet.
-* ((("exchange rates", "listing services")))Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency.
+* Use a Bitcoin ATM in your city.  A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet.
+* Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency.
 
 [TIP]
 ====
-((("privacy, maintaining")))((("security", "maintaining
-privacy")))((("digital currencies", "currency exchanges")))((("currency
+((("security", "maintaining
+privacy")))((("currency
 exchanges")))((("digital currencies", "benefits of
-bitcoin")))((("bitcoin", "benefits of")))One of the advantages of
+bitcoin")))One of the advantages of
 Bitcoin over other payment systems is that, when used correctly, it
 affords users much more privacy. Acquiring, holding, and spending
 bitcoin does not require you to divulge sensitive and personally
@@ -440,14 +440,14 @@ Alice was introduced to Bitcoin by a friend so she has an easy way to acquire he
 [[bitcoin_price]]
 ==== Finding the Current Price of Bitcoin
 
-((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price
+Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price
 of bitcoins?" The short answer is that the price is set by markets.
 
-((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
+Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
 
 There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular:
 
-https://bitcoinaverage.com/[Bitcoin Average]:: ((("BitcoinAverage")))A site that provides a simple view of the volume-weighted-average for each currency.
+https://bitcoinaverage.com/[Bitcoin Average]:: A site that provides a simple view of the volume-weighted-average for each currency.
 https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoins.
 https://www.cmegroup.com/markets/cryptocurrencies/cme-cf-cryptocurrency-benchmarks.html?redirect=/trading/cryptocurrency-indices/cf-bitcoin-reference-rate.html[Chicago Mercantile Exchange Bitcoin Reference Rate]:: A reference rate that can be used for institutional and contractual reference, provided as part of investment data feeds by the CME.
 
@@ -460,7 +460,7 @@ currencies.
 
 ((("getting started", "sending and receiving bitcoin",
 id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start
-example")))((("spending bitcoin", see="also transactions")))Alice has
+example")))Alice has
 decided to buy 0.001 bitcoins. After she and Joe check the exchange rate,
 she gives Joe an appropriate amount of cash, opens her mobile wallet
 application, and selects Receive. This
@@ -511,7 +511,7 @@ transaction, Alice's wallet will indicate that it is receiving
 [[confirmations]]
 .Confirmations
 ****
-((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
+At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
 ****
 
-Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))
+Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail.

keys.adoc

@@ -29,7 +29,7 @@ the addresses used by modern Bitcoin software.
 === Public Key Cryptography
 
 ((("keys and addresses", "overview of", "public key
-cryptography")))((("digital currencies", "cryptocurrency")))Public key
+cryptography")))Public key
 cryptography was invented in the 1970s and is a mathematical foundation
 for modern computer and information security.
 
@@ -56,14 +56,14 @@ revealing the private key.
 
 [TIP]
 ====
-((("keys and addresses", "overview of", "key pairs")))In some wallet
+In some wallet
 implementations, the private and public keys are stored together as a
 _key pair_ for convenience. However, the public key can be calculated
 from the private key, so storing only the private key is also possible.
 ====
 
 ((("keys and addresses", "overview of", "private and public key
-pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic
+pairs")))((("cryptography", "elliptic
 curve cryptography")))A Bitcoin wallet contains a collection of key
 pairs, each consisting of a private key and a public key. The private
 key (k) is a number, usually derived from a number picked at random.
@@ -73,8 +73,8 @@ generate a public key (K).
 
 .Why Use Asymmetric Cryptography (Public/Private Keys)?
 ****
-((("cryptography", "asymmetric")))((("digital signatures", "asymmetric
-cryptography and")))((("asymmetric cryptography")))Why is asymmetric
+((("digital signatures", "asymmetric
+cryptography and")))Why is asymmetric
 cryptography used in Bitcoin? It's not used to "encrypt" (make secret)
 the transactions. Rather, a useful property of asymmetric cryptography
 is the ability to generate _digital signatures_. A private key can be
@@ -92,7 +92,7 @@ signatures.
 ==== Private Keys
 
 ((("keys and addresses", "overview of", "private key
-generation")))((("warnings and cautions", "private key protection")))A
+generation")))A
 private key is simply a number, picked at random.  Control
 over the private key is the root of user control over all funds
 associated with the corresponding Bitcoin public key. The private key is
@@ -136,7 +136,7 @@ Otherwise, we simply try again with another random number.
 
 [WARNING]
 ====
-((("random numbers", "random number generation")))((("entropy", "random
+((("entropy", "random
 number generation")))Do not write your own code to create a random
 number or use a "simple" random number generator offered by your
 programming language. Use a cryptographically secure pseudorandom number
@@ -288,13 +288,13 @@ Now that we have defined addition, we can define multiplication in the
 standard way that extends addition. For a point P on the elliptic curve,
 if k is a whole number, then kP = P + P + P + ... + P (k times). Note
 that k is sometimes confusingly called an "exponent" in this case.((("",
-startref="eliptic04")))((("", startref="Celliptic04")))
+startref="eliptic04")))
 
 [[public_key_derivation]]
 ==== Public Keys
 
 ((("keys and addresses", "overview of", "public key
-calculation")))((("generator point")))The public key is calculated from
+calculation")))The public key is calculated from
 the private key using elliptic curve multiplication, which is
 irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
 constant point called the _generator point_, and _K_ is the resulting
@@ -317,7 +317,7 @@ signatures that prove control over bitcoin funds.
 ====
 
 ((("keys and addresses", "overview of", "public key
-generation")))((("generator point")))Starting with a private key in the
+generation")))Starting with a private key in the
 form of a randomly generated number _k_, we multiply it by a
 predetermined point on the curve called the _generator point_ _G_ to
 produce another point somewhere else on the curve, which is the
@@ -379,7 +379,7 @@ geometric operation on the curve.
 
 [TIP]
 ====
-((("OpenSSL cryptographic library")))Many Bitcoin implementations use
+Many Bitcoin implementations use
 the https://github.com/bitcoin-core/secp256k1[libsecp256k1 crytographic
 library] to do the elliptic curve math.
 ====
@@ -727,7 +727,7 @@ image::images/mbc2_0405.png["pubkey_to_address"]
 
 //https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-November/000778.html
 
-((("public and private keys", "compressed public keys")))
+
 When Bitcoin was first authored, its developers only knew how to create
 65-byte public keys.  However, a later developer became aware of an
 alternative encoding for public keys that used only 33 bytes and which
@@ -1375,7 +1375,7 @@ support for new Bitcoin features as soon as they become available.
 [[priv_formats]]
 ==== Private key formats
 
-((("public and private keys", "private key formats")))The private key
+The private key
 can be represented in a number of different formats, all of which
 correspond to the same 256-bit number. <<table_4-2>> shows several common
 formats used to represent private keys. Different formats are used in
@@ -1438,7 +1438,7 @@ can easily be converted to any other format.
 [[comp_priv]]
 ===== Compressed private keys
 
-((("public and private keys", "compressed private keys")))
+
 the commonly used term "compressed private key" is a misnomer, because when a private
 key is exported as WIF-compressed it is actually one byte _longer_ than
 an "uncompressed" private key. That is because the private key has an
@@ -1500,14 +1500,14 @@ from older wallets.
 
 === Advanced Keys and Addresses
 
-((("keys and addresses", "advanced forms", id="KAadvanced04")))In the
+In the
 following sections we will look at advanced forms of keys and addresses,
 such as vanity addresses and paper wallets.
 
 ==== Vanity Addresses
 
 ((("keys and addresses", "advanced forms", "vanity
-addresses")))((("vanity addresses", id="vanity04")))((("addresses",
+addresses")))((("addresses",
 "vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin
 addresses that contain human-readable messages. For example,
 +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
@@ -1603,7 +1603,7 @@ repeat until successful.
 
 ===== Vanity address security and privacy
 
-((("security", "vanity addresses")))Vanity addresses were popular in the
+Vanity addresses were popular in the
 early years of Bitcoin but have almost entirely disappeared from use as
 of 2023.  There are two likely causes for this trend:
 
@@ -1634,7 +1634,7 @@ the future unless the above problems are solved.
 [[paper_wallets]]
 ==== Paper Wallets
 
-((("keys and addresses", "advanced forms", "paper wallets")))((("paper
+((("paper
 wallets", id="paperw04")))((("wallets", "types of", "paper wallets",
 id="Wpaper04")))Paper wallets are private keys printed on paper.
 Often the paper wallet also includes the corresponding Bitcoin address
@@ -1679,8 +1679,8 @@ opaque scratch-off stickers, or folded and sealed with tamper-proof
 adhesive foil.  Other designs feature additional copies of the key and
 address, in the form of detachable stubs similar to ticket stubs,
 allowing you to store multiple copies to protect against fire, flood, or
-other natural disasters.((("", startref="KAadvanced04")))((("",
-startref="Wpaper04")))((("", startref="paperw04")))
+other natural disasters.((("",
+startref="Wpaper04")))
 
 [[paper_wallet_spw]]
 .An example of a paper wallet with additional copies of the keys on a backup "stub"

mining.adoc

@@ -1,7 +1,7 @@
 [[mining]]
 == Mining and Consensus
 
-((("mining and consensus", "purpose of")))The word "mining" is somewhat
+The word "mining" is somewhat
 misleading. By evoking the extraction of precious metals, it focuses our
 attention on the reward for mining, the new bitcoins created in each
 block. Although mining is incentivized by this reward, the primary
@@ -13,17 +13,17 @@ transactions are validated and cleared. Mining is one of the inventions that
 makes Bitcoin special, a decentralized consensus mechanism that is the
 basis for P2P digital cash.
 
-((("mining and consensus", "decentralized consensus")))((("central
+((("central
 trusted authority")))Mining _secures the Bitcoin system_ and enables the
 emergence of network-wide _consensus without a central authority_.
-((("fees", "transaction fees")))The reward of newly minted bitcoins and
+The reward of newly minted bitcoins and
 transaction fees is an incentive scheme that aligns the actions of
 miners with the security of the network, while simultaneously
 implementing the monetary supply.
 
 [TIP]
 ====
-((("decentralized systems", "bitcoin mining and")))
+
 Mining
 is one of the mechanisms by which Bitcoin's _consensus security_ is _decentralized_.
 ====
@@ -52,8 +52,8 @@ In some protocols built on top of Bitcoin, the topological order of
 Bitcoin transactions is also used to establish a sequence of events;
 we'll discuss that idea further in <<single_use_seals>>.
 
-((("fees", "mining rewards")))((("mining and consensus", "mining rewards
-and fees")))((("Proof-of-Work algorithm")))((("mining and consensus",
+((("mining and consensus", "mining rewards
+and fees")))((("mining and consensus",
 "Proof-of-Work algorithm")))Miners receive two types of rewards in
 return for the security provided by mining: new bitcoins created with each
 new block (called the _subsidy_), and transaction fees from all the transactions included in
@@ -103,7 +103,7 @@ consensus.
 === Bitcoin Economics and Currency Creation
 
 ((("mining and consensus", "bitcoin economics and currency
-creation")))((("currency creation")))((("money supply")))((("issuance
+creation")))((("issuance
 rate")))Bitcoin are minted during the creation of each block at a
 fixed and diminishing rate. Each block, generated on average every 10
 minutes, contains entirely new bitcoins, created from nothing. Every
@@ -168,7 +168,7 @@ to inflate the supply of bitcoin.
 
 .Deflationary Money
 ****
-((("deflationary money")))The most important and debated consequence of
+The most important and debated consequence of
 fixed and diminishing monetary issuance is that the currency tends to be
 inherently _deflationary_. Deflation is the phenomenon of appreciation
 of value due to a mismatch in supply and demand that drives up the value
@@ -206,7 +206,7 @@ outweighs the risks of deflation.
 
 === Decentralized Consensus
 
-((("mining and consensus", "decentralized consensus")))((("decentralized
+((("decentralized
 systems", "consensus in")))In the previous chapter we looked at the
 blockchain, the global list of all transactions, which
 everyone in the Bitcoin network accepts as the authoritative record of
@@ -226,7 +226,7 @@ and assemble a copy of the same blockchain as everyone else. This
 chapter examines the process by which the Bitcoin network achieves
 global consensus without central authority.
 
-((("emergent consensus")))((("mining and consensus", "emergent
+((("mining and consensus", "emergent
 consensus")))One of Satoshi Nakamoto's inventions is the decentralized
 mechanism for _emergent consensus_. Emergent, because consensus is not
 achieved explicitly—there is no election or fixed moment when consensus
@@ -261,7 +261,7 @@ trusted, public, global blockchain.
 === Independent Verification of Transactions
 
 ((("mining and consensus", "independent transaction
-verification")))((("transactions", "independent verification of")))In
+verification")))In
 <<c_transactions>>, we saw how wallet software creates transactions by
 collecting UTXOs, providing the appropriate authentication data, and then
 constructing new outputs assigned to a new owner. The resulting
@@ -316,7 +316,7 @@ _mempool_.
 
 === Mining Nodes
 
-((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining
+((("Bitcoin nodes", "mining
 nodes")))Some of the nodes on the Bitcoin network are specialized nodes
 called _miners_. Jing is a
 Bitcoin miner; he
@@ -334,7 +334,7 @@ containing Alice's transaction was mined by Jing's mining system and
 follow Alice's transaction as it becomes part of this new block.
 
 Jing's mining node maintains a local copy of the blockchain. By the time
-((("use cases", "buying coffee")))Alice buys something, Jing's
+Alice buys something, Jing's
 node is caught up with the chain of blocks with the most proof-of-work.
 Jing's node is listening
 for transactions, trying to mine a new block and also listening for
@@ -352,7 +352,7 @@ transactions in the memory pool and remove any that were included in
 that block. Whatever transactions remain in the memory pool are
 unconfirmed and are waiting to be recorded in a new block.
 
-((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work
+((("mining and consensus", "Proof-of-Work
 algorithm")))Jing's node immediately constructs a new partial block, a
 candidate for the next block. This block is called a _candidate block_
 because it is not yet a valid block, as it does not contain a valid
@@ -365,7 +365,7 @@ transaction fees he'll attempt to claim.
 
 ==== The Coinbase Transaction
 
-((("coinbase transactions", id="coinbtrans10")))((("transactions",
+((("transactions",
 "coinbase transactions", id="Tcoinb10")))The first transaction in any
 block is a special transaction, called a _coinbase transaction_. This
 transaction is constructed by Jing's node and pays out his _reward_ for
@@ -389,8 +389,8 @@ reward.
 
 ==== Coinbase Reward and Fees
 
-((("coinbase transactions", "rewards and fees")))((("fees", "transaction
-fees")))((("mining and consensus", "rewards and fees")))To construct the
+((("fees", "transaction
+fees")))To construct the
 coinbase transaction, Jing's node first calculates the total amount of
 transaction fees:
 
@@ -430,7 +430,7 @@ The initial subsidy is calculated in satoshis by multiplying 50 with the
 +COIN+ constant (100,000,000 satoshis). This sets the initial reward
 (+nSubsidy+) at 5 billion satoshis.
 
-((("halvings")))Next, the function calculates the number of +halvings+
+Next, the function calculates the number of +halvings+
 that have occurred by dividing the current block height by the halving
 interval (+SubsidyHalvingInterval+).
 
@@ -458,7 +458,7 @@ only gets to spend the reward if the block is accepted by everyone.
 
 ==== Structure of the Coinbase Transaction
 
-((("coinbase transactions", "structure of")))With these calculations,
+With these calculations,
 Jing's node then constructs the coinbase transaction to pay himself
 the block reward.
 
@@ -504,14 +504,14 @@ the miners, as we will see next.
 [[duplicate_transactions]]
 ==== Coinbase Data
 
-((("coinbase transactions", "coinbase data")))Coinbase transactions do
+Coinbase transactions do
 not have an input script field. Instead, this
 field is replaced by coinbase data, which must be between 2 and 100
 bytes. Except for the first few bytes, the rest of the coinbase data can
 be used by miners in any way they want; it is arbitrary data.
 
-((("nonce values")))((("blocks", "genesis block")))((("blockchain
-(the)", "genesis block")))((("genesis block")))In the genesis block, for
+((("blockchain
+(the)", "genesis block")))In the genesis block, for
 example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
 Chancellor on brink of second bailout for banks" in the coinbase data,
 using it as a proof of the earliest date this block chould have been
@@ -526,8 +526,8 @@ version field set to 2 or higher) must contain the block height as a script
 
 === Constructing the Block Header
 
-((("mining and consensus", "constructing block headers")))((("blocks",
-"headers")))((("headers")))((("blockchain (the)", "block headers")))To
+((("blocks",
+"headers")))To
 construct the block header, the mining node needs to fill in six fields,
 as listed in <<block_header_structure_ch10>>.
 
@@ -564,7 +564,7 @@ Today, VersionBits field has no meaning unless there's an attempt to
 upgrade the consensus protocol underway, in which case you will need to
 read its documentation to determine how it is using VersionBits.
 
-((("blocks", "parent blocks")))((("parent blocks")))Next, the mining
+Next, the mining
 node needs to add the "Previous Block Hash" (also known as +prevhash+).
 That is the hash of the block header of the previous block
 received from the network, which Jing's node has accepted and
@@ -577,7 +577,7 @@ Block Hash field in the candidate block header, Jing is committing his
 mining power to extending the chain that ends in that specific block.
 ====
 
-((("merkle trees")))((("blockchain (the)", "merkle trees")))The next
+The next
 step is to commit to all the transactions using merkle trees.  Each
 transaction is listed using its witness transaction identifier (_wtxid_)
 in topographical order, with 32 0x00 bytes standing in for the wtxid of
@@ -622,15 +622,15 @@ the header before a version is found that satisfies the requirement.
 
 === Mining the Block
 
-((("mining and consensus", "mining the block", id="MACmining10")))Now
+Now
 that a candidate block has been constructed by Jing's node, it is time
 for Jing's hardware mining rig to "mine" the block, to find a solution
 to the Proof-of-Work algorithm that makes the block valid. Throughout
 this book we have studied cryptographic hash functions as used in
 various aspects of the Bitcoin system. The hash function SHA256 is the
-function used in Bitcoin's mining process.((("", startref="jingten")))
+function used in Bitcoin's mining process.
 
-((("mining and consensus", "defined")))In the simplest terms, mining is
+In the simplest terms, mining is
 the process of hashing the candidate block header repeatedly, changing one
 parameter, until the resulting hash matches a specific target. The hash
 function's result cannot be determined in advance, nor can a pattern be
@@ -641,14 +641,14 @@ until the desired hash result appears by chance.
 
 ==== Proof-of-Work Algorithm
 
-((("Proof-of-Work algorithm", id="proof10")))((("mining and consensus",
+((("mining and consensus",
 "Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an
 arbitrary-length data input and produces a fixed-length deterministic
 result, called a _digest_.  The digest is a digital commitment to the
 input. For any specific input, the resulting digest will always be the
 same and can be easily calculated and
 verified by anyone implementing the same hash algorithm.
-((("collisions")))A key characteristic of a cryptographic hash
+A key characteristic of a cryptographic hash
 algorithm is that it is computationally infeasible to find two different
 inputs that produce the same digest (known as a _collision_). As a
 corollary, it is also virtually impossible to select an input in such a
@@ -753,7 +753,7 @@ the target. A lower target means it is more difficult to find a hash
 below the target. The target and difficulty are inversely related.
 ====
 
-((("targets")))Bitcoin's Proof-of-Work is very similar to the challenge
+Bitcoin's Proof-of-Work is very similar to the challenge
 shown in <<sha256_example_generator_output>>. The miner constructs a
 candidate block filled with transactions. Next, the miner calculates the
 hash of this block's header and sees if it is smaller than the current
@@ -769,7 +769,7 @@ enough block header hash.
 //TODO:use visual representation like I did on bitcoin.org
 
 ((("mining and consensus", "mining the block", "target
-representation")))((("targets", id="targets10")))
+representation")))
 Block headers contain the target in a notation called "target
 bits" or just "bits," which in block 277,316 has the value of
 +0x1903a30c+. This notation expresses the Proof-of-Work target as a
@@ -929,7 +929,7 @@ electricity into hashing computation at the highest rate possible. The
 primary influence on the mining market is the price of one kilowatt-hour
 of electricity in bitcoin, because that determines the profitability of
 mining and therefore the incentives to enter or exit the mining
-market.((("", startref="targets10")))
+market.
 
 [[mtp]]
 === Median Time Past (MTP)
@@ -988,7 +988,7 @@ sequence, +CLTV+, and +CSV+.
 === Successfully Mining the Block
 
 ((("mining and consensus", "mining the block", "successful
-completion")))((("use cases", "mining for bitcoin", id="jingtentwo")))As
+completion")))As
 we saw earlier, Jing's node has constructed a candidate block and
 prepared it for mining. Jing has several hardware mining rigs with
 application-specific integrated circuits, where hundreds of thousands of
@@ -1021,12 +1021,12 @@ chain it extends.
 In the next section, we'll look at the process each node uses to
 validate a block and select the most-work chain, creating the consensus
 that forms the decentralized blockchain.((("",
-startref="MACmining10")))((("", startref="jingtentwo")))
+startref="MACmining10")))
 
 === Validating a New Block
 
-((("mining and consensus", "new block validation")))((("blocks", "new
-block validation")))((("validation")))The third step in Bitcoin's
+((("blocks", "new
+block validation")))The third step in Bitcoin's
 consensus mechanism is independent validation of each new block by every
 node on the network. As the newly solved block moves across the network,
 each node performs a series of tests to validate it.
@@ -1154,8 +1154,8 @@ forks (in addition to other problems), so many people prefer Bitcoin's
 ====
 
 ((("",
-startref="Bassemble10")))((("", startref="MACassembling10")))((("",
-startref="forks10")))((("", startref="BCTfork10")))
+startref="Bassemble10")))((("",
+startref="forks10")))
 
 === Mining and the Hash Lottery
 
@@ -1181,7 +1181,7 @@ a rapid pace.
 [[extra_nonce]]
 ==== The Extra Nonce Solution
 
-((("nonce values")))Since 2012, mining has evolved to resolve a
+Since 2012, mining has evolved to resolve a
 fundamental limitation in the structure of the block header. In the
 early days of Bitcoin, a miner could find a block by iterating through
 the nonce until the resulting hash was below the target. As difficulty
@@ -1222,7 +1222,7 @@ entire left flank of the merkle tree up to the root.
 [[mining_pools]]
 ==== Mining Pools
 
-((("mining pools", id="MACoverpool10")))((("mining pools", "benefits
+((("mining pools", "benefits
 of")))In this highly competitive environment, individual miners working
 alone (also known as solo miners) don't stand a chance. The likelihood
 of them finding a block to offset their electricity and hardware costs
@@ -1263,7 +1263,7 @@ the miners' Bitcoin addresses, once their share of the rewards has
 reached a certain threshold. Typically, the pool server charges a
 percentage fee of the rewards for providing the pool-mining service.
 
-((("mining pools", "operation of")))Miners participating in a pool split
+Miners participating in a pool split
 the work of searching for a solution to a candidate block, earning
 "shares" for their mining contribution. The mining pool sets a higher
 target (lower difficulty) for earning a share, typically more than 1,000
@@ -1322,7 +1322,7 @@ whole pool wins.
 
 ===== Managed pools
 
-((("mining pools", "managed pools")))((("pool operators",
+((("pool operators",
 seealso="mining pools")))Most mining pools are "managed," meaning that
 there is a company or individual running a pool server. The owner of the
 pool server is called the _pool operator_, and he charges pool miners a
@@ -1356,7 +1356,7 @@ using their own full node.
 
 ===== Peer-to-peer mining pool (P2Pool)
 
-((("mining pools", "peer-to-peer pools (P2Pool)")))((("peer-to-peer
+((("peer-to-peer
 pools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by
 the pool operator, who might direct the pool effort to double-spend
 transactions or invalidate blocks (see <<consensus_attacks>>).
@@ -1403,7 +1403,7 @@ robust overall, as part of a diversified mining ecosystem.  As of this
 writing, P2Pool has fallen into disuse, but new protocols such as
 Stratum v2 can allow individual miners to choose the transactions they
 include in their blocks.((("",
-startref="MAChash10")))((("", startref="MACoverpool10")))
+startref="MAChash10")))
 
 [[consensus_attacks]]
 === Hashrate Attacks
@@ -1486,7 +1486,7 @@ original payment to Carol. Carol is now missing the three paintings and
 also has no payment. Throughout all this activity, Paul's mining
 pool participants might remain blissfully unaware of the double-spend
 attempt, because they mine with automated miners and cannot monitor
-every transaction or block.((("", startref="carolten")))
+every transaction or block.
 
 ((("confirmations", "of large-value transactions",
 secondary-sortas="large-value transactions")))To protect against this
@@ -1575,7 +1575,7 @@ between all participants.
 [[hard_forks]]
 ==== Hard Forks
 
-((("forks", "changing consensus rules", id="forks10a")))((("forks",
+((("forks",
 "changing consensus rules", "hard forks")))In <<forks>> we looked at how
 the Bitcoin network may briefly diverge, with two parts of the network
 following two different branches of the blockchain for a short time. We
@@ -1644,7 +1644,7 @@ valid block.
 
 ==== Hard Forks: Software, Network, Mining, and Chain
 
-((("forks", "changing consensus rules", "software forks")))For software
+For software
 developers, the term "fork" has another meaning, adding confusion to the
 term "hard fork." In open source software, a fork occurs when a group of
 developers choose to follow a different software roadmap and start a
@@ -1740,7 +1740,7 @@ transactions.
 ==== Contentious Hard Forks
 
 ((("forks", "changing consensus rules", "contentious hard
-forks")))((("hard forks")))This is the dawn of the development of software
+forks")))This is the dawn of the development of software
 for decentralized consensus. Just as other innovations in development changed both the methods
 and products of software and created new methodologies, new tools, and
 new communities in its wake, consensus software development also
@@ -1765,7 +1765,7 @@ consensus modifications.
 
 ==== Soft Forks
 
-((("forks", "changing consensus rules", "soft forks")))((("soft forks",
+((("soft forks",
 "defined")))Not all consensus rule changes cause a hard fork. Only
 consensus changes that are forward-incompatible cause a fork. If the
 change is implemented in such a way that an unmodified client still sees
@@ -1792,7 +1792,7 @@ nonupgraded nodes out of consensus.
 
 ===== Soft forks redefining NOP opcodes
 
-((("opcodes", "redefinition by soft forks")))((("soft forks",
+((("soft forks",
 "redefinition of NOP codes")))Two soft forks have been
 implemented in Bitcoin, based on the re-interpretation of NOP opcodes.
 Bitcoin Script had ten opcodes reserved for future use, NOP1 through
@@ -1811,7 +1811,7 @@ the old clients, the script contains an NOP code, which is ignored.
 
 ==== Criticisms of Soft Forks
 
-((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft
+((("soft
 forks", "drawbacks of")))Soft forks based on the NOP opcodes are
 relatively uncontroversial. The NOP opcodes were placed in Bitcoin
 Script with the explicit goal of allowing non-disruptive upgrades.
@@ -1840,13 +1840,13 @@ a loss of funds under the old rules. For example, if a CLTV transaction
 is evaluated under the old rules, there is no timelock constraint and it
 can be spent at any time. Therefore, critics contend that a failed soft
 fork that had to be reversed because of a bug would almost certainly
-lead to loss of funds.((("", startref="Crule10")))
+lead to loss of funds.
 
 [[softforksignaling]]
 === Soft Fork Signaling with Block Version
 
 ((("forks", "changing consensus rules", "soft fork
-activation")))((("soft forks", "activation")))Since soft forks allow
+activation")))Since soft forks allow
 unmodified clients to continue to operate within consensus, one
 mechanism for "activating" a soft fork is through miners signaling that
 they are ready and willing to enforce the new consensus rules.  If
@@ -2006,7 +2006,7 @@ image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram]
 
 BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
 and associated BIPs (68, 112, 113). The proposal named "csv" was
-activated successfully in July of 2016.((("", startref="forks10a")))
+activated successfully in July of 2016.
 
 The standard is defined in
 https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9
@@ -2117,7 +2117,7 @@ state of this system with only a few changes possible if there is strong
 consensus by a very large majority. The 95% threshold for soft forks is
 reflective of this reality.
 
-((("hard forks")))It is important to recognize that there is no perfect
+It is important to recognize that there is no perfect
 solution for consensus development. Both hard forks and soft forks
 involve tradeoffs. For some types of changes, soft forks may be a better
 choice; for others, hard forks may be a better choice. There is no

network.adoc

@@ -1,7 +1,7 @@
 [[bitcoin_network_ch08]]
 == The Bitcoin Network
 
-((("Bitcoin network", "peer-to-peer architecture")))((("peer-to-peer
+((("peer-to-peer
 (P2P)")))Bitcoin is structured as a peer-to-peer network architecture on
 top of the internet. The term peer-to-peer, or P2P, means that the
 full nodes which participate in the network are peers to each other, that
@@ -26,7 +26,7 @@ characteristic. Decentralization of control is a core design principle
 that can only be achieved and maintained by a flat and decentralized P2P
 consensus network.
 
-((("Bitcoin network", "defined")))The term "Bitcoin network" refers to
+The term "Bitcoin network" refers to
 the collection of nodes running the Bitcoin P2P protocol. In addition to
 the Bitcoin P2P protocol, there are other protocols that
 are used for mining and lightweight wallets. These additional
@@ -55,8 +55,8 @@ only a subset of the blockchain and partly verify transactions using a method
 called _simplified payment verification_, or SPV. ((("lightweight
 clients")))These clients are known as lightweight clients.
 
-((("Bitcoin nodes", "mining nodes")))((("mining and consensus", "mining
-nodes")))((("Proof-of-Work algorithm")))((("mining and consensus",
+((("mining and consensus", "mining
+nodes")))((("mining and consensus",
 "Proof-of-Work algorithm")))Miners compete to create new blocks by
 running specialized hardware to solve the Proof-of-Work algorithm. Some
 miners operate full nodes, validating every block on the
@@ -74,7 +74,7 @@ mining pool protocols and lightweight client-access protocols.
 
 === The Network
 
-((("", startref="BNnode08")))((("", startref="BNtype08")))((("Bitcoin
+((("Bitcoin
 network", "extended network activities")))As of this writing, the main Bitcoin network,
 running the Bitcoin P2P protocol, consists of about 10,000
 listening nodes running various versions of Bitcoin Core and a few
@@ -249,7 +249,7 @@ several Virtual Private Servers (VPSes) hosted on
 infrastructure around the world and served to connect the majority of
 miners and mining pools.
 
-((("Fast Internet Bitcoin Relay Engine (FIBRE)")))((("Compact Block
+((("Compact Block
 optimization")))The original Bitcoin Relay Network was replaced in 2016
 with the introduction of the _Fast Internet Bitcoin Relay Engine_ or
 https://bitcoinfibre.org[_FIBRE_], also created by developer Matt
@@ -419,14 +419,14 @@ connection for too long, it is assumed to be disconnected
 and a new peer will be sought. Thus, the network dynamically adjusts to
 transient nodes and network problems, and can organically grow and
 shrink as needed without any central control.((("",
-startref="BNextend08")))((("", startref="BNodiscover08")))
+startref="BNextend08")))
 
 === Full Nodes
 
 Full nodes are nodes that verify every transaction in every block on the
 valid blockchain with the most proof of work.
 
-((("blocks", "genesis block")))((("genesis block")))((("blockchain
+((("blockchain
 (the)", "genesis block")))Full nodes
 independently process every block, starting after the very first
 block (genesis block) and building up to the latest known block in the
@@ -437,11 +437,11 @@ receive updates about new blocks of transactions, which it then verifies
 and incorporates into its local view of which scripts control which
 bitcoins, called the set of _unspent transaction outputs_ (UTXOs).
 
-((("Bitcoin nodes", "full nodes")))Running a full node gives
+Running a full node gives
 you the pure Bitcoin experience: independent verification of all
 transactions without the need to rely on, or trust, any other systems.
 
-((("Satoshi client")))There are a few alternative implementations of
+There are a few alternative implementations of
 full nodes, built using different programming
 languages and software architectures, or which made different design
 decisions. However, the most common
@@ -453,7 +453,7 @@ command +getpeerinfo+ as we saw earlier; for example, +/Satoshi:24.0.1/+.
 
 === Exchanging "Inventory"
 
-((("Bitcoin network", "syncing the blockchain")))The first thing a full
+The first thing a full
 node will do once it connects to peers is try to construct a complete
 chain of block headers. If it is a brand-new node and has no blockchain at all, it
 only knows one block, the genesis block, which is statically embedded in
@@ -461,7 +461,7 @@ the client software. Starting after block #0 (the genesis block), the new
 node will have to download hundreds of thousands of blocks to
 synchronize with the network and reestablish the full blockchain.
 
-((("blockchain (the)", "syncing the blockchain")))((("syncing")))The
+The
 process of syncing the blockchain starts with the +version+ message,
 because that contains +BestHeight+, a node's current blockchain height
 (number of blocks). A node will see the +version+ messages from its
@@ -607,13 +607,13 @@ incoming and outgoing transactions.
 Bloom filters allow lightweight clients to receive a subset of
 the transactions without directly revealing precisely which addresses they are
 interested in, through a filtering mechanism that uses probabilities
-rather than fixed patterns.((("", startref="BNspvnodes08")))((("",
+rather than fixed patterns.((("",
 startref="simple08")))
 
 [[bloom_filters]]
 === Bloom Filters
 
-((("bitcoin network", "bloom filters", id="BNebloom08")))((("bloom
+((("bloom
 filters", id="bloom08")))((("privacy, maintaining",
 id="privacy08")))((("security", "maintaining privacy",
 id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way
@@ -742,7 +742,7 @@ them) that a lightweight client receives from its peers, selecting only
 transactions of interest to the lightweight client without revealing exactly which
 addresses or keys it is interested in.
 
-((("transaction IDs (txid)")))A lightweight client will initialize a bloom filter
+A lightweight client will initialize a bloom filter
 as "empty"; in that state the bloom filter will not match any patterns.
 The lightweight client will then make a list of all the addresses, keys, and
 hashes that it is interested in. It will do this by extracting the
@@ -751,7 +751,7 @@ controlled by its wallet. The lightweight client then adds each of these to the
 bloom filter, so that the bloom filter will "match" if these patterns
 are present in a transaction, without revealing the patterns themselves.
 
-((("Bitcoin nodes", "full nodes")))The lightweight client will then send a
+The lightweight client will then send a
 +filterload+ message to the peer, containing the bloom filter to use on
 the connection. On the peer, bloom filters are checked against each
 incoming transaction. The full node checks several parts of the
@@ -1139,7 +1139,7 @@ client.
 === Encrypted and Authenticated Connections
 
 ((("Bitcoin network", "encrypted
-connections")))((("encryption")))((("authentication")))Most new users of
+connections")))Most new users of
 Bitcoin assume that the network communications of a Bitcoin node are
 encrypted. In fact, the original implementation of Bitcoin communicates
 entirely in the clear, as does the modern implementation of Bitcoin Core
@@ -1151,7 +1151,7 @@ communications: _Tor Transport_.
 
 ==== Tor Transport
 
-((("Tor network")))((("The Onion Routing network (Tor)")))Tor, which
+Tor, which
 stands for _The Onion Routing network_, is a software project and
 network that offers encryption and encapsulation of data through
 randomized network paths that offer anonymity, untraceability and
@@ -1183,8 +1183,8 @@ online tutorials.
 [[mempool]]
 === Mempools and orphan pools
 
-((("Bitcoin network", "transaction pools")))((("transaction
-pools")))((("memory pools (mempools)")))Almost every node on the Bitcoin
+((("transaction
+pools")))Almost every node on the Bitcoin
 network maintains a temporary list of unconfirmed transactions called
 the _memory pool_ (_mempool_). Nodes use this pool
 to keep track of transactions that are known to the network but are not
@@ -1194,7 +1194,7 @@ As unconfirmed transactions are received and verified, they are added to the
 mempool and relayed to the neighboring nodes to propagate on
 the network.
 
-((("orphan pools")))((("transactions", "orphaned")))Some node
+Some node
 implementations also maintain a separate pool of orphaned transactions.
 If a transaction's inputs refer to a transaction that is not yet known,
 such as a missing parent, the orphan transaction will be stored

overview.adoc

@@ -1,7 +1,7 @@
 [[ch02_bitcoin_overview]]
 == How Bitcoin Works
 
-((("bitcoin", "overview of", id="BCover02")))((("central trusted
+((("central trusted
 authority")))((("decentralized systems", "bitcoin overview",
 id="DCSover02")))The Bitcoin system, unlike traditional banking and
 payment systems, does not require trust in third parties. Instead of a central
@@ -22,7 +22,7 @@ transactions that are propagated across the network, and miners who
 produce (through competitive computation) the consensus blockchain,
 which is the authoritative journal of all transactions.
 
-((("blockchain explorer sites")))Each example in this chapter is based
+Each example in this chapter is based
 on an actual transaction made on the Bitcoin network, simulating the
 interactions between several users by sending
 funds from one wallet to another. While tracking a transaction through
@@ -36,7 +36,7 @@ relationships and flows between them.
 .Bitcoin overview
 image::images/mbc2_0201.png["Bitcoin Overview"]
 
-((("Bitcoin Block Explorer")))Popular blockchain explorers include:
+Popular blockchain explorers include:
 
 * https://blockstream.info/[Blockstream Explorer]
 * https://mempool.space[Mempool.Space]
@@ -81,7 +81,7 @@ Alice is offered the option to pay with bitcoin, in addition to the
 usual options. The checkout cart displays the price in US dollars and
 also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.
 
-((("payment requests")))((("QR codes", "payment requests")))Bob's
+Bob's
 e-commerce system will automatically create a QR code containing an
 _invoice_ (<<invoice-QR>>).
 
@@ -103,7 +103,7 @@ image::images/mbc2_0202.png["payment-request"]
 
 [TIP]
 ====
-((("QR codes", "warnings and cautions")))((("transactions", "warnings
+((("transactions", "warnings
 and cautions")))((("warnings and cautions", "avoid sending money to
 addresses appearing in book")))Try to scan this with your wallet to see
 the address and amount but DO NOT SEND MONEY.
@@ -131,7 +131,7 @@ register.
 
 [NOTE]
 ====
-((("fractional values")))((("milli-bitcoin")))((("satoshis")))The
+The
 Bitcoin network can transact in fractional values, e.g., from
 millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a
 bitcoin, which is known as a satoshi.  This book uses the same
@@ -160,7 +160,7 @@ can spend that amount in subsequent transactions.
 
 === Bitcoin Transactions
 
-((("transactions", "defined")))In simple terms, a transaction tells the
+In simple terms, a transaction tells the
 network that the owner of certain bitcoins has authorized the transfer
 of that value to another owner. The new owner can now spend the bitcoin
 by creating another transaction that authorizes the transfer to another
@@ -168,12 +168,12 @@ owner, and so on, in a chain of ownership.
 
 ==== Transaction Inputs and Outputs
 
-((("transactions", "overview of", id="Tover02")))((("outputs and
+((("outputs and
 inputs", "basics of")))Transactions are like lines in a double-entry
 bookkeeping ledger.  Each transaction contains one or more _inputs_,
 which spend funds. On the other side of
 the transaction, there are one or more _outputs_, which receive funds.
-((("fees", "transaction fees")))The inputs
+The inputs
 and outputs do not necessarily add up to the same
 amount. Instead, outputs add up to slightly less than inputs and the
 difference represents an implied _transaction fee_, which is a small
@@ -184,7 +184,7 @@ blockchain. A Bitcoin transaction is shown as a bookkeeping ledger entry in
 The transaction also contains proof of ownership for each amount of
 bitcoins (inputs) whose value is being spent, in the form of a digital
 signature from the owner, which can be independently validated by
-anyone. ((("spending bitcoin", "defined")))In Bitcoin terms, spending
+anyone. In Bitcoin terms, spending
 is signing a transaction that transfers value from a previous
 transaction over to a new owner identified by a Bitcoin address.
 
@@ -194,7 +194,7 @@ image::images/mbc2_0203.png["Transaction Double-Entry"]
 
 ==== Transaction Chains
 
-((("chain of transactions")))Alice's payment to Bob's Store uses a
+Alice's payment to Bob's Store uses a
 previous transaction's output as its input. In the previous chapter,
 Alice received bitcoins from her friend Joe in return for cash.
 We've labeled that as _Transaction 1_ (Tx1) in <<transaction-chain>>.
@@ -252,7 +252,7 @@ that's what the protocol itself uses.
 
 ==== Making Change
 
-((("change, making")))((("change addresses")))((("addresses", "change
+((("addresses", "change
 addresses")))In addition to one or more outputs that pay the receiver of
 bitcoins, many transactions will also include an output that pays the
 spender of the bitcoins, called a _change_ output.
@@ -327,7 +327,7 @@ blockchain is _payment batching_ that pays to multiple outputs
 representing multiple recipients (<<transaction-distributing>>).
 This type of transaction is sometimes used by commercial entities to
 distribute funds, such as when processing payroll payments to multiple
-employees.((("", startref="Tover02")))
+employees.
 
 [[transaction-distributing]]
 .Batch transaction distributing funds
@@ -335,7 +335,7 @@ image::images/mbc2_0207.png["Distributing Transaction"]
 
 === Constructing a Transaction
 
-((("transactions", "constructing", id="Tconstruct02")))((("wallets",
+((("wallets",
 "constructing transactions")))Alice's wallet application contains all
 the logic for selecting inputs and generating outputs to build a
 transaction to Alice's specification. Alice only needs to choose a
@@ -349,7 +349,7 @@ while connected to the Bitcoin network.
 
 ==== Getting the Right Inputs
 
-((("outputs and inputs", "locating and tracking inputs")))Alice's wallet
+Alice's wallet
 application will first have to find inputs that can pay the amount she
 wants to send to Bob. Most wallets keep track of all the available
 outputs belonging to addresses in the wallet. Therefore, Alice's wallet
@@ -373,7 +373,7 @@ wallet application creates the transaction outputs (payments).
 
 ==== Creating the Outputs
 
-((("outputs and inputs", "creating outputs")))A transaction output is
+A transaction output is
 created with a
 script that says something like, "This output is paid to whoever can
 present a signature from the key corresponding to Bob's public address."
@@ -416,7 +416,7 @@ blocks are added.
 
 ===== Transmitting the transaction
 
-((("propagation", "process of")))Because the transaction contains all
+Because the transaction contains all
 the information necessary for it to be processed, it does not matter how or where it
 is transmitted to the Bitcoin network. The Bitcoin network is a
 peer-to-peer network, with each Bitcoin peer participating by
@@ -425,7 +425,7 @@ network is to propagate transactions and blocks to all participants.
 
 ===== How it propagates
 
-((("Bitcoin nodes", "defined")))((("nodes", see="Bitcoin nodes")))
+
 Peers in the Bitcoin peer-to-peer network are programs that have both
 the software logic and the data necessary for them to fully verify the
 correctness of a new transaction.  The connections between peers are
@@ -441,7 +441,7 @@ node.  Her Bitcoin wallet does not have
 to be connected to Bob's Bitcoin wallet directly and she does not have
 to use the internet connection offered by Bob, though both those
 options are possible, too. ((("propagation", "flooding
-technique")))((("flooding technique")))Any Bitcoin node that receives a
+technique")))Any Bitcoin node that receives a
 valid transaction it has not seen before will forward it to
 all other nodes to which it is connected, a propagation technique known
 as _gossiping_. Thus, the transaction rapidly propagates out across the
@@ -478,7 +478,7 @@ computation to verify as correct.
 The mining process serves two purposes in Bitcoin:
 
 * ((("mining and consensus", "consensus rules", "security provided
-by")))((("consensus", see="mining and consensus")))Miners can only
+by")))Miners can only
 receive honest income from creating blocks that follow all of Bitcoin's
 _consensus rules_.  Therefore, miners are normally incentivized to
 only include valid transactions in their blocks and the blocks they
@@ -541,7 +541,7 @@ software to create candidate blocks that assign the reward to a pool address.
 From there, a share of the reward is distributed to members of the pool
 miners in proportion to the amount of work they contributed.
 
-((("candidate blocks")))((("blocks", "candidate blocks")))Alice's
+Alice's
 transaction was picked up by the network and included in the pool of
 unverified transactions. Once validated by a full node, it was
 included in a candidate block.
@@ -583,7 +583,7 @@ You can see the block that includes
 https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764611cb7acf552e90[Alice's transaction].
 ====
 
-((("confirmations", "role in transactions")))Approximately 19 minutes
+Approximately 19 minutes
 after the block containing Alice's transaction is broadcast, a new block
 is mined by another miner. Because this
 new block is built on top of the block that contained Alice's
@@ -596,7 +596,7 @@ transaction counts as an additional confirmation.  As the blocks pile on
 top of each other, it becomes harder to reverse the transaction, thereby
 giving Bob more and more confidence that Alice's payment is secure.
 
-((("genesis block")))((("blocks", "genesis block")))((("blockchain
+((("blockchain
 (the)", "genesis block")))In <<block-alice1>>,  we can
 the block which contains Alice's transaction. Below it are
 hundreds of thousands of blocks, linked to each other in a chain of
@@ -607,7 +607,7 @@ By convention, any block with more than six confirmations
 is considered very hard to change, because it would require an immense amount of
 computation to recalculate six blocks (plus one new block). We will examine
 the process of mining and the way it builds confidence in more detail in
-<<mining>>.((("", startref="BToverview02")))((("",
+<<mining>>.((("",
 startref="MACover02")))
 
 [[block-alice1]]

preface.asciidoc

@@ -3,27 +3,27 @@
 
 === Writing the Bitcoin Book
 
-((("bitcoin", "benefits of", id="BCbasicbenefits0")))((("decentralized systems", "bitcoin as")))I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. ((("digital currencies", "bitcoin vs. others")))I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin.
+I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin.
 
 Two years later, after creating a number of small startups to explore various Bitcoin-related services and products, I decided that it was time to write my first book. Bitcoin was the topic that had driven me into a frenzy of creativity and consumed my thoughts; it was the most exciting technology I had encountered since the internet. It was now time to share my passion about this amazing technology with a broader audience.
 
 === Intended Audience
 
-((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies.
+This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies.
 
 === Why Are There Bugs on the Cover?
 
-((("decentralized systems", "in nature")))The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming!
+The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming!
 
 Although ants form a caste-based society and have a queen for producing offspring, there is no central authority or leader in an ant colony. The highly intelligent and sophisticated behavior exhibited by a multimillion-member colony is an emergent property from the interaction of the individuals in a social network.
 
 Nature demonstrates that decentralized systems can be resilient and can produce emergent complexity and incredible sophistication without the need for a central authority, hierarchy, or complex parts.
 
-((("decentralized systems", "benefits of")))Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination.((("", startref="BCbasicbenefits0")))
+Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination.
 
 === Conventions Used in This Book
 
-((("typographical conventions")))The following typographical conventions are used in this book:
+The following typographical conventions are used in this book:
 
 _Italic_:: Indicates new terms, URLs, email addresses, filenames, and file extensions.
 
@@ -61,9 +61,9 @@ All the code snippets use real values and calculations where possible, so that y
 
 This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
 
-((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.”
+We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.”
 
-((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
+Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
 
 If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at pass:[<a href="mailto:permissions@oreilly.com">permissions@oreilly.com</a>].
 
@@ -73,13 +73,13 @@ include::meta/third_edition_changes.asciidoc[]
 
 === Bitcoin Addresses and Transactions in This Book
 
-((("getting started", "warnings and cautions")))((("warnings and cautions", "avoid sending money to addresses appearing in book")))((("keys and addresses", "warnings and cautions")))((("transactions", "warnings and cautions")))((("blockchain applications", "warnings and cautions")))((("QR codes", "warnings and cautions")))The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
+The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
 
 However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
 
 [WARNING]
 ====
-DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.((("", startref="codeuse00")))
+DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.
 ====
 
 === O'Reilly Safari
@@ -96,7 +96,7 @@ For more information, please visit pass:[<a href="https://oreilly.com/safari" cl
 
 === How to Contact Us
 
-((("comments and questions")))((("contact information")))Please address comments and questions concerning this book to the publisher:
+Please address comments and questions concerning this book to the publisher:
 
 ++++
 <ul class="simplelist">
@@ -146,7 +146,7 @@ link:$$https://dtrt.org/$$[]
 
 _By Andreas M. Antonopoulos_
 
-((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin.
+This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin.
 
 It is impossible to make a distinction between the Bitcoin technology and the Bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire Bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful.
 

security.adoc

@@ -20,7 +20,7 @@ need to think about securing your bitcoins in a novel way too.
 
 === Security Principles
 
-((("security", "security principles", id="Sprinc11")))((("decentralized
+((("decentralized
 systems", "security of")))The core principle in Bitcoin is
 decentralization and it has important implications for security. A
 centralized model, such as a traditional bank or payment network,
@@ -63,7 +63,7 @@ able to adequately secure their keys and get hacked, one by one.
 
 ==== Developing Bitcoin Systems Securely
 
-((("decentralized systems", "bitcoin as")))A critical principle
+A critical principle
 for Bitcoin developers is decentralization. Most developers will be
 familiar with centralized security models and might be tempted to apply
 these models to their Bitcoin applications, with disastrous results.
@@ -93,7 +93,7 @@ ultimately subvert Bitcoin's security.
 
 ==== The Root of Trust
 
-((("root of trust concept")))Traditional security architecture is based
+Traditional security architecture is based
 upon a concept called the _root of trust_, which is a trusted core used
 as the foundation for the security of the overall system or application.
 Security architecture is developed around the root of trust as a series
@@ -112,7 +112,7 @@ of a single system, then extending that root of trust through the
 operating system to higher-level system services, and finally across
 many servers layered in concentric circles of diminishing trust.
 
-((("mining and consensus", "security and consensus")))Bitcoin security
+Bitcoin security
 architecture is different. In Bitcoin, the consensus system creates a
 trusted blockchain that is completely decentralized. A correctly
 validated blockchain uses the genesis block as the root of trust,
@@ -146,7 +146,7 @@ startref="Sprinc11")))
 
 === User Security Best Practices
 
-((("security", "user security best practices", id="Suser11")))((("use
+((("use
 cases", "user security best practices", id="UCsecurity11")))Humans have
 used physical security controls for thousands of years. By comparison,
 our experience with digital security is less than 50 years old. Modern
@@ -193,8 +193,8 @@ we will examine various best practices for practical user security.
 
 ==== Physical Bitcoin Storage
 
-((("storage", "physical bitcoin storage")))((("paper
-wallets")))((("wallets", "types of", "paper wallets")))((("paper
+((("paper
+wallets")))((("paper
 wallets", see="also wallets")))Because most users are far more
 comfortable with physical security than information security, a very
 effective method for protecting bitcoins is to convert them into physical
@@ -225,7 +225,7 @@ signing devices may become the predominant method of storing bitcoins.
 
 ==== Ensuring Your Access
 
-((("risk, balancing and diversifying", seealso="security")))Although
+Although
 most users are rightly concerned about theft of thir bitcoins, there is an even
 bigger risk. Data files get lost all the time. If they contain Bitcoin keys,
 the loss is much more painful. In the effort to secure their Bitcoin
@@ -262,7 +262,7 @@ storage).
 
 ==== Multisig and Governance
 
-((("multisig addresses")))((("addresses", "multisig
+((("addresses", "multisig
 addresses")))Whenever a company or individual stores large amounts of
 bitcoins, they should consider using a multisignature Bitcoin address.
 Multisignature addresses secure funds by requiring more than one
@@ -277,8 +277,8 @@ stored in different locations.
 
 ==== Survivability
 
-((("survivability")))((("digital asset executors")))((("passwords",
-"survivability and")))((("security", "passwords")))One important
+((("passwords",
+"survivability and")))One important
 security consideration that is often overlooked is availability,
 especially in the context of incapacity or death of the key holder.
 Bitcoin users are told to use complex passwords and keep their keys
@@ -292,7 +292,7 @@ If you have a lot of bitcoins, you should consider sharing access details
 with a trusted relative or lawyer. A more complex survivability scheme
 can be set up with multi-signature access and estate planning through a
 lawyer specialized as a "digital asset executor."((("",
-startref="Suser11")))((("", startref="UCsecurity11")))
+startref="Suser11")))
 
 Bitcoin is a completely new, unprecedented, and complex technology. Over
 time we will develop better security tools and practices that are easier

signatures.adoc

@@ -1,7 +1,7 @@
 [[c_signatures]]
 == Digital Signatures
 
-((("digital signatures", "algorithm used")))((("Elliptic Curve Digital
+((("Elliptic Curve Digital
 Signature Algorithm (ECDSA)")))Two signature algorithms are currently
 used in Bitcoin, the _schnorr signature algorithm_ and the _Elliptic
 Curve Digital Signature Algorithm_ (_ECDSA_).
@@ -14,7 +14,7 @@ keypath spending, and by the script functions +OP_CHECKSIG+,
 Any time one of those is executed, a signature must be
 provided.
 
-((("digital signatures", "purposes of")))A digital signature serves
+A digital signature serves
 three purposes in Bitcoin. First, the
 signature proves that the controller of a private key, who is by
 implication the owner of the funds, has _authorized_ the spending of
@@ -38,7 +38,7 @@ key.
 
 === How Digital Signatures Work
 
-((("digital signatures", "how they work")))A digital signature
+A digital signature
 consists of two parts. The first part is an algorithm for creating a
 signature for a message (the transaction) using a private key (the
 signing key). The second part is an algorithm
@@ -70,7 +70,7 @@ In both schnorr and ECDSA signatures, the function _F_~_sig_~ produces a signatu
 two values.  There are differences between the two values in the
 different algorithms, which we'll explore later.
 
-((("Distinguished Encoding Rules (DER)")))After the two values
+After the two values
 are calculated, they are serialized into a byte-stream.  For ECDSA
 signatures, the encoding uses an international standard encoding scheme
 called the
@@ -79,7 +79,7 @@ simpler serialization format is used.
 
 ==== Verifying the Signature
 
-((("digital signatures", "verifying"))) The signature verification
+ The signature verification
 algorithm takes the message (a hash of parts of the transaction and
 related data), the signer's public key and the signature, and returns
 TRUE if the signature is valid for this message and public key.
@@ -95,7 +95,7 @@ signature on this transaction."
 ==== Signature Hash Types (SIGHASH)
 
 ((("digital signatures", "signature hash
-types")))((("commitment")))Digital signatures apply to messages,
+types")))Digital signatures apply to messages,
 which in the case of Bitcoin, are the transactions themselves. The
 signature prove a _commitment_ by the signer to specific transaction
 data. In the simplest form, the signature applies to almost the entire
@@ -104,7 +104,7 @@ transaction fields. However, a signature can commit to only a subset of
 the data in a transaction, which is useful for a number of scenarios as
 we will see in this section.
 
-((("SIGHASH flags")))Bitcoin signatures have a way of indicating which
+Bitcoin signatures have a way of indicating which
 part of a transaction's data is included in the hash signed by the
 private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
 that is appended to the signature. Every signature has either an
@@ -176,7 +176,7 @@ of all inputs and outputs. This is the most common signature form.
 Let's look at some of the other +SIGHASH+ types and how they can be used
 in practice:
 
-+ALL|ANYONECANPAY+ :: ((("charitable donations")))((("use cases",
++ALL|ANYONECANPAY+ :: ((("use cases",
 "charitable donations")))This construction can be used to make a
 "crowdfunding”-style transaction. Someone attempting to raise
 funds can construct a transaction with a single output. The single
@@ -209,7 +209,7 @@ without the cost in fees exceeding the value of the UTXO, see
 of signature, the uneconomical UTXOs can be donated for anyone to aggregate and
 spend whenever they want.
 
-((("Bitmask Sighash Modes")))There are some proposals to modify or
+There are some proposals to modify or
 expand the +SIGHASH+ system.  The most widely discussed proposal as of
 this writing is BIP118, which proposes to add two
 new sighash flags.  A signature using +SIGHASH_ANYPREVOUT+ would not
@@ -886,7 +886,7 @@ as follows:
 [[nonce_warning]]
 === The Importance of Randomness in Signatures
 
-((("digital signatures", "randomness in")))As we saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
+As we saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
 the signature generation algorithm uses a random number _k_, as the basis
 for a private/public nonce pair. The value of _k_ is not
 important, _as long as it is random_. If signatures from the same
@@ -898,7 +898,7 @@ key!
 
 [WARNING]
 ====
-((("warnings and cautions", "digital signatures")))If the same value _k_
+If the same value _k_
 is used in the signing algorithm on two different transactions, the
 private key can be calculated and exposed to the world!
 ====
@@ -910,8 +910,8 @@ because of inadvertent reuse of a _k_ value. The most common reason for
 reuse of a _k_ value is an improperly initialized random-number
 generator.
 
-((("random numbers", "random number generation")))((("entropy", "random
-number generation")))((("deterministic initialization")))To avoid this
+((("entropy", "random
+number generation")))To avoid this
 vulnerability, the industry best practice is to not generate _k_ with a
 random-number generator seeded only with entropy, but instead to use a
 process seeded in part with the transaction data itself plus the

wallets.adoc

@@ -20,7 +20,7 @@ In those cases, we'll describe the various options available.
 
 === Independent Key Generation
 
-((("wallets", "contents of")))Wallets for physical cash hold that cash,
+Wallets for physical cash hold that cash,
 so it's unsurprising that many people mistakenly believe that
 bitcoin wallets contain bitcoins.  In fact, what many people call a
 Bitcoin wallet--which we call a _wallet database_ to distinguish it
@@ -211,7 +211,7 @@ We'll provide a detailed exploration of HD wallets in <<hd_wallet_details>>.
 
 ==== Seeds and Recovery Codes
 
-((("wallets", "technology of", "seeds and recovery codes")))((("recovery
+((("recovery
 code words")))((("bitcoin improvement proposals", "Recovery Code Words
 (BIP39)")))HD wallets are a very powerful mechanism for managing many
 keys all derived from a single seed.  If your wallet database
@@ -624,7 +624,7 @@ modern standards that may provide additional features or safety.
 [[recovery_code_words]]
 ==== BIP39 Recovery Codes
 
-((("wallets", "technology of", "recovery code words")))((("recovery code
+((("recovery code
 words", id="mnemonic05")))((("bitcoin improvement proposals", "Recovery
 Code Words (BIP39)", id="BIP3905")))BIP39 recovery codes are word
 sequences that represent (encode) a random number used as a seed to
@@ -640,7 +640,7 @@ transcribe.
 
 [TIP]
 ====
-((("brainwallets")))Recovery codes are often confused with
+Recovery codes are often confused with
 "brainwallets." They are not the same. The primary difference is that a
 brainwallet consists of words chosen by the user, whereas recovery codes
 are created randomly by the wallet and presented to the user. This
@@ -705,13 +705,13 @@ data and the length of recovery code in words.
 [[recovery_to_seed]]
 ===== From recovery code to seed
 
-((("key-stretching function")))((("PBKDF2 function")))The recovery code
+The recovery code
 represents entropy with a length of 128 to 256 bits. The entropy is then
 used to derive a longer (512-bit) seed through the use of the
 key-stretching function PBKDF2. The seed produced is then used to build
 a deterministic wallet and derive its keys.
 
-((("salts")))((("passphrases")))The key-stretching function takes two
+The key-stretching function takes two
 parameters: the entropy and a _salt_. The purpose of a salt in a
 key-stretching function is to make it difficult to build a lookup table
 enabling a brute-force attack. In the BIP39 standard, the salt has
@@ -858,7 +858,7 @@ recovery codes (or a value near 128, such as Electrum v2's 132 bits).
 [[recovery_passphrase]]
 ===== Optional passphrase in BIP39
 
-((("passphrases")))The BIP39 standard allows the use of an optional
+The BIP39 standard allows the use of an optional
 passphrase in the derivation of the seed. If no passphrase is used, the
 recovery code is stretched with a salt consisting of the constant string
 +"mnemonic"+, producing a specific 512-bit seed from any given recovery code.
@@ -904,7 +904,7 @@ her family to recover the cryptocurrency estate.
 ==== Creating an HD Wallet from the Seed
 
 ((("wallets", "technology of", "creating HD wallets from root
-seed")))((("root seeds")))((("hierarchical deterministic (HD)
+seed")))((("hierarchical deterministic (HD)
 wallets")))HD wallets are created from a single _root seed_, which is a
 128-, 256-, or 512-bit random number. Most commonly, this seed is
 generated by or decrypted from a _recovery code_ as detailed in the previous section.
@@ -936,7 +936,7 @@ creates child keys from parent keys, as we will see in the next section.
 
 ===== Private child key derivation
 
-((("child key derivation (CKD)")))((("public and private keys", "child
+((("public and private keys", "child
 key derivation (CKD)")))HD wallets use a _child key derivation_ (CKD)
 function to derive child keys from parent keys.
 
@@ -1008,7 +1008,7 @@ operate exactly as "normal" keys.
 
 ===== Extended keys
 
-((("public and private keys", "extended keys")))((("extended keys")))As
+As
 we saw earlier, the key derivation function can be used to create
 children at any level of the tree, based on the three inputs: a key, a
 chain code, and the index of the desired child. The two essential
@@ -1055,7 +1055,7 @@ xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLr
 [[public__child_key_derivation]]
 ===== Public child key derivation
 
-((("public and private keys", "public child key derivation")))As
+As
 mentioned  previously, a very useful characteristic of HD wallets is the
 ability to derive public child keys from public parent keys, _without_
 having the private keys. This gives us two ways to derive a child public
@@ -1133,7 +1133,7 @@ address for the actual transaction.  However, these other solutions have
 not been used in production as of this writing.
 ****
 
-((("cold storage")))((("storage", "cold storage")))((("hardware
+((("hardware
 wallets")))Another common application of this solution is for
 cold-storage or hardware signing devices. In that scenario, the extended
 private key can be stored on a paper wallet or hardware device, while
@@ -1152,7 +1152,7 @@ image::images/mbc2_0511.png["ChildPublicDerivation"]
 
 ((("wallets", "technology of", "using extended public keys on web
 stores")))Let's see how HD wallets are used by looking at
-Gabriel's web store.((("use cases", "web store", id="gabrielfivetwo")))
+Gabriel's web store.
 
 Gabriel first set up his web store as a hobby, based on a simple hosted
 Wordpress page. His store was quite basic with only a few pages and an
@@ -1206,7 +1206,7 @@ software, such as the widely used open source BTCPay Server.
 ===== Hardened child key derivation
 
 ((("public and private keys", "hardened child key
-derivation")))((("hardened derivation")))The ability to derive a branch
+derivation")))The ability to derive a branch
 of public keys from an xpub is very useful, but it comes with a
 potential risk. Access to an xpub does not give access to child private
 keys. However, because the xpub contains the chain code, if a child
@@ -1273,7 +1273,7 @@ has special meaning, using the letter _h_ is recommended.
 
 ===== HD wallet key identifier (path)
 
-((("hierarchical deterministic (HD) wallets")))Keys in an HD wallet are
+Keys in an HD wallet are
 identified using a "path" naming convention, with each level of the tree
 separated by a slash (/) character (see <<table_4-8>>). Private keys
 derived from the master private key start with "m." Public keys derived
@@ -1344,7 +1344,7 @@ contain two Bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++
 and m/44++&#x27;++/0++&#x27;++/1++&#x27;++. Each account is the root of
 its own subtree.
 
-((("keys and addresses", see="also public and private keys")))On the
+On the
 fourth level, "change," an HD wallet has two subtrees, one for creating
 receiving addresses and one for creating change addresses. Note that
 whereas the previous levels used hardened derivation, this level uses

whitepaper.adoc

@@ -4,7 +4,7 @@
 
 [NOTE]
 ====
-((("whitepaper", id="whitethirteen")))((("bitcoin whitepaper", id="BCwhitethirteen")))((("Nakamoto, Satoshi", id="nakamatothirteen")))This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008.
+This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008.
 ====
 
 === Bitcoin - A Peer-to-Peer Electronic Cash System
@@ -450,7 +450,7 @@ We have proposed a system for electronic transactions without relying on trust.
 
 === License
 
-((("open source licenses")))This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license:
+This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license:
 
 The MIT License (MIT)
 Copyright (c) 2008 Satoshi Nakamoto
@@ -459,4 +459,4 @@ Permission is hereby granted, free of charge, to any person obtaining a copy of
 
 The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.((("", startref="whitethirteen")))((("", startref="nakamatothirteen")))((("", startref="BCwhitethirteen")))
+THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.