From bc53bf0e0854194c8188e841e4621ae4dcd14e0a Mon Sep 17 00:00:00 2001 From: theresa jones Date: Fri, 8 Sep 2023 19:25:18 -0700 Subject: [PATCH] removing additional line breaks from index tags --- applications.adoc | 6 ++---- authorization-authentication.adoc | 27 +++++++++------------------ bitcoin-core.adoc | 21 +++++++-------------- fees.adoc | 3 +-- intro.adoc | 15 +++++---------- keys.adoc | 15 +++++---------- mining.adoc | 18 ++++++------------ network.adoc | 12 ++++-------- overview.adoc | 9 +++------ security.adoc | 3 +-- wallets.adoc | 9 +++------ 11 files changed, 46 insertions(+), 92 deletions(-) diff --git a/applications.adoc b/applications.adoc index ac915fee..b1aaa594 100644 --- a/applications.adoc +++ b/applications.adoc @@ -357,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_ ((("payment (state) channels", -"defined")))are a trustless mechanism for exchanging Bitcoin +_Payment channels_ ((("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 blockchain, are held offchain instead, waiting for @@ -969,8 +968,7 @@ know the secret +R+. [[lightning_network]] === Routed Payment Channels (Lightning Network) -((("routed payment -channels", see="Lightning Network")))((("Lightning Network", +((("routed paymentchannels", 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 can allow any participant to route a payment from channel to channel diff --git a/authorization-authentication.adoc b/authorization-authentication.adoc index 251db7d7..2390c0e0 100644 --- a/authorization-authentication.adoc +++ b/authorization-authentication.adoc @@ -25,8 +25,7 @@ used. [role="pagebreak-before less_space_h1"] === Transaction Scripts and Script Language -((("scripting", "transactions and", -id="Stransact06")))The original version of Bitcoin introduced a new +((("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 input script used in a spending transaction are written in this scripting @@ -312,8 +311,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"] [[multisig]] === Scripted multisignatures -((("scripting", -"multisignature scripts", id="Smulti07")))((("multisignature +((("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 signatures to spend the funds, called t-of-k. @@ -475,8 +473,7 @@ 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. -((("Pay-to-Script-Hash -(P2SH)", "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 corporate accounts. Multisignature scripts are one of the most common @@ -609,8 +606,7 @@ If the redeem script hash matches, the redeem script is executed: ==== P2SH Addresses -((("bitcoin -improvement proposals", "Address Format for P2SH (BIP13)")))Another +((("bitcoinimprovement 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 encodings of the 20-byte hash of a script, just like Bitcoin addresses @@ -680,8 +676,7 @@ spent. [[op_return]] === Data Recording Output (OP_RETURN) -((("data recording -(nonpayment data)")))((("blockchain (the)", +((("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 @@ -771,8 +766,7 @@ It is important to understand the limitations of transaction lock time. The only ==== Check Lock Time Verify (OP_CLTV) -((("scripting", "timelocks", "Check Lock Time -Verify (OP_CLTV)")))((("bitcoin improvement proposals", +((("scripting", "timelocks", "Check Lock TimeVerify (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 specification in BIP65, a new script operator called @@ -887,8 +881,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65 [[op_csv]] ==== Relative Timelocks -Lock time and +OP_CLTV+ are ((("scripting", "timelocks", "relative -timelocks")))both +Lock time and +OP_CLTV+ are ((("scripting", "timelocks", "relativetimelocks")))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 @@ -909,8 +902,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", "CHECKSEQUENCEVERIFY (BIP112)")))Relative timelocks are +((("bitcoin improvementproposals", "CHECKSEQUENCEVERIFY (BIP112)")))Relative timelocks are implemented according to the specifications in https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68, Relative lock-time using consensus-enforced sequence numbers] and @@ -961,8 +953,7 @@ CHECKSEQUENCEVERIFY]. === Scripts with Flow Control (Conditional Clauses) -((("conditional clauses", -id="condition07")))One of the more +((("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 various programming languages that use the construct +IF...THEN...ELSE+. diff --git a/bitcoin-core.adoc b/bitcoin-core.adoc index 305be916..a3ed1f16 100644 --- a/bitcoin-core.adoc +++ b/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! -((("Bitcoin Core", "reference -implementation")))When Bitcoin was created by Satoshi Nakamoto, the +((("Bitcoin Core", "referenceimplementation")))When Bitcoin was created by Satoshi Nakamoto, the software was mostly completed before publication of the whitepaper reproduced in <>. Satoshi wanted to make sure the implementation worked before publishing a paper about it. That first implementation, then simply @@ -78,8 +77,7 @@ next chapter, which is less technical. [[compiling_core]] === Compiling Bitcoin Core from the Source Code -((("Bitcoin Core", "compiling from source code", -"downloading")))Bitcoin Core's +((("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. On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed @@ -185,8 +183,7 @@ nothing to commit, working tree clean ==== Configuring the Bitcoin Core Build -((("build documentation", -seealso="Bitcoin Core")))The source code includes documentation, which +((("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. In this chapter, we will build the Bitcoin Core daemon @@ -427,8 +424,7 @@ node. ==== Configuring the Bitcoin Core Node -((("passwords", -"creating")))Bitcoin Core will look for a +((("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 configuration file. To locate the configuration file, run +bitcoind @@ -519,8 +515,7 @@ Use it to reduce memory use on memory-constrained nodes. [[txindex]] .Transaction Database Index and txindex Option **** -((("transactions", "database configuration -options")))By default, +((("transactions", "database configurationoptions")))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 @@ -1115,8 +1110,7 @@ spot the difference. [[alt_libraries]] === Alternative Clients, Libraries, and Toolkits -((("libraries, clients, and -toolkits", id="librar03")))((("toolkits, libraries, and clients", +((("libraries, clients, andtoolkits", id="librar03")))((("toolkits, libraries, and clients", id="toolkit03")))There are many alternative clients, libraries, toolkits, and even full-node implementations in the bitcoin ecosystem. These are implemented in a @@ -1154,8 +1148,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="toolkit03"))) +and more are created all the time.((("",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 diff --git a/fees.adoc b/fees.adoc index bc38ac99..2dc773c3 100644 --- a/fees.adoc +++ b/fees.adoc @@ -620,8 +620,7 @@ you intended. [[fee_sniping]] === Timelock Defense Against Fee Sniping -((("timelocks", "defense against -fee-sniping")))((("security", "defense +((("timelocks", "defense againstfee-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 diff --git a/intro.adoc b/intro.adoc index e4e98bca..f4e94fdc 100644 --- a/intro.adoc +++ b/intro.adoc @@ -106,8 +106,7 @@ alias of Satoshi Nakamoto (see <>). 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. ((("mining and consensus", "Proof-of-Work -algorithm")))A key innovation was to use a distributed computation +of transactions. ((("mining and consensus", "Proof-of-Workalgorithm")))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. This @@ -141,8 +140,7 @@ authority_, represents a breakthrough in distributed computing. === Getting Started -((("wallets", "selecting", -id="Wselect01")))((("bitcoin", "getting started", +((("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 most common user interface to the Bitcoin system, just like a web @@ -260,8 +258,7 @@ interact with the network in different ways. ==== Quick Start -((("wallets", "quick start example", -id="Wquick01")))Alice is not a +((("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 Bitcoin to everyone around him and is offering a demonstration. Intrigued, @@ -410,8 +407,7 @@ Here are some methods for acquiring bitcoin as a new user: [TIP] ==== -((("currency -exchanges")))((("digital currencies", "benefits of +((("currencyexchanges")))((("digital currencies", "benefits 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 @@ -451,8 +447,7 @@ currencies. [[sending_receiving]] ==== Sending and Receiving Bitcoin -((("spending bitcoin", "bitcoin wallet quick start -example")))Alice has +((("spending bitcoin", "bitcoin wallet quick startexample")))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 diff --git a/keys.adoc b/keys.adoc index 40bb9a96..ee9614b7 100644 --- a/keys.adoc +++ b/keys.adoc @@ -61,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. ==== -((("cryptography", "elliptic -curve cryptography")))A Bitcoin wallet contains a collection of key +((("cryptography", "ellipticcurve 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. From the private key, we @@ -159,8 +158,7 @@ visible universe is estimated to contain 10^80^ atoms. [[elliptic_curve]] ==== Elliptic Curve Cryptography Explained -((("elliptic curve cryptography", -id="eliptic04")))((("cryptography", "elliptic curve cryptography", +((("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 expressed by addition and multiplication on the points of an elliptic @@ -607,8 +605,7 @@ look at compact encoding and reliable checksums. [[base58]] === Base58Check Encoding -((("base58 and base58check encoding", -id="base5804")))((("addresses", "base58 and base58check encoding", +((("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 representations with a base (or radix) higher than 10. For example, @@ -1496,8 +1493,7 @@ such as vanity addresses and paper wallets. ==== Vanity Addresses -((("addresses", -"vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin +((("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 the letters forming the word "Love" as the first four base58 letters. @@ -1622,8 +1618,7 @@ the future unless the above problems are solved. [[paper_wallets]] ==== Paper Wallets -((("wallets", "types of", "paper wallets", -id="Wpaper04")))Paper wallets are private keys printed on paper. +((("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 from the private key. diff --git a/mining.adoc b/mining.adoc index cb25964d..a0af3002 100644 --- a/mining.adoc +++ b/mining.adoc @@ -51,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 <>. -((("mining and consensus", -"Proof-of-Work algorithm")))Miners receive two types of rewards in +((("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 the block. To earn this reward, miners compete to satisfy a challenge @@ -100,8 +99,7 @@ consensus. === Bitcoin Economics and Currency Creation -((("issuance -rate")))Bitcoin are minted during the creation of each block at a +((("issuancerate")))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 210,000 blocks, or approximately every four years, the currency issuance @@ -1059,8 +1057,7 @@ independent validation is a key component of decentralized consensus. [[forks]] === Assembling and Selecting Chains of Blocks -((("blocks", "assembling and selecting chains -of", id="Bassemble10")))The final part in Bitcoin's decentralized +((("blocks", "assembling and selecting chainsof", 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. @@ -1134,8 +1131,7 @@ forks (in addition to other problems), so many people prefer Bitcoin's 10-minute blocks over shorter block intervals. ==== -((("", -startref="forks10"))) +((("",startref="forks10"))) === Mining and the Hash Lottery @@ -1877,8 +1873,7 @@ described next. [[bip9]] ==== BIP9 Signaling and Activation -((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY -(BIP65)")))((("bitcoin improvement proposals", "Strict DER signatures +((("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 because it had several limitations: @@ -2057,8 +2052,7 @@ future attempt to activate a soft fork. === Consensus Software Development -((("development environment", "consensus software -development")))Consensus software continues to evolve and there is much +((("development environment", "consensus softwaredevelopment")))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 consensus for changes. As a decentralized system, it has no "authority" diff --git a/network.adoc b/network.adoc index 73d9a62e..9fca572f 100644 --- a/network.adoc +++ b/network.adoc @@ -39,8 +39,7 @@ protocols in this chapter in addition to the base Bitcoin P2P protocol. === Node Types and Roles -((("Bitcoin nodes", "types and roles", -id="BNtype08")))Although full nodes (peers) in the Bitcoin P2P network are equal to each other, +((("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 functions, such as routing, mining, and wallet services. @@ -52,8 +51,7 @@ 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. These clients are known as lightweight clients. -((("mining and consensus", -"Proof-of-Work algorithm")))Miners compete to create new blocks by +((("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 blockchain, while others are clients participating in pool @@ -253,8 +251,7 @@ further reduce the amount of data transmitted and the network latency. === Network Discovery -((("Bitcoin nodes", "network discovery", -id="BNodiscover08")))When a new node boots up, it must discover other +((("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 network and connect to it. The geographic location of other nodes is @@ -602,8 +599,7 @@ rather than fixed patterns. [[bloom_filters]] === Bloom Filters -((("privacy, maintaining", -id="privacy08")))((("security", "maintaining privacy", +((("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 filters offer an efficient way to express a search pattern while diff --git a/overview.adoc b/overview.adoc index 09c78f82..16082596 100644 --- a/overview.adoc +++ b/overview.adoc @@ -1,8 +1,7 @@ [[ch02_bitcoin_overview]] == How Bitcoin Works -((("decentralized systems", "bitcoin overview", -id="DCSover02")))The Bitcoin system, unlike traditional banking and +((("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 their own computer to verify the correct operation of every @@ -102,8 +101,7 @@ image::images/mbc2_0202.png["payment-request"] [TIP] ==== -((("warnings and cautions", "avoid sending money to -addresses appearing in book")))Try to scan this with your wallet to see +((("warnings and cautions", "avoid sending money toaddresses appearing in book")))Try to scan this with your wallet to see the address and amount but DO NOT SEND MONEY. ==== [[invoice-URI]] @@ -456,8 +454,7 @@ wallet can further verify Alice's transaction only spends valid UTXOs. === Bitcoin Mining -((("blockchain (the)", "overview of mining", -id="BToverview02")))Alice's transaction is now propagated on the Bitcoin +((("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 validated by full nodes. See diff --git a/security.adoc b/security.adoc index c718c827..400afdf2 100644 --- a/security.adoc +++ b/security.adoc @@ -190,8 +190,7 @@ we will examine various best practices for practical user security. ==== Physical Bitcoin Storage -((("paper -wallets", see="also wallets")))Because most users are far more +((("paperwallets", 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 form. Bitcoin keys, and the seeds used to create them, are nothing more than long numbers. This means that diff --git a/wallets.adoc b/wallets.adoc index fdcc574f..70638ee8 100644 --- a/wallets.adoc +++ b/wallets.adoc @@ -211,8 +211,7 @@ We'll provide a detailed exploration of HD wallets in <>. ==== Seeds and Recovery Codes -((("bitcoin improvement proposals", "Recovery Code Words -(BIP39)")))HD wallets are a very powerful mechanism for managing many +((("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 for your wallet using your original seed. But, if someone else gets @@ -623,8 +622,7 @@ modern standards that may provide additional features or safety. [[recovery_code_words]] ==== BIP39 Recovery Codes -((("bitcoin improvement proposals", "Recovery -Code Words (BIP39)", id="BIP3905")))BIP39 recovery codes are word +((("bitcoin improvement proposals", "RecoveryCode 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 re-create the seed and from there re-create all the @@ -901,8 +899,7 @@ her family to recover the cryptocurrency estate. [[hd_wallet_details]] ==== Creating an HD Wallet from the Seed -((("hierarchical deterministic (HD) -wallets")))HD wallets are created from a single _root seed_, which is a +((("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.