From d3c0914c8b9638729b42cc2a59bc349867532da4 Mon Sep 17 00:00:00 2001 From: theresa jones Date: Fri, 8 Sep 2023 19:19:59 -0700 Subject: [PATCH] removing line breaks from inside index tags --- applications.adoc | 36 +++------ authorization-authentication.adoc | 66 ++++++----------- bitcoin-core.adoc | 57 +++++---------- blockchain.adoc | 30 +++----- fees.adoc | 3 +- intro.adoc | 24 ++---- keys.adoc | 42 ++++------- mining.adoc | 117 ++++++++++-------------------- network.adoc | 42 ++++------- overview.adoc | 33 +++------ security.adoc | 24 ++---- signatures.adoc | 15 ++-- wallets.adoc | 21 ++---- 13 files changed, 170 insertions(+), 340 deletions(-) diff --git a/applications.adoc b/applications.adoc index 2056442c..d2131359 100644 --- a/applications.adoc +++ b/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. <> 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 diff --git a/authorization-authentication.adoc b/authorization-authentication.adoc index e526aa59..908a3a9e 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 -((("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] and pass:[#P2PubKHash2] 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 <> and <>.((("", -startref="relativetime07"))) +be seen in <> and <>.((("",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 <>, Mohammed's ((("use cases", -"import/export")))company is using Segregated Witness payments to +As we saw in <>, 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 diff --git a/bitcoin-core.adoc b/bitcoin-core.adoc index caaaf5b3..475e327e 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! -((("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 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 <>, ((("use cases", "buying coffee", -id="alicethree")))Alice made a purchase from Bob's store. Her +In <>, ((("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 <>. ==== 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 diff --git a/blockchain.adoc b/blockchain.adoc index a1d10708..9c372e29 100644 --- a/blockchain.adoc +++ b/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. <> 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]] @@ -118,8 +114,7 @@ process and will be discussed in more detail in <>. [[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 diff --git a/fees.adoc b/fees.adoc index 4b7ec048..938fed5d 100644 --- a/fees.adoc +++ b/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" diff --git a/intro.adoc b/intro.adoc index a6b39448..0c04d6ac 100644 --- a/intro.adoc +++ b/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 <>). 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 diff --git a/keys.adoc b/keys.adoc index 139d8b78..9bff8932 100644 --- a/keys.adoc +++ b/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" diff --git a/mining.adoc b/mining.adoc index 46f65b69..3248fc41 100644 --- a/mining.adoc +++ b/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 <>. -((("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 <>, 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 <>. @@ -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 <>). 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 <> we looked at how +((("forks","changing consensus rules", "hard forks")))In <> 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 diff --git a/network.adoc b/network.adoc index af1de8fe..83081907 100644 --- a/network.adoc +++ b/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. -<> ((("propagation", "address propagation and -discovery")))shows the address discovery protocol. +<> ((("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 diff --git a/overview.adoc b/overview.adoc index 54aff439..fdb32ee7 100644 --- a/overview.adoc +++ b/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 <>, we can +((("blockchain(the)", "genesis block")))In <>, 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 -<>.((("", -startref="MACover02"))) +<>.((("",startref="MACover02"))) [[block-alice1]] .Alice's transaction included in a block diff --git a/security.adoc b/security.adoc index 8db03a94..6b9b4ed2 100644 --- a/security.adoc +++ b/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 diff --git a/signatures.adoc b/signatures.adoc index fe959e84..2e8443c7 100644 --- a/signatures.adoc +++ b/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 diff --git a/wallets.adoc b/wallets.adoc index 7354c075..4514e3f9 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 -((("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