removing line breaks from inside index tags

applications.adoc

@@ -13,8 +13,7 @@ routed payment channels (Lightning Network).
 
 === Building Blocks (Primitives)
 
-((("blockchain applications", "building blocks for
-(primitives)")))When operating correctly and over the
+((("blockchain applications", "building blocks for(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:
 
@@ -112,8 +111,7 @@ 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")))Immutability + Timestamp + Durability.
+Proof-of-Existence (Digital Notary):: ((("digital notaryservices")))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
@@ -124,8 +122,7 @@ sign one input and the output (Integrity) of a fundraiser transaction,
 others can contribute to the fundraiser but it cannot be spent
 (Atomicity) until the goal (output amount) is funded (Consistency).
 
-Payment Channels:: ((("payment (state) channels", "building blocks
-(primitives) used in")))Quorum of Control + Timelock + No Double Spend + Nonexpiration
+Payment Channels:: ((("payment (state) channels", "building blocks(primitives) used in")))Quorum of Control + Timelock + No Double Spend + Nonexpiration
 + Censorship Resistance + Authorization. A multisig 2-of-2
 (Quorum) with a timelock (Timelock) used as the "settlement" transaction
 of a payment channel can be held (Nonexpiration) and spent at any time
@@ -135,8 +132,7 @@ Double-Spend) the settlement on a shorter timelock (Timelock).
 
 === Colored Coins
 
-((("blockchain applications", "colored coins",
-id="BCAcoins12")))The first
+((("blockchain applications", "colored coins",id="BCAcoins12")))The first
 blockchain application we will discuss is _colored coins_.
 
 Colored coins refers to a set of
@@ -361,8 +357,7 @@ working on BIPs that may be available after this book goes into print.
 [[state_channels]]
 === Payment Channels and State Channels
 
-_Payment channels_ ((("blockchain applications", "payment (state)
-channels", id="BCApayment12")))((("payment (state) channels",
+_Payment channels_ ((("blockchain applications", "payment (state)channels", id="BCApayment12")))((("payment (state) channels",
 "defined")))are a trustless mechanism for exchanging Bitcoin
 transactions between two parties, outside of the Bitcoin blockchain.
 These transactions, which would be valid if settled on the Bitcoin
@@ -444,8 +439,7 @@ any number of commitment transactions that are never seen by anyone
 else, nor submitted to the blockchain.
 
 <<payment_channel>> illustrates a payment channel between Bob and Alice,
-showing the funding, commitment, and settlement transactions.((("use
-cases", "buying coffee", startref="alicetwelve")))
+showing the funding, commitment, and settlement transactions.((("usecases", "buying coffee", startref="alicetwelve")))
 
 [[payment_channel]]
 .A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions
@@ -555,8 +549,7 @@ image::images/mbc2_1206.png["Emma's payment channel with Fabian, showing the com
 
 ==== Making Trustless Channels
 
-((("payment (state) channels", "making trustless channels",
-id="PSCtrust12")))The channel we just described works, but only if both
+((("payment (state) channels", "making trustless channels",id="PSCtrust12")))The channel we just described works, but only if both
 parties cooperate, without any failures or attempts to cheat. Let's look
 at some of the scenarios that break this channel and see what is needed
 to fix those:
@@ -702,8 +695,7 @@ to wait for their funds too.
 
 ==== Asymmetric Revocable Commitments
 
-((("payment (state) channels", "asymmetric revocable commitments",
-id="PSCaymetric12")))Another way to handle the prior commitment states
+((("payment (state) channels", "asymmetric revocable commitments",id="PSCaymetric12")))Another way to handle the prior commitment states
 is to explicitly revoke them. However, this is not easy to achieve. A
 key characteristic of Bitcoin is that once a transaction is valid, it
 remains valid and does not expire. The only way to cancel a transaction
@@ -922,8 +914,7 @@ channel.
 
 ==== Hash Time Lock Contracts (HTLC)
 
-((("payment (state) channels",
-"Hash Time Lock Contracts (HTLC)")))Payment channels can be further
+((("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
 time. This feature is called a _Hash Time Lock Contract_, or _HTLC_, and
@@ -978,8 +969,7 @@ know the secret +R+.
 [[lightning_network]]
 === Routed Payment Channels (Lightning Network)
 
-((("blockchain applications", "routed payment channels",
-seealso="Lightning Network", id="BCAlightning12")))((("routed payment
+((("blockchain applications", "routed payment channels",seealso="Lightning Network", id="BCAlightning12")))((("routed payment
 channels", see="Lightning Network")))((("Lightning Network",
 "defined")))The Lightning Network is a proposed routed network of
 bidirectional payment channels connected end-to-end. A network like this
@@ -991,8 +981,7 @@ of payment channels as proposed and elaborated upon by many others.
 
 "Lightning Network" refers to a specific design for a routed payment
 channel network, which has now been implemented by at least five
-different open source teams. ((("Basics of Lightning Technology
-(BOLT)")))The independent implementations are coordinated by a set of
+different open source teams. ((("Basics of Lightning Technology(BOLT)")))The independent implementations are coordinated by a set of
 interoperability standards described in the
 https://github.com/lightning/bolts/blob/master/00-introduction.md[_Basics of Lightning Technology (BOLT)_ repository].
 
@@ -1183,8 +1172,7 @@ who can only decrypt and unwrap the outer layer. Inside, Bob finds a
 message addressed to Carol that he can forward to Carol but cannot
 decipher himself. Following the path, the messages get forwarded,
 decrypted, forwarded, etc., all the way to Eric. Each participant knows
-only the previous and next node in each hop.((("",
-startref="alicetwelve")))
+only the previous and next node in each hop.((("",startref="alicetwelve")))
 
 Each element of the path contains information on the HTLC that must be
 extended to the next hop, the amount that is being sent, the fee to

authorization-authentication.adoc

@@ -25,8 +25,7 @@ used.
 [role="pagebreak-before less_space_h1"]
 === Transaction Scripts and Script Language
 
-((("transactions", "scripts and Script language",
-id="Tsript06")))((("scripting", "transactions and",
+((("transactions", "scripts and Script language",id="Tsript06")))((("scripting", "transactions and",
 id="Stransact06")))The original version of Bitcoin introduced a new
 programming language called _Script_, a Forth-like stack-based
 language.  Both the script placed in an output and the legacy
@@ -67,8 +66,7 @@ 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",
-see="also security")))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
@@ -301,8 +299,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="Stransact06")))
+transaction.((("",startref="Stransact06")))
 
 [[P2PubKHash1]]
 .Evaluating a script for a P2PKH transaction (part 1 of 2)
@@ -315,8 +312,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
 [[multisig]]
 === Scripted multisignatures
 
-((("transactions", "advanced", "multisignature
-scripts")))((("scripting",
+((("transactions", "advanced", "multisignaturescripts")))((("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
@@ -388,8 +384,7 @@ script may include multiple of those opcodes.
 [[multisig_bug]]
 ==== An oddity in CHECKMULTISIG execution
 
-((("scripting", "multisignature scripts", "OP_CHECKMULTISIG
-oddity")))There is an oddity in
+((("scripting", "multisignature scripts", "OP_CHECKMULTISIGoddity")))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
@@ -470,20 +465,17 @@ book, we simply call it an oddity.
 
 From now on, if you see a multisig script, you should expect
 to see an extra +OP_0+ in the beginning, whose only purpose is as a
-workaround to an oddity in the consensus rules.((("",
-startref="Smulti07")))
+workaround to an oddity in the consensus rules.((("",startref="Smulti07")))
 
 [[p2sh]]
 === Pay-to-Script-Hash (P2SH)
 
-((("scripting",
-"Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was
+((("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.
 
-((("scripting",
-"Pay-to-Script-Hash", "import/export example")))((("Pay-to-Script-Hash
+((("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
 company uses Bitcoin's multisignature feature extensively for its
@@ -617,8 +609,7 @@ If the redeem script hash matches, the redeem script is executed:
 
 ==== P2SH Addresses
 
-((("scripting", "Pay-to-Script-Hash",
-"addresses")))((("bitcoin
+((("scripting", "Pay-to-Script-Hash","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
@@ -642,8 +633,7 @@ payment does not see the script.
 
 ==== Benefits of P2SH
 
-((("scripting", "Pay-to-Script-Hash", "benefits
-of")))The P2SH feature
+((("scripting", "Pay-to-Script-Hash", "benefitsof")))The P2SH feature
 offers the following benefits compared to the direct use of complex
 scripts in outputs:
 
@@ -690,8 +680,7 @@ spent.
 [[op_return]]
 === Data Recording Output (OP_RETURN)
 
-((("scripting",
-"data recording output")))((("data recording
+((("scripting","data recording output")))((("data recording
 (nonpayment data)")))((("blockchain (the)",
 "nonpayment data recording")))Bitcoin's
 distributed and timestamped blockchain has potential uses
@@ -705,8 +694,7 @@ 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.
 
-((("unspent transaction outputs
-(UTXO)")))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
@@ -783,8 +771,7 @@ It is important to understand the limitations of transaction lock time. The only
 
 ==== Check Lock Time Verify (OP_CLTV)
 
-((("timelocks", "Check
-Lock Time Verify (OP_CLTV)")))((("scripting", "timelocks", "Check Lock Time
+((("timelocks", "CheckLock 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
 timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
@@ -900,8 +887,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
 [[op_csv]]
 ==== Relative Timelocks
 
-Lock time and +OP_CLTV+ are ((("timelocks", "relative timelocks",
-id="Trelative07")))((("scripting", "timelocks", "relative
+Lock time and +OP_CLTV+ are ((("timelocks", "relative timelocks",id="Trelative07")))((("scripting", "timelocks", "relative
 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
@@ -923,8 +909,7 @@ on the value of +sequence+, a transaction field that is set in every
 transaction input. Script-level relative timelocks are implemented with
 the +OP_CHECKSEQUENCEVERIFY+ (OP_CSV) opcode.
 
-((("bitcoin improvement proposals", "Relative lock-time using
-consensus-enforced sequence numbers (BIP68)")))((("bitcoin improvement
+((("bitcoin improvement proposals", "Relative lock-time usingconsensus-enforced sequence numbers (BIP68)")))((("bitcoin improvement
 proposals", "CHECKSEQUENCEVERIFY (BIP112)")))Relative timelocks are
 implemented according to the specifications in
 https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68,
@@ -937,8 +922,7 @@ the consensus rules.
 
 ==== Relative Timelocks with OP_CSV
 
-((("scripting", "timelocks", "relative timelocks with
-CHECKSEQUENCEVERIFY")))Just like OP_CLTV
+((("scripting", "timelocks", "relative timelocks withCHECKSEQUENCEVERIFY")))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.
@@ -969,8 +953,7 @@ Relative timelocks with +OP_CSV+ are especially useful when several
 is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the
 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")))
+be seen in <<state_channels>> and <<lightning_network>>.((("",startref="relativetime07")))
 
 +OP_CSV+ is defined in detail in
 https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
@@ -978,8 +961,7 @@ CHECKSEQUENCEVERIFY].
 
 === Scripts with Flow Control (Conditional Clauses)
 
-((("scripting",
-"flow control scripts", id="Sflow07")))((("conditional clauses",
+((("scripting","flow control scripts", id="Sflow07")))((("conditional clauses",
 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
@@ -1178,13 +1160,11 @@ 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="flow07")))
+at each flow control point.((("",startref="flow07")))
 
 === Complex Script Example
 
-((("scripting", "complex
-script example", id="Scomplex07")))In this section we combine many of
+((("scripting", "complexscript example", id="Scomplex07")))In this section we combine many of
 the concepts from this chapter into a single example.
 
 Mohammed is company owner in Dubai who is operating an import/export
@@ -1548,8 +1528,7 @@ OP_HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b OP_EQUAL
 ----
 
 Even though Alice's wallet has no support for segwit, the payment it
-creates can be spent by Bob with a segwit transaction.((("",
-startref="aliced")))
+creates can be spent by Bob with a segwit transaction.((("",startref="aliced")))
 
 ===== Nested Pay-to-Witness-Script-Hash
 
@@ -1558,8 +1537,7 @@ complicated script can be embedded inside a P2SH script and address,
 making it possible for any wallet to make payments that are segwit
 compatible.
 
-As we saw in <<p2wsh>>, Mohammed's ((("use cases",
-"import/export")))company is using Segregated Witness payments to
+As we saw in <<p2wsh>>, Mohammed's ((("use cases","import/export")))company is using Segregated Witness payments to
 multisignature scripts. To make it possible for any client to pay his
 company, regardless of whether their wallets are upgraded for segwit,
 Mohammed's wallet can embed the P2WSH witness program inside a P2SH

bitcoin-core.adoc

@@ -35,8 +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!
 
-((("reference
-implementation", see="Bitcoin Core")))((("Bitcoin Core", "reference
+((("referenceimplementation", 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
 <<satoshi_whitepaper>>. Satoshi wanted to make sure the
@@ -79,15 +78,12 @@ next chapter, which is less technical.
 [[compiling_core]]
 === Compiling Bitcoin Core from the Source Code
 
-((("Bitcoin Core", "compiling from source code",
-id="BCsource03")))((("Bitcoin Core", "compiling from source code",
+((("Bitcoin Core", "compiling from source code",id="BCsource03")))((("Bitcoin Core", "compiling from source code",
 "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
+source repository from GitHub.  ((("Bitcoin Coredownloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download
 page], select the most recent version and download the compressed
-archive of the source code. ((("GitHub
-bitcoin page")))Alternatively, use the git command line to create a
+archive of the source code. ((("GitHubbitcoin page")))Alternatively, use the git command line to create a
 local copy of the source code from the
 https://github.com/bitcoin/bitcoin[GitHub bitcoin page].
 
@@ -107,8 +103,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.
 ====
 
-((("source code, cloning", seealso="Bitcoin
-Core")))In this example, we are using the +git+ command to create a
+((("source code, cloning", seealso="BitcoinCore")))In this example, we are using the +git+ command to create a
 local copy ("clone") of the source code:
 
 ----
@@ -141,8 +136,7 @@ $ cd bitcoin
 
 ==== Selecting a Bitcoin Core Release
 
-((("Bitcoin Core", "compiling from source code", "version
-selection")))By default, the local copy will be synchronized with the
+((("Bitcoin Core", "compiling from source code", "versionselection")))By default, the local copy will be synchronized with the
 most recent code, which might be an unstable or beta version of Bitcoin.
 Before compiling the code, select a specific version by checking out a
 release _tag_. This will synchronize the local copy with a specific
@@ -191,8 +185,7 @@ nothing to commit, working tree clean
 
 ==== Configuring the Bitcoin Core Build
 
-((("Bitcoin Core", "compiling from source code", "build
-configuration")))((("build documentation",
+((("Bitcoin Core", "compiling from source code", "buildconfiguration")))((("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.
@@ -302,8 +295,7 @@ fixes the error.
 
 ==== Building the Bitcoin Core Executables
 
-((("Bitcoin Core", "compiling from source code", "core
-executables")))Next, you
+((("Bitcoin Core", "compiling from source code", "coreexecutables")))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
@@ -358,8 +350,7 @@ $ which bitcoin-cli
 
 === Running a Bitcoin Core Node
 
-((("Bitcoin
-nodes", "running core nodes", id="BNcore03")))Bitcoin's peer-to-peer
+((("Bitcoinnodes", "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
 Bitcoin nodes have a direct and authoritative view of the Bitcoin
@@ -392,8 +383,7 @@ https://blockstream.com/satellite/[Blockstream Satellite].
 
 [TIP]
 ====
-((("warnings and cautions", "core node resource
-requirements")))Bitcoin Core keeps a full
+((("warnings and cautions", "core node resourcerequirements")))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,8 +427,7 @@ node.
 
 ==== Configuring the Bitcoin Core Node
 
-((("warnings
-and cautions", "password creation")))((("passwords",
+((("warningsand cautions", "password creation")))((("passwords",
 "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
@@ -530,8 +519,7 @@ Use it to reduce memory use on memory-constrained nodes.
 [[txindex]]
 .Transaction Database Index and txindex Option
 ****
-((("Bitcoin Core", "running core nodes", "database
-options")))((("transactions", "database configuration
+((("Bitcoin Core", "running core nodes", "databaseoptions")))((("transactions", "database configuration
 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_
@@ -653,8 +641,7 @@ should add Bitcoin Core to the startup scripts in your operating system, so
 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")))
+a _README.md_ file showing which system uses which script.((("",startref="BCnode03")))
 
 === Bitcoin Core Application Programming Interface (API)
 
@@ -662,8 +649,7 @@ 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
-programmatically via the API. ((("Bitcoin Core", "Bitcoin Core API",
-"RPC commands")))To start, invoke the +help+ command to see a list of
+programmatically via the API. ((("Bitcoin Core", "Bitcoin Core API","RPC commands")))To start, invoke the +help+ command to see a list of
 the available Bitcoin Core RPC commands:
 
 [[bitcoind_commands]]
@@ -788,8 +774,7 @@ on how many blocks your node has.
 [[exploring_and_decoding_transactions]]
 ==== Exploring and Decoding Transactions
 
-In <<spending_bitcoin>>, ((("use cases", "buying coffee",
-id="alicethree")))Alice made a purchase from Bob's store. Her
+In <<spending_bitcoin>>, ((("use cases", "buying coffee",id="alicethree")))Alice made a purchase from Bob's store. Her
 transaction was recorded on the blockchain.
 Let's use the API to retrieve and examine that transaction by passing
 the txid as a parameter:
@@ -984,8 +969,7 @@ we'll examine those in detail in <<mining>>.
 
 ==== Using Bitcoin Core's Programmatic Interface
 
-((("Bitcoin Core", "Bitcoin Core API", "using programmatic
-interface")))The
+((("Bitcoin Core", "Bitcoin Core API", "using programmaticinterface")))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
@@ -1126,14 +1110,12 @@ 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="progint03")))
+spot the difference.((("",startref="progint03")))
 
 [[alt_libraries]]
 === Alternative Clients, Libraries, and Toolkits
 
-((("clients,
-libraries, and toolkits", id="clients03")))((("libraries, clients, and
+((("clients,libraries, and toolkits", id="clients03")))((("libraries, clients, and
 toolkits", id="librar03")))((("toolkits, libraries, and clients",
 id="toolkit03")))There
 are many alternative clients, libraries, toolkits, and even full-node
@@ -1172,8 +1154,7 @@ 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="clients03")))((("",
+and more are created all the time.((("",startref="clients03")))((("",
 startref="toolkit03")))
 
 If you followed the instructions in this chapter, you now have Bitcoin

blockchain.adoc

@@ -19,8 +19,7 @@ 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",
-"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,8 +57,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. ((("coinbase
-transactions")))After 100 blocks back there is so much stability that
+change. ((("coinbasetransactions")))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.
 While the
@@ -70,8 +68,7 @@ infinitesimal.
 
 === Structure of a Block
 
-((("blockchain (the)", "block
-structure")))A block is a container data structure that aggregates
+((("blockchain (the)", "blockstructure")))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
 of transactions that make up the bulk of its size. The block header is
@@ -95,8 +92,7 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
 [[block_header]]
 === Block Header
 
-((("blockchain (the)", "block
-headers")))The block header consists of
+((("blockchain (the)", "blockheaders")))The block header consists of
 block metadata as shown in <<block_header_structure_ch09>>.
 
 [[block_header_structure_ch09]]
@@ -118,8 +114,7 @@ process and will be discussed in more detail in <<mining>>.
 [[block_hash]]
 === Block Identifiers: Block Header Hash and Block Height
 
-((("blocks", "block
-height")))The primary identifier of a block
+((("blocks", "blockheight")))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,8 +173,7 @@ the blockchain.
 
 === The Genesis Block
 
-((("blockchain (the)", "genesis
-block")))The first block in the blockchain is called the _genesis block_
+((("blockchain (the)", "genesisblock")))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
 chain backward in time, you will eventually arrive at the genesis block.
@@ -250,8 +244,7 @@ first block by Satoshi Nakamoto, Bitcoin's creator.
 
 === Linking Blocks in the Blockchain
 
-((("blockchain (the)",
-"linking blocks in the blockchain")))Bitcoin full nodes validate every
+((("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
 extend the chain. As a node receives incoming blocks from the network,
@@ -307,8 +300,7 @@ image::images/mbc2_0901.png[]
 [[merkle_trees]]
 === Merkle Trees
 
-((("blockchain (the)", "merkle
-trees", id="BCTmerkle09")))Each block in the Bitcoin blockchain contains
+((("blockchain (the)", "merkletrees", id="BCTmerkle09")))Each block in the Bitcoin blockchain contains
 a summary of all the transactions in the block using a _merkle tree_.
 
 A _merkle tree_, also known
@@ -496,13 +488,11 @@ and block, and between the block and blockchain, proves that the
 transaction is recorded in the blockchain. All in all, the lightweight client will
 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")))
+than a full block (about 2 megabytes currently).((("",startref="BCTmerkle09")))
 
 === Bitcoin's Test Blockchains
 
-((("blockchain (the)", "test blockchains",
-id="BCTtest09")))You might be
+((("blockchain (the)", "test blockchains",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

fees.adoc

@@ -620,8 +620,7 @@ you intended.
 [[fee_sniping]]
 === Timelock Defense Against Fee Sniping
 
-((("scripting", "timelocks", "defense against
-fee-sniping")))((("timelocks", "defense against
+((("scripting", "timelocks", "defense againstfee-sniping")))((("timelocks", "defense against
 fee-sniping")))((("security", "defense
 against fee-sniping")))Fee-sniping is a theoretical
 attack scenario, where miners attempting to rewrite past blocks "snipe"

intro.adoc

@@ -98,8 +98,7 @@ Although these earlier digital currencies worked, they were centralized and, as
 
 === History of Bitcoin
 
-((("bitcoin",
-"history of")))Bitcoin was first described in 2008 with the publication of a
+((("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,"
 Satoshi Nakamoto (https://bitcoin.org/bitcoin.pdf).] written under the
@@ -107,13 +106,11 @@ 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. ((("decentralized
-systems", "consensus in")))((("mining and consensus", "Proof-of-Work
+of transactions. ((("decentralizedsystems", "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")))This
+arrive at _consensus_ about the state of transactions. ((("double-spendproblem")))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
@@ -137,16 +134,14 @@ 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
 to agree on a course of action by exchanging information over an
-unreliable and potentially compromised network. ((("central trusted
-authority")))Satoshi Nakamoto's solution, which uses the concept of
+unreliable and potentially compromised network. ((("central trustedauthority")))Satoshi Nakamoto's solution, which uses the concept of
 Proof-of-Work to achieve consensus _without a central trusted
 authority_, represents a breakthrough in distributed computing.
 ****
 
 === Getting Started
 
-((("getting started", "wallet selection",
-id="GSwallet01")))((("wallets", "selecting",
+((("getting started", "wallet selection",id="GSwallet01")))((("wallets", "selecting",
 id="Wselect01")))((("bitcoin", "getting started",
 id="BCbasic01")))Bitcoin is a protocol that can be accessed using an
 application that speaks the protocol. A "Bitcoin wallet" is the
@@ -265,8 +260,7 @@ interact with the network in different ways.
 
 ==== Quick Start
 
-((("getting started", "quick start example",
-id="GSquick01")))((("wallets", "quick start example",
+((("getting started", "quick start example",id="GSquick01")))((("wallets", "quick start example",
 id="Wquick01")))Alice is not a
 technical user and only recently heard about Bitcoin from her friend
 Joe. While at a party, Joe is enthusiastically explaining
@@ -416,8 +410,7 @@ Here are some methods for acquiring bitcoin as a new user:
 
 [TIP]
 ====
-((("security", "maintaining
-privacy")))((("currency
+((("security", "maintainingprivacy")))((("currency
 exchanges")))((("digital currencies", "benefits of
 bitcoin")))One of the advantages of
 Bitcoin over other payment systems is that, when used correctly, it
@@ -458,8 +451,7 @@ currencies.
 [[sending_receiving]]
 ==== Sending and Receiving Bitcoin
 
-((("getting started", "sending and receiving bitcoin",
-id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start
+((("getting started", "sending and receiving bitcoin",id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start
 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

keys.adoc

@@ -28,8 +28,7 @@ the addresses used by modern Bitcoin software.
 
 === Public Key Cryptography
 
-((("keys and addresses", "overview of", "public key
-cryptography")))Public key
+((("keys and addresses", "overview of", "public keycryptography")))Public key
 cryptography was invented in the 1970s and is a mathematical foundation
 for modern computer and information security.
 
@@ -62,8 +61,7 @@ _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")))((("cryptography", "elliptic
+((("keys and addresses", "overview of", "private and public keypairs")))((("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 +71,7 @@ generate a public key (K).
 
 .Why Use Asymmetric Cryptography (Public/Private Keys)?
 ****
-((("digital signatures", "asymmetric
-cryptography and")))Why is asymmetric
+((("digital signatures", "asymmetriccryptography 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
@@ -91,8 +88,7 @@ signatures.
 [[private_keys]]
 ==== Private Keys
 
-((("keys and addresses", "overview of", "private key
-generation")))A
+((("keys and addresses", "overview of", "private keygeneration")))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,8 +132,7 @@ Otherwise, we simply try again with another random number.
 
 [WARNING]
 ====
-((("entropy", "random
-number generation")))Do not write your own code to create a random
+((("entropy", "randomnumber 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
 generator (CSPRNG) with a seed from a source of sufficient entropy.
@@ -164,8 +159,7 @@ visible universe is estimated to contain 10^80^ atoms.
 [[elliptic_curve]]
 ==== Elliptic Curve Cryptography Explained
 
-((("keys and addresses", "overview of", "elliptic curve
-cryptography")))((("elliptic curve cryptography",
+((("keys and addresses", "overview of", "elliptic curvecryptography")))((("elliptic curve cryptography",
 id="eliptic04")))((("cryptography", "elliptic curve cryptography",
 id="Celliptic04")))Elliptic curve cryptography is a type of asymmetric
 or public key cryptography based on the discrete logarithm problem as
@@ -287,14 +281,12 @@ pass:[+] B pass:[+] C without parentheses and without ambiguity.
 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")))
+that k is sometimes confusingly called an "exponent" in this case.((("",startref="eliptic04")))
 
 [[public_key_derivation]]
 ==== Public Keys
 
-((("keys and addresses", "overview of", "public key
-calculation")))The public key is calculated from
+((("keys and addresses", "overview of", "public keycalculation")))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
@@ -316,8 +308,7 @@ mathematical trick becomes the basis for unforgeable and secure digital
 signatures that prove control over bitcoin funds.
 ====
 
-((("keys and addresses", "overview of", "public key
-generation")))Starting with a private key in the
+((("keys and addresses", "overview of", "public keygeneration")))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
@@ -616,8 +607,7 @@ look at compact encoding and reliable checksums.
 [[base58]]
 === Base58Check Encoding
 
-((("keys and addresses", "Bitcoin addresses", "base58 and base58check
-encoding")))((("base58 and base58check encoding",
+((("keys and addresses", "Bitcoin addresses", "base58 and base58checkencoding")))((("base58 and base58check encoding",
 id="base5804")))((("addresses", "base58 and base58check encoding",
 id="Abase5804")))In order to represent long numbers in a compact way,
 using fewer symbols, many computer systems use mixed-alphanumeric
@@ -1506,8 +1496,7 @@ such as vanity addresses and paper wallets.
 
 ==== Vanity Addresses
 
-((("keys and addresses", "advanced forms", "vanity
-addresses")))((("addresses",
+((("keys and addresses", "advanced forms", "vanityaddresses")))((("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
@@ -1534,8 +1523,7 @@ organizing a fundraising drive and wants to use a vanity Bitcoin
 address to publicize the fundraising. Eugenia will create a vanity
 address that starts with "1Kids" to promote the children's charity
 fundraiser. Let's see how this vanity address will be created and what
-it means for the security of Eugenia's charity.((("use cases",
-"charitable donations", startref="eugeniafour")))
+it means for the security of Eugenia's charity.((("use cases","charitable donations", startref="eugeniafour")))
 
 ===== Generating vanity addresses
 
@@ -1634,8 +1622,7 @@ the future unless the above problems are solved.
 [[paper_wallets]]
 ==== Paper Wallets
 
-((("paper
-wallets", id="paperw04")))((("wallets", "types of", "paper wallets",
+((("paperwallets", 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
 for convenience, but this is not necessary because it can be derived
@@ -1679,8 +1666,7 @@ 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="Wpaper04")))
+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

@@ -13,8 +13,7 @@ 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.
 
-((("central
-trusted authority")))Mining _secures the Bitcoin system_ and enables the
+((("centraltrusted authority")))Mining _secures the Bitcoin system_ and enables the
 emergence of network-wide _consensus without a central authority_.
 The reward of newly minted bitcoins and
 transaction fees is an incentive scheme that aligns the actions of
@@ -52,8 +51,7 @@ 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>>.
 
-((("mining and consensus", "mining rewards
-and fees")))((("mining and consensus",
+((("mining and consensus", "mining rewardsand 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
@@ -102,8 +100,7 @@ consensus.
 
 === Bitcoin Economics and Currency Creation
 
-((("mining and consensus", "bitcoin economics and currency
-creation")))((("issuance
+((("mining and consensus", "bitcoin economics and currencycreation")))((("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
@@ -206,8 +203,7 @@ outweighs the risks of deflation.
 
 === Decentralized Consensus
 
-((("decentralized
-systems", "consensus in")))In the previous chapter we looked at the
+((("decentralizedsystems", "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
 ownership transfers.
@@ -226,8 +222,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.
 
-((("mining and consensus", "emergent
-consensus")))One of Satoshi Nakamoto's inventions is the decentralized
+((("mining and consensus", "emergentconsensus")))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
 occurs. Instead, consensus is an emergent artifact of the asynchronous
@@ -260,8 +255,7 @@ trusted, public, global blockchain.
 [[tx_verification]]
 === Independent Verification of Transactions
 
-((("mining and consensus", "independent transaction
-verification")))In
+((("mining and consensus", "independent transactionverification")))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,8 +310,7 @@ _mempool_.
 
 === Mining Nodes
 
-((("Bitcoin nodes", "mining
-nodes")))Some of the nodes on the Bitcoin network are specialized nodes
+((("Bitcoin nodes", "miningnodes")))Some of the nodes on the Bitcoin network are specialized nodes
 called _miners_. Jing is a
 Bitcoin miner; he
 earns bitcoin by running a "mining rig," which is a specialized
@@ -352,8 +345,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.
 
-((("mining and consensus", "Proof-of-Work
-algorithm")))Jing's node immediately constructs a new partial block, a
+((("mining and consensus", "Proof-of-Workalgorithm")))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
 proof-of-work. The block becomes valid only if the miner succeeds in
@@ -365,8 +357,7 @@ transaction fees he'll attempt to claim.
 
 ==== The Coinbase Transaction
 
-((("transactions",
-"coinbase transactions", id="Tcoinb10")))The first transaction in any
+((("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
 the mining effort.
@@ -389,8 +380,7 @@ reward.
 
 ==== Coinbase Reward and Fees
 
-((("fees", "transaction
-fees")))To construct the
+((("fees", "transactionfees")))To construct the
 coinbase transaction, Jing's node first calculates the total amount of
 transaction fees:
 
@@ -510,8 +500,7 @@ 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.
 
-((("blockchain
-(the)", "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 +515,7 @@ version field set to 2 or higher) must contain the block height as a script
 
 === Constructing the Block Header
 
-((("blocks",
-"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>>.
 
@@ -641,8 +629,7 @@ until the desired hash result appears by chance.
 
 ==== Proof-of-Work Algorithm
 
-((("mining and consensus",
-"Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an
+((("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
@@ -768,8 +755,7 @@ enough block header hash.
 
 //TODO:use visual representation like I did on bitcoin.org
 
-((("mining and consensus", "mining the block", "target
-representation")))
+((("mining and consensus", "mining the block", "targetrepresentation")))
 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
@@ -824,8 +810,7 @@ terahash per second or 1 TH/sec) would only find a solution once every
 [[target]]
 ==== Retargeting to Adjust Difficulty
 
-((("mining and consensus", "mining the block", "retargeting to adjust
-difficulty")))As we saw, the target determines the difficulty and
+((("mining and consensus", "mining the block", "retargeting to adjustdifficulty")))As we saw, the target determines the difficulty and
 therefore affects how long it takes to find a solution to the
 Proof-of-Work algorithm. This leads to the obvious questions: Why is the
 difficulty adjustable, who adjusts it, and how?
@@ -987,8 +972,7 @@ sequence, +CLTV+, and +CSV+.
 
 === Successfully Mining the Block
 
-((("mining and consensus", "mining the block", "successful
-completion")))As
+((("mining and consensus", "mining the block", "successfulcompletion")))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
@@ -1020,13 +1004,11 @@ 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")))
+that forms the decentralized blockchain.((("",startref="MACmining10")))
 
 === Validating a New Block
 
-((("blocks", "new
-block validation")))The third step in Bitcoin's
+((("blocks", "newblock 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.
@@ -1077,8 +1059,7 @@ independent validation is a key component of decentralized consensus.
 [[forks]]
 === Assembling and Selecting Chains of Blocks
 
-((("mining and consensus", "assembling and selecting chains of blocks",
-id="MACassembling10")))((("blocks", "assembling and selecting chains
+((("mining and consensus", "assembling and selecting chains of blocks",id="MACassembling10")))((("blocks", "assembling and selecting chains
 of", id="Bassemble10")))The final part in Bitcoin's decentralized
 consensus mechanism is the assembly of blocks into chains and the
 selection of the chain with the most Proof-of-Work.
@@ -1153,14 +1134,12 @@ forks (in addition to other problems), so many people prefer Bitcoin's
 10-minute blocks over shorter block intervals.
 ====
 
-((("",
-startref="Bassemble10")))((("",
+((("",startref="Bassemble10")))((("",
 startref="forks10")))
 
 === Mining and the Hash Lottery
 
-((("mining and consensus", "hashing power race",
-id="MAChash10")))Bitcoin mining is an extremely competitive industry.
+((("mining and consensus", "hashing power race",id="MAChash10")))Bitcoin mining is an extremely competitive industry.
 The hashing power has increased exponentially every year of Bitcoin's
 existence. Some years the growth has reflected a complete change of
 technology, such as in 2010 and 2011 when many miners switched from
@@ -1222,8 +1201,7 @@ entire left flank of the merkle tree up to the root.
 [[mining_pools]]
 ==== Mining Pools
 
-((("mining pools", "benefits
-of")))In this highly competitive environment, individual miners working
+((("mining pools", "benefitsof")))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
 is so low that it represents a gamble, like playing the lottery. Even
@@ -1322,8 +1300,7 @@ whole pool wins.
 
 ===== Managed pools
 
-((("pool operators",
-seealso="mining pools")))Most mining pools are "managed," meaning that
+((("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
 percentage fee of the earnings.
@@ -1356,8 +1333,7 @@ using their own full node.
 
 ===== Peer-to-peer mining pool (P2Pool)
 
-((("peer-to-peer
-pools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by
+((("peer-to-peerpools (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>>).
 Furthermore, centralized pool servers represent a
@@ -1402,8 +1378,7 @@ attack problem for bitcoin itself. Rather, P2Pool makes bitcoin more
 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")))
+include in their blocks.((("",startref="MAChash10")))
 
 [[consensus_attacks]]
 === Hashrate Attacks
@@ -1443,8 +1418,7 @@ a transaction allows the attacker can get an irreversible exchange payment or
 product without paying for it.
 
 Let's examine a practical example of a 51% attack. In the first chapter,
-we looked at a transaction between ((("use cases", "buying
-coffee")))Alice and Bob. Bob, the seller, is
+we looked at a transaction between ((("use cases", "buyingcoffee")))Alice and Bob. Bob, the seller, is
 willing to accept payment without waiting for
 confirmation (mining in a block), because the risk of a double-spend on
 a small item is low in comparison to the convenience of rapid
@@ -1463,8 +1437,7 @@ the corresponding transaction in the old chain.
 //TODO:distinguish between majority attack and sub-majority "reorg"
 //attack.
 
-In our example, malicious attacker Mallory goes to ((("use cases",
-"retail sales", id="carolten")))Carol's gallery and purchases a
+In our example, malicious attacker Mallory goes to ((("use cases","retail sales", id="carolten")))Carol's gallery and purchases a
 set of beautiful paintings depicting Satoshi Nakamoto as Prometheus.
 Carol sells the paintings for $250,000 in bitcoins to
 Mallory. Instead of waiting for six or more confirmations on the
@@ -1488,8 +1461,7 @@ pool participants might remain blissfully unaware of the double-spend
 attempt, because they mine with automated miners and cannot monitor
 every transaction or block.
 
-((("confirmations", "of large-value transactions",
-secondary-sortas="large-value transactions")))To protect against this
+((("confirmations", "of large-value transactions",secondary-sortas="large-value transactions")))To protect against this
 kind of attack, a merchant selling large-value items must wait at least
 six confirmations before giving the product to the buyer. Waiting for
 more than six confirmations may sometimes be warranted.  Alternatively,
@@ -1557,8 +1529,7 @@ Bitcoin community.
 [[consensus_changes]]
 === Changing the Consensus Rules
 
-((("mining and consensus", "consensus rules", "changing",
-id="Crule10")))The rules of consensus determine the validity of
+((("mining and consensus", "consensus rules", "changing",id="Crule10")))The rules of consensus determine the validity of
 transactions and blocks. These rules are the basis for collaboration
 between all Bitcoin nodes and are responsible for the convergence of all
 local perspectives into a single consistent blockchain across the entire
@@ -1575,8 +1546,7 @@ between all participants.
 [[hard_forks]]
 ==== Hard Forks
 
-((("forks",
-"changing consensus rules", "hard forks")))In <<forks>> we looked at how
+((("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
 saw how this process occurs naturally, as part of the normal operation
@@ -1705,8 +1675,7 @@ they are connected to two separate networks.
 
 ==== Diverging Miners and Difficulty
 
-((("forks", "changing consensus rules", "diverging miners and
-difficulty")))As miners diverge into mining two different chains, the
+((("forks", "changing consensus rules", "diverging miners anddifficulty")))As miners diverge into mining two different chains, the
 hashing power is split between the chains. The mining power can be split
 in any proportion between the two chains. The new rules may only be
 followed by a minority, or by the vast majority of the mining power.
@@ -1739,8 +1708,7 @@ transactions.
 
 ==== Contentious Hard Forks
 
-((("forks", "changing consensus rules", "contentious hard
-forks")))This is the dawn of the development of software
+((("forks", "changing consensus rules", "contentious hardforks")))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,8 +1733,7 @@ consensus modifications.
 
 ==== Soft Forks
 
-((("soft forks",
-"defined")))Not all consensus rule changes cause a hard fork. Only
+((("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
 the transaction or block as valid under the previous rules, the change
@@ -1792,8 +1759,7 @@ nonupgraded nodes out of consensus.
 
 ===== Soft forks redefining NOP opcodes
 
-((("soft forks",
-"redefinition of NOP codes")))Two soft forks have been
+((("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
 NOP10. Under the consensus rules, the presence of these opcodes in a
@@ -1811,8 +1777,7 @@ the old clients, the script contains an NOP code, which is ignored.
 
 ==== Criticisms of Soft Forks
 
-((("soft
-forks", "drawbacks of")))Soft forks based on the NOP opcodes are
+((("softforks", "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.
 
@@ -1845,8 +1810,7 @@ lead to loss of funds.
 [[softforksignaling]]
 === Soft Fork Signaling with Block Version
 
-((("forks", "changing consensus rules", "soft fork
-activation")))Since soft forks allow
+((("forks", "changing consensus rules", "soft forkactivation")))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
@@ -1856,8 +1820,7 @@ This mechanism was introduced by BIP34.
 
 ==== BIP34 Signaling and Activation
 
-((("bitcoin improvement proposals", "Block v2, Height in Coinbase
-(BIP34)")))BIP34 used the block version
+((("bitcoin improvement proposals", "Block v2, Height in Coinbase(BIP34)")))BIP34 used the block version
 field to allow miners to signal readiness for a specific consensus rule
 change. Prior to BIP34, the block version was set to "1" by
 _convention_ not enforced by _consensus_.
@@ -1914,8 +1877,7 @@ described next.
 [[bip9]]
 ==== BIP9 Signaling and Activation
 
-((("bitcoin improvement proposals", "Version bits with timeout and delay
-(BIP9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY
+((("bitcoin improvement proposals", "Version bits with timeout and delay(BIP9)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY
 (BIP65)")))((("bitcoin improvement proposals", "Strict DER signatures
 (BIP66)")))The mechanism used by BIP34, BIP66, and BIP65 was
 successful in activating three soft forks. However, it was replaced
@@ -2095,8 +2057,7 @@ future attempt to activate a soft fork.
 
 === Consensus Software Development
 
-((("mining and consensus", "consensus software
-development")))((("development environment", "consensus software
+((("mining and consensus", "consensus softwaredevelopment")))((("development environment", "consensus software
 development")))Consensus software continues to evolve and there is much
 discussion on the various mechanisms for changing the consensus rules.
 By its very nature, Bitcoin sets a very high bar on coordination and

network.adoc

@@ -1,8 +1,7 @@
 [[bitcoin_network_ch08]]
 == The Bitcoin Network
 
-((("peer-to-peer
-(P2P)")))Bitcoin is structured as a peer-to-peer network architecture on
+((("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
 they can all perform the same functions, and that there are no "special" nodes.
@@ -40,8 +39,7 @@ protocols in this chapter in addition to the base Bitcoin P2P protocol.
 
 === Node Types and Roles
 
-((("Bitcoin network", "node types and roles",
-id="BNnode08")))((("Bitcoin nodes", "types and roles",
+((("Bitcoin network", "node types and roles",id="BNnode08")))((("Bitcoin nodes", "types and roles",
 id="BNtype08")))Although full nodes (peers) in the Bitcoin P2P network are equal to each other,
 they may take on different roles depending on the functionality they are
 supporting. A Bitcoin full node validates blocks and may contain other
@@ -52,11 +50,9 @@ complete and up-to-date copy of the blockchain.
 Those nodes can
 serve data to clients that store
 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.
+called _simplified payment verification_, or SPV. ((("lightweightclients")))These clients are known as lightweight clients.
 
-((("mining and consensus", "mining
-nodes")))((("mining and consensus",
+((("mining and consensus", "miningnodes")))((("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,8 +70,7 @@ mining pool protocols and lightweight client-access protocols.
 
 === The Network
 
-((("Bitcoin
-network", "extended network activities")))As of this writing, the main Bitcoin network,
+((("Bitcoinnetwork", "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
 hundred nodes running various other implementations of the Bitcoin P2P
@@ -249,8 +244,7 @@ several Virtual Private Servers (VPSes) hosted on
 infrastructure around the world and served to connect the majority of
 miners and mining pools.
 
-((("Compact Block
-optimization")))The original Bitcoin Relay Network was replaced in 2016
+((("Compact Blockoptimization")))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
 Corallo. FIBRE is software that allows operating a UDP-based relay network that relays blocks within a
@@ -259,8 +253,7 @@ further reduce the amount of data transmitted and the network latency.
 
 === Network Discovery
 
-((("Bitcoin network", "extended network discovery",
-id="BNextend08")))((("Bitcoin nodes", "network discovery",
+((("Bitcoin network", "extended network discovery",id="BNextend08")))((("Bitcoin nodes", "network discovery",
 id="BNodiscover08")))When a new node boots up, it must discover other
 Bitcoin nodes on the network in order to participate. To start this
 process, a new node must discover at least one existing node on the
@@ -325,8 +318,7 @@ connected. Additionally, the newly connected node can send +getaddr+ to
 the neighbors, asking them to return a list of IP addresses of other
 peers. That way, a node can find peers to connect to and advertise its
 existence on the network for other nodes to find it.
-<<address_propagation>> ((("propagation", "address propagation and
-discovery")))shows the address discovery protocol.
+<<address_propagation>> ((("propagation", "address propagation anddiscovery")))shows the address discovery protocol.
 
 
 [[address_propagation]]
@@ -418,16 +410,14 @@ message to maintain the connection. If a node has not communicated on a
 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")))
+shrink as needed without any central control.((("",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.
 
-((("blockchain
-(the)", "genesis block")))Full nodes
+((("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
 network. A full node can independently and authoritatively
@@ -607,14 +597,12 @@ 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="simple08")))
+rather than fixed patterns.((("",startref="simple08")))
 
 [[bloom_filters]]
 === Bloom Filters
 
-((("bloom
-filters", id="bloom08")))((("privacy, maintaining",
+((("bloomfilters", id="bloom08")))((("privacy, maintaining",
 id="privacy08")))((("security", "maintaining privacy",
 id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way
 to describe a desired pattern without specifying it exactly. Bloom
@@ -1138,8 +1126,7 @@ client.
 
 === Encrypted and Authenticated Connections
 
-((("Bitcoin network", "encrypted
-connections")))Most new users of
+((("Bitcoin network", "encryptedconnections")))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
@@ -1183,8 +1170,7 @@ online tutorials.
 [[mempool]]
 === Mempools and orphan pools
 
-((("transaction
-pools")))Almost every node on the Bitcoin
+((("transactionpools")))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

overview.adoc

@@ -1,8 +1,7 @@
 [[ch02_bitcoin_overview]]
 == How Bitcoin Works
 
-((("central trusted
-authority")))((("decentralized systems", "bitcoin overview",
+((("central trustedauthority")))((("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
 trusted authority, in Bitcoin, each user can use software running on
@@ -103,8 +102,7 @@ image::images/mbc2_0202.png["payment-request"]
 
 [TIP]
 ====
-((("transactions", "warnings
-and cautions")))((("warnings and cautions", "avoid sending money to
+((("transactions", "warningsand 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.
 ====
@@ -168,8 +166,7 @@ owner, and so on, in a chain of ownership.
 
 ==== Transaction Inputs and Outputs
 
-((("outputs and
-inputs", "basics of")))Transactions are like lines in a double-entry
+((("outputs andinputs", "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.
@@ -252,8 +249,7 @@ that's what the protocol itself uses.
 
 ==== Making Change
 
-((("addresses", "change
-addresses")))In addition to one or more outputs that pay the receiver of
+((("addresses", "changeaddresses")))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.
 This is because transaction inputs,
@@ -335,8 +331,7 @@ image::images/mbc2_0207.png["Distributing Transaction"]
 
 === Constructing a Transaction
 
-((("wallets",
-"constructing transactions")))Alice's wallet application contains all
+((("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
 destination, amount, and transaction fee, and the rest happens in the wallet
@@ -440,8 +435,7 @@ to another program (such as a block explorer) that will relay it to a
 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")))Any Bitcoin node that receives a
+options are possible, too. ((("propagation", "floodingtechnique")))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
@@ -462,8 +456,7 @@ wallet can further verify Alice's transaction only spends valid UTXOs.
 
 === Bitcoin Mining
 
-((("mining and consensus", "overview of",
-id="MACover02")))((("blockchain (the)", "overview of mining",
+((("mining and consensus", "overview of",id="MACover02")))((("blockchain (the)", "overview of mining",
 id="BToverview02")))Alice's transaction is now propagated on the Bitcoin
 network. It does not become part of the _blockchain_ until it is
 included in a block by a process called _mining_ and that block has been
@@ -477,8 +470,7 @@ amount of computation to get right--but only a small amount of
 computation to verify as correct.
 The mining process serves two purposes in Bitcoin:
 
-* ((("mining and consensus", "consensus rules", "security provided
-by")))Miners can only
+* ((("mining and consensus", "consensus rules", "security providedby")))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
@@ -535,8 +527,7 @@ the block reward plus the sum of
 transaction fees from all the transactions included in the candidate block. If they
 finds a solution that makes the candidate into a valid block, they receives this reward
 after his successful block is added to the global blockchain and the
-reward transaction he included becomes spendable. ((("mining pools",
-"operation of")))Miners who participates in a mining pool have set up their
+reward transaction he included becomes spendable. ((("mining pools","operation of")))Miners who participates in a mining pool have set up their
 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.
@@ -596,8 +587,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.
 
-((("blockchain
-(the)", "genesis block")))In <<block-alice1>>,  we can
+((("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
 blocks (blockchain) all the way back to block #0, known as the _genesis
@@ -607,8 +597,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="MACover02")))
+<<mining>>.((("",startref="MACover02")))
 
 [[block-alice1]]
 .Alice's transaction included in a block

security.adoc

@@ -20,8 +20,7 @@ need to think about securing your bitcoins in a novel way too.
 
 === Security Principles
 
-((("decentralized
-systems", "security of")))The core principle in Bitcoin is
+((("decentralizedsystems", "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,
 depends on access control and vetting to keep bad actors out of the
@@ -141,13 +140,11 @@ this point because their security architecture and design fails even
 under the most casual scrutiny. These centralized implementations had
 invested trust explicitly in numerous components outside the Bitcoin
 blockchain, such as hot wallets, centralized databases,
-vulnerable encryption keys, and similar schemes.((("",
-startref="Sprinc11")))
+vulnerable encryption keys, and similar schemes.((("",startref="Sprinc11")))
 
 === User Security Best Practices
 
-((("use
-cases", "user security best practices", id="UCsecurity11")))Humans have
+((("usecases", "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
 general-purpose operating systems are not very secure and not
@@ -193,8 +190,7 @@ we will examine various best practices for practical user security.
 
 ==== Physical Bitcoin Storage
 
-((("paper
-wallets")))((("paper
+((("paperwallets")))((("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
@@ -213,8 +209,7 @@ stick.
 
 ==== Hardware Signing Devices
 
-((("hardware
-signing devices")))In the long term, Bitcoin security may increasingly take the
+((("hardwaresigning devices")))In the long term, Bitcoin security may increasingly take the
 form of tamper-proof hardware signing devices. Unlike a smartphone or desktop
 computer, a Bitcoin hardware signing device only needs to hold keys and
 use them to generate signatures.  Without general-purpose software to
@@ -262,8 +257,7 @@ storage).
 
 ==== Multisig and Governance
 
-((("addresses", "multisig
-addresses")))Whenever a company or individual stores large amounts of
+((("addresses", "multisigaddresses")))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
 signature to make a payment. The signing keys should be stored in a
@@ -277,8 +271,7 @@ stored in different locations.
 
 ==== Survivability
 
-((("passwords",
-"survivability and")))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
@@ -291,8 +284,7 @@ existence of the bitcoin funds.
 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")))
+lawyer specialized as a "digital asset executor."((("",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,8 +1,7 @@
 [[c_signatures]]
 == Digital Signatures
 
-((("Elliptic Curve Digital
-Signature Algorithm (ECDSA)")))Two signature algorithms are currently
+((("Elliptic Curve DigitalSignature Algorithm (ECDSA)")))Two signature algorithms are currently
 used in Bitcoin, the _schnorr signature algorithm_ and the _Elliptic
 Curve Digital Signature Algorithm_ (_ECDSA_).
 These algorithms are used for digital signatures based on elliptic
@@ -94,8 +93,7 @@ signature on this transaction."
 [[sighash_types]]
 ==== Signature Hash Types (SIGHASH)
 
-((("digital signatures", "signature hash
-types")))Digital signatures apply to messages,
+((("digital signatures", "signature hashtypes")))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
@@ -176,8 +174,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+ :: ((("use cases",
-"charitable donations")))This construction can be used to make a
++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
 output pays the "goal" amount to the fundraiser. Such a transaction is
@@ -910,8 +907,7 @@ 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.
 
-((("entropy", "random
-number generation")))To avoid this
+((("entropy", "randomnumber 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
@@ -933,8 +929,7 @@ fault-injection attacks.
 
 If you are implementing an algorithm to sign transactions in Bitcoin,
 you _must_ use BIP340, RFC6979, or a similar algorithm to
-ensure you generate a different _k_ for each transaction.((("",
-startref="Tdigsig06")))
+ensure you generate a different _k_ for each transaction.((("",startref="Tdigsig06")))
 
 === Segregated Witness's New Signing Algorithm
 

wallets.adoc

@@ -211,8 +211,7 @@ We'll provide a detailed exploration of HD wallets in <<hd_wallet_details>>.
 
 ==== Seeds and Recovery Codes
 
-((("recovery
-code words")))((("bitcoin improvement proposals", "Recovery Code Words
+((("recoverycode 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
 is ever corrupted or lost, you can regenerate all of the private keys
@@ -624,8 +623,7 @@ modern standards that may provide additional features or safety.
 [[recovery_code_words]]
 ==== BIP39 Recovery Codes
 
-((("recovery code
-words", id="mnemonic05")))((("bitcoin improvement proposals", "Recovery
+((("recovery codewords", 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
 derive a deterministic wallet. The sequence of words is sufficient to
@@ -903,8 +901,7 @@ her family to recover the cryptocurrency estate.
 [[hd_wallet_details]]
 ==== Creating an HD Wallet from the Seed
 
-((("wallets", "technology of", "creating HD wallets from root
-seed")))((("hierarchical deterministic (HD)
+((("wallets", "technology of", "creating HD wallets from rootseed")))((("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,8 +933,7 @@ creates child keys from parent keys, as we will see in the next section.
 
 ===== Private child key derivation
 
-((("public and private keys", "child
-key derivation (CKD)")))HD wallets use a _child key derivation_ (CKD)
+((("public and private keys", "childkey derivation (CKD)")))HD wallets use a _child key derivation_ (CKD)
 function to derive child keys from parent keys.
 
 The child key derivation functions are based on a one-way hash function
@@ -1133,8 +1129,7 @@ address for the actual transaction.  However, these other solutions have
 not been used in production as of this writing.
 ****
 
-((("hardware
-wallets")))Another common application of this solution is for
+((("hardwarewallets")))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
 the extended public key can be kept online. The
@@ -1150,8 +1145,7 @@ image::images/mbc2_0511.png["ChildPublicDerivation"]
 
 ==== Using an Extended Public Key on a Web Store
 
-((("wallets", "technology of", "using extended public keys on web
-stores")))Let's see how HD wallets are used by looking at
+((("wallets", "technology of", "using extended public keys on webstores")))Let's see how HD wallets are used by looking at
 Gabriel's web store.
 
 Gabriel first set up his web store as a hobby, based on a simple hosted
@@ -1205,8 +1199,7 @@ software, such as the widely used open source BTCPay Server.
 
 ===== Hardened child key derivation
 
-((("public and private keys", "hardened child key
-derivation")))The ability to derive a branch
+((("public and private keys", "hardened child keyderivation")))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