From 140ba650e8440722eaca6a2d0af818a8eb87c719 Mon Sep 17 00:00:00 2001 From: theresa jones Date: Fri, 8 Sep 2023 18:47:20 -0700 Subject: [PATCH] removing 2e index tags --- applications.adoc | 34 ++++----- authorization-authentication.adoc | 78 ++++++++++---------- bips.adoc | 4 +- bitcoin-core.adoc | 60 ++++++++-------- blockchain.adoc | 46 ++++++------ fees.adoc | 6 +- glossary.asciidoc | 2 +- intro.adoc | 56 +++++++-------- keys.adoc | 40 +++++------ mining.adoc | 114 +++++++++++++++--------------- network.adoc | 42 +++++------ overview.adoc | 48 ++++++------- preface.asciidoc | 22 +++--- security.adoc | 24 +++---- signatures.adoc | 26 +++---- wallets.adoc | 32 ++++----- whitepaper.adoc | 6 +- 17 files changed, 320 insertions(+), 320 deletions(-) diff --git a/applications.adoc b/applications.adoc index ea812921..2056442c 100644 --- a/applications.adoc +++ b/applications.adoc @@ -14,7 +14,7 @@ routed payment channels (Lightning Network). === Building Blocks (Primitives) ((("blockchain applications", "building blocks for -(primitives)")))((("primitives")))When operating correctly and over the +(primitives)")))When operating correctly and over the long term, the Bitcoin system offers certain guarantees, which can be used as building blocks to create applications. These include: @@ -107,13 +107,13 @@ new feature introduced into Bitcoin. === Applications from Building Blocks -((("blockchain applications", "examples of")))The building blocks +The building blocks offered by Bitcoin are elements of a trust platform that can be used to compose applications. Here are some examples of applications that exist today and the building blocks they use: Proof-of-Existence (Digital Notary):: ((("digital notary -services")))((("Proof of Existence")))Immutability + Timestamp + Durability. +services")))Immutability + Timestamp + Durability. A transaction on the blockchain can commit to a value, proving that a piece of data existed at the time it was recorded (Timestamp). The commitment cannot be modified ex-post-facto @@ -136,17 +136,17 @@ Double-Spend) the settlement on a shorter timelock (Timelock). === Colored Coins ((("blockchain applications", "colored coins", -id="BCAcoins12")))((("colored coins", id="color12")))The first +id="BCAcoins12")))The first blockchain application we will discuss is _colored coins_. -((("extrinsic asset management")))Colored coins refers to a set of +Colored coins refers to a set of similar technologies that use Bitcoin transactions to record the creation, ownership, and transfer of extrinsic assets other than bitcoin. By "extrinsic" we mean assets that are not stored directly on the bitcoin blockchain, as opposed to bitcoin itself, which is an asset intrinsic to the blockchain. -((("digital asset management")))Colored coins are used to track digital +Colored coins are used to track digital assets as well as physical assets held by third parties and traded through colored coins certificates of ownership. Digital asset colored coins can represent intangible assets such as a stock certificate, @@ -155,7 +155,7 @@ intellectual property (trademarks, copyrights, etc.). Tangible asset colored coins can represent certificates of ownership of commodities (gold, silver, oil), land title, automobiles, boats, aircraft, etc. -((("Enhanced Padded-Order-Based Coloring (EPOBC)")))The term derives +The term derives from the idea of "coloring" or marking a nominal amount of bitcoin, for example, a single satoshi, to represent something other than the bitcoin amount itself. As an analogy, consider stamping a $1 note with a message @@ -379,7 +379,7 @@ underlying data transport mechanism is not the channel. We use the term channel to represent the relationship and shared state between two parties, outside of the blockchain. -((("payment (state) channels", "concept of")))To further explain this +To further explain this concept, think of a TCP stream. From the perspective of higher-level protocols it is a "socket" connecting two applications across the internet. But if you look at the network traffic, a TCP stream is just a @@ -406,7 +406,7 @@ the state being altered is the balance of a virtual currency. ==== State Channels—Basic Concepts and Terminology -((("payment (state) channels", "terminology")))A state channel is +A state channel is established between two parties, through a transaction that locks a shared state on the blockchain. This is called the _funding transaction_. This single transaction must be transmitted to @@ -453,7 +453,7 @@ image::images/mbc2_1204.png["A payment channel between Bob and Alice, showing th ==== Simple Payment Channel Example -((("payment (state) channels", "example of", id="PSCexample12")))To +To explain state channels, we start with a very simple example. We demonstrate a one-way channel, meaning that value is flowing in one direction only. We will also start with the naive assumption that no one @@ -547,7 +547,7 @@ the commitment transactions that update the balance of the channel. In the end, only two transactions are recorded on the blockchain: the funding transaction that established the channel and a settlement transaction that allocated the final balance correctly between the two -participants.((("", startref="PSCexample12"))) +participants. [[video_payment_channel]] .Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel @@ -698,7 +698,7 @@ settlement transaction they can close the channel and redeem their balance immediately. Worst case, one of the parties can be petty, refuse to cooperate, and force the other party to do a unilateral close with the most recent commitment transaction. But if they do that, they have -to wait for their funds too.((("", startref="PSCtrust12"))) +to wait for their funds too. ==== Asymmetric Revocable Commitments @@ -922,7 +922,7 @@ channel. ==== Hash Time Lock Contracts (HTLC) -((("Hash Time Lock Contracts (HTLC)")))((("payment (state) channels", +((("payment (state) channels", "Hash Time Lock Contracts (HTLC)")))Payment channels can be further extended with a special type of smart contract that allows the participants to commit funds to a redeemable secret, with an expiration @@ -973,7 +973,7 @@ redeemed by _anyone_ who has the secret +R+. An HTLC can take many different forms with slight variations to the script. For example, adding a +CHECKSIG+ operator and a public key in the first clause restricts redemption of the hash to a particular recipient, who must also -know the secret +R+.((("", startref="BCApayment12"))) +know the secret +R+. [[lightning_network]] === Routed Payment Channels (Lightning Network) @@ -998,7 +998,7 @@ https://github.com/lightning/bolts/blob/master/00-introduction.md[_Basics of Lig ==== Basic Lightning Network Example -((("Lightning Network", "basic example")))Let's see how this works. +Let's see how this works. In this example, we have five participants: Alice, Bob, Carol, Diana, and Eric. These five participants have opened payment channels with each @@ -1114,7 +1114,7 @@ refund if the channel was closed or the routed payment failed. ==== Lightning Network Transport and Pathfinding -((("Lightning Network", "transport and pathfinding")))All communications +All communications between LN nodes are encrypted point-to-point. In addition, nodes have a long-term public key that they use as an identifier and to authenticate each other. @@ -1204,7 +1204,7 @@ hops to go. ==== Lightning Network Benefits -((("Lightning Network", "benefits of")))A Lightning Network is a +A Lightning Network is a second-layer routing technology. It can be applied to any blockchain that supports some basic capabilities, such as multisignature transactions, timelocks, and basic smart contracts. diff --git a/authorization-authentication.adoc b/authorization-authentication.adoc index 90daa7f9..e526aa59 100644 --- a/authorization-authentication.adoc +++ b/authorization-authentication.adoc @@ -37,7 +37,7 @@ Script is a very simple language. It requires minimal processing and cannot easily do many of the fancy things modern programming languages can do. -((("Pay-to-Public-Key-Hash (P2PKH)")))When legacy transactions were the +When legacy transactions were the most commonly used type of transaction, the majority of transactions processed through the Bitcoin network had the form "Payment to Bob's Bitcoin address" and used a script called a Pay-to-Public-Key-Hash script. @@ -53,7 +53,7 @@ conditions for spending and how those conditions can be satisfied. [TIP] ==== -((("programmable money")))Bitcoin transaction validation is not based on +Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. @@ -61,14 +61,14 @@ of conditions to be expressed. ==== Turing Incompleteness -((("Turing incompleteness")))The Bitcoin transaction script language +The Bitcoin transaction script language contains many operators, but is deliberately limited in one important way--there are no loops or complex flow control capabilities other than conditional flow control. This ensures that the language is not _Turing Complete_, meaning that scripts have limited complexity and predictable execution times. Script is not a general-purpose language. -((("denial-of-service attacks")))((("denial-of-service attacks", -see="also security")))((("security", "denial-of-service attacks")))These +((("denial-of-service attacks", +see="also security")))These limitations ensure that the language cannot be used to create an infinite loop or other form of "logic bomb" that could be embedded in a transaction in a way that causes a denial-of-service attack against the @@ -78,7 +78,7 @@ validation mechanism from being used as a vulnerability. ==== Stateless Verification -((("stateless verification")))The Bitcoin transaction script language is +The Bitcoin transaction script language is stateless, in that there is no state prior to execution of the script, or state saved after execution of the script. All the information needed to execute a script is contained within the script @@ -205,7 +205,7 @@ to know that the number 2 satisfies the script. [TIP] ==== -((("transactions", "valid and invalid")))Transactions are valid if the +Transactions are valid if the top result on the stack is +TRUE+, which is any non-zero value. Transactions are invalid if the top value on the stack is +FALSE+ (the @@ -261,7 +261,7 @@ failed to satisfy the spending conditions placed on the output. [[p2pkh]] ==== Pay-to-Public-Key-Hash (P2PKH) -((("Pay-to-Public-Key-Hash (P2PKH)"))) + A Pay-to-Public-Key-Hash or "P2PKH" script uses an output script that contains a hash which commits to a public key. P2PKH is best known as the basis for a legacy Bitcoin address. A P2PKH output can be spent by @@ -301,7 +301,7 @@ data-xrefstyle="select: labelnumber">#P2PubKHash1] 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="Tsript06")))((("", +transaction.((("", startref="Stransact06"))) [[P2PubKHash1]] @@ -316,7 +316,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"] === Scripted multisignatures ((("transactions", "advanced", "multisignature -scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting", +scripts")))((("scripting", "multisignature scripts", id="Smulti07")))((("multisignature scripts")))Multisignature scripts set a condition where _k_ public keys are recorded in the script and at least _t_ of those must provide @@ -389,7 +389,7 @@ script may include multiple of those opcodes. ==== An oddity in CHECKMULTISIG execution ((("scripting", "multisignature scripts", "OP_CHECKMULTISIG -oddity")))((("OP_CHECKMULTISIG oddity workaround")))There is an oddity in +oddity")))There is an oddity in ++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When +OP_CHECKMULTISIG+ executes, it should consume t+k+2 items on the stack as parameters. However, due to the oddity, +OP_CHECKMULTISIG+ will pop an extra @@ -476,13 +476,13 @@ startref="Smulti07"))) [[p2sh]] === Pay-to-Script-Hash (P2SH) -((("transactions", "advanced", "Pay-to-Script-Hash")))((("scripting", +((("scripting", "Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was introduced in 2012 as a powerful new type of operation that greatly simplifies the use of complex scripts. To explain the need for P2SH, let's look at a practical example. -((("use cases", "import/export", id="mohamseven")))((("scripting", +((("scripting", "Pay-to-Script-Hash", "import/export example")))((("Pay-to-Script-Hash (P2SH)", "import/export example"))) Mohammed is an electronics importer based in Dubai. Mohammed's @@ -525,7 +525,7 @@ matches the commitment in addition to the data which satisfies the script. In si P2SH means "pay to a script matching this hash, a script that will be presented later when this output is spent." -((("redeem scripts")))((("scripting", "redeem scripts")))In P2SH +In P2SH transactions, the script that is replaced by a hash is referred to as the _redeem script_ because it is presented to the system at redemption time rather than as an output script. <> shows @@ -618,7 +618,7 @@ If the redeem script hash matches, the redeem script is executed: ==== P2SH Addresses ((("scripting", "Pay-to-Script-Hash", -"addresses")))((("Pay-to-Script-Hash (P2SH)", "addresses")))((("bitcoin +"addresses")))((("bitcoin improvement proposals", "Address Format for P2SH (BIP13)")))Another important part of the P2SH feature is the ability to encode a script hash as an address, as defined in BIP13. P2SH addresses are Base58Check @@ -643,7 +643,7 @@ payment does not see the script. ==== Benefits of P2SH ((("scripting", "Pay-to-Script-Hash", "benefits -of")))((("Pay-to-Script-Hash (P2SH)", "benefits of")))The P2SH feature +of")))The P2SH feature offers the following benefits compared to the direct use of complex scripts in outputs: @@ -679,7 +679,7 @@ risk, because you can send bitcoin to a P2SH address that cannot be spent later. [WARNING] ==== -((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts +P2SH output scripts contain the hash of a redeem script, which gives no clues as to the content of the redeem script. The P2SH output will be considered valid and accepted even if the redeem script is invalid. You @@ -690,10 +690,10 @@ spent. [[op_return]] === Data Recording Output (OP_RETURN) -((("transactions", "advanced", "data recording output")))((("scripting", -"data recording output")))((("OP_RETURN operator")))((("data recording -(nonpayment data)")))((("nonpayment data")))((("blockchain (the)", -"nonpayment data recording")))((("digital notary services")))Bitcoin's +((("scripting", +"data recording output")))((("data recording +(nonpayment data)")))((("blockchain (the)", +"nonpayment data recording")))Bitcoin's distributed and timestamped blockchain has potential uses beyond payments. Many developers have tried to use the transaction scripting language to take advantage of the security and resilience of @@ -705,8 +705,8 @@ to a file in such a way that anyone could establish proof-of-existence of that file on a specific date by reference to that transaction. -((("blockchain bloat")))((("bloat")))((("unspent transaction outputs -(UTXO)")))((("UTXO sets")))The use of Bitcoin's blockchain to store data +((("unspent transaction outputs +(UTXO)")))The use of Bitcoin's blockchain to store data unrelated to Bitcoin payments is a controversial subject. Many people consider such use abusive and want to discourage it. Others view it as a demonstration of the powerful capabilities of blockchain @@ -739,7 +739,7 @@ expensive database operations. OP_RETURN ---- -((("Proof of Existence")))((("DOCPROOF prefix")))The data portion +The data portion often represents a hash, such as the output from the SHA256 algorithm (32 bytes). Some applications put a prefix in front of the data to help identify the application. For example, the @@ -769,7 +769,7 @@ being included in a block until a specific block height, but it does not prevent spending the funds in another transaction earlier than that. Let's explain that with the following example. -((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that: +Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that: * Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed. * Bob may transmit the transaction after 3 months. @@ -783,7 +783,7 @@ It is important to understand the limitations of transaction lock time. The only ==== Check Lock Time Verify (OP_CLTV) -((("Check Lock Time Verify (OP_CLTV)", id="cltv07")))((("timelocks", "Check +((("timelocks", "Check Lock Time Verify (OP_CLTV)")))((("scripting", "timelocks", "Check Lock Time Verify (OP_CLTV)")))((("bitcoin improvement proposals", "OP_CHECKLOCKTIMEVERIFY (BIP65)")))In December 2015, a new form of @@ -891,7 +891,7 @@ expired. By introducing timelock functionality directly into the scripting language, +OP_CLTV+ allows us to develop some very interesting complex -scripts.((("", startref="cltv07"))) +scripts. The standard is defined in https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65 @@ -902,7 +902,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65 Lock time and +OP_CLTV+ are ((("timelocks", "relative timelocks", id="Trelative07")))((("scripting", "timelocks", "relative -timelocks")))((("relative timelocks", id="relativetime07")))both +timelocks")))both _absolute timelocks_ in that they specify an absolute point in time. The next two timelock features we will examine are _relative timelocks_ in that they specify, as a condition of spending an output, an elapsed time @@ -938,7 +938,7 @@ the consensus rules. ==== Relative Timelocks with OP_CSV ((("scripting", "timelocks", "relative timelocks with -CHECKSEQUENCEVERIFY")))((("CHECKSEQUENCEVERIFY (CSV)")))Just like OP_CLTV +CHECKSEQUENCEVERIFY")))Just like OP_CLTV and lock time, there is a script opcode for relative timelocks that leverages the sequence value in scripts. That opcode is +OP_CHECKSEQUENCEVERIFY+, commonly referred to as +OP_CSV+ for short. @@ -970,7 +970,7 @@ is, they're kept off the blockchain (_offchain_). A child transaction cannot be parent transaction has been propagated, mined, and aged by the time specified in the relative timelock. One application of this use case can be seen in <> and <>.((("", -startref="relativetime07")))((("", startref="Trelative07"))) +startref="relativetime07"))) +OP_CSV+ is defined in detail in https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112, @@ -978,9 +978,9 @@ CHECKSEQUENCEVERIFY]. === Scripts with Flow Control (Conditional Clauses) -((("transactions", "advanced", "flow control scripts")))((("scripting", +((("scripting", "flow control scripts", id="Sflow07")))((("conditional clauses", -id="condition07")))((("flow control", id="flow07")))One of the more +id="condition07")))One of the more powerful features of Bitcoin Script is flow control, also known as conditional clauses. You are probably familiar with flow control in various programming languages that use the construct +IF...THEN...ELSE+. @@ -1041,13 +1041,13 @@ comes _before_ the +IF+ opcode. ==== Conditional Clauses with VERIFY Opcodes -((("VERIFY opcodes")))((("IF clauses")))((("opcodes", "VERIFY")))Another +Another form of conditional in Bitcoin Script is any opcode that ends in +VERIFY+. The +VERIFY+ suffix means that if the condition evaluated is not +TRUE+, execution of the script terminates immediately and the transaction is deemed invalid. -((("guard clauses")))Unlike an +IF+ clause, which offers alternative +Unlike an +IF+ clause, which offers alternative execution paths, the +VERIFY+ suffix acts as a _guard clause_, continuing only if a precondition is met. @@ -1104,7 +1104,7 @@ A very common use for flow control in Bitcoin Script is to construct a script that offers multiple execution paths, each a different way of redeeming the UTXO. -((("use cases", "buying coffee")))Let's look at a simple example, where +Let's look at a simple example, where we have two signers, Alice and Bob, and either one is able to redeem. With multisig, this would be expressed as a 1-of-2 multisig script. For the sake of demonstration, we will do the same thing with an +OP_IF+ @@ -1178,12 +1178,12 @@ Using this construct, we can build redeem scripts with tens or hundreds of execution paths, each offering a different way to redeem the UTXO. To spend, we construct an input script that navigates the execution path by putting the appropriate +TRUE+ and +FALSE+ values on the stack -at each flow control point.((("", startref="Sflow07")))((("", -startref="flow07")))((("", startref="condition07"))) +at each flow control point.((("", +startref="flow07"))) === Complex Script Example -((("transactions", "advanced", "example")))((("scripting", "complex +((("scripting", "complex script example", id="Scomplex07")))In this section we combine many of the concepts from this chapter into a single example. @@ -1378,7 +1378,7 @@ to the receiver in the manner that the receiver indicated. [[p2wsh]] ===== Pay-to-Witness-Script-Hash (P2WSH) -The ((("use cases", "import/export", id="mohamappd")))second type of +The second type of segwit v0 witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We saw this type of script in <>. In that example, P2SH was used by Mohammed's company to express a multisignature script. Payments to diff --git a/bips.adoc b/bips.adoc index 949e2044..1634ab09 100644 --- a/bips.adoc +++ b/bips.adoc @@ -2,7 +2,7 @@ [appendix] == Bitcoin Improvement Proposals -((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment. +Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment. As per BIP1 _BIP Purpose and Guidelines_, there are three kinds of BIPs: @@ -10,7 +10,7 @@ _Standard_ BIP:: Describes any change that affects most or all Bitcoin implement _Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice. _Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP. -((("bitcoin improvement proposals", "repository of")))BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips]. +BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips]. An MIT-licensed document from the open source Bitcoin Core project, reproduced here in edited form, describes which BIPs it implements, including listing the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or diff --git a/bitcoin-core.adoc b/bitcoin-core.adoc index 85399d4a..caaaf5b3 100644 --- a/bitcoin-core.adoc +++ b/bitcoin-core.adoc @@ -25,7 +25,7 @@ create and examine data related to the blockchain and network. === From Bitcoin to Bitcoin Core -((("open source licenses")))((("Nakamoto, Satoshi")))Bitcoin is an _open +Bitcoin is an _open source_ project and the source code is available under an open (MIT) license, free to download and use for any purpose. More than just being open source, Bitcoin is developed by @@ -35,7 +35,7 @@ contributors with about a dozen developers working on the code almost full-time and several dozen more on a part-time basis. Anyone can contribute to the code—including you! -((("bitcoin whitepaper")))((("Satoshi client")))((("reference +((("reference implementation", see="Bitcoin Core")))((("Bitcoin Core", "reference implementation")))When Bitcoin was created by Satoshi Nakamoto, the software was mostly completed before publication of the whitepaper reproduced in @@ -51,7 +51,7 @@ wallets, a transaction and block validation engine, tools for block construction of Bitcoin peer-to-peer communication. <> shows the architecture of Bitcoin -Core.((("Bitcoin Core", "architecture"))) +Core. [[bitcoin_core_architecture]] .Bitcoin Core architecture (Source: Eric Lombrozo) @@ -68,7 +68,7 @@ several major upgrades to Bitcoin. === Bitcoin Development Environment -((("development environment", "setup", see="Bitcoin Core")))If you're a +If you're a developer, you will want to set up a development environment with all the tools, libraries, and support software for writing Bitcoin applications. In this highly technical chapter, we'll walk through that @@ -81,7 +81,7 @@ next chapter, which is less technical. ((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", -"downloading")))((("code examples, obtaining and using")))Bitcoin Core's +"downloading")))Bitcoin Core's source code can be downloaded as an archive or by cloning the source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download @@ -93,7 +93,7 @@ https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. [TIP] ==== -((("$ symbol")))((("shell commands")))((("terminal applications")))In +In many of the examples in this chapter we will be using the operating system's command-line interface (also known as a "shell"), accessed via a "terminal" application. The shell will display a prompt; you type a @@ -107,7 +107,7 @@ system's responses to that command. When you see the next +$+ prefix, you'll know it's a new command and you should repeat the process. ==== -((("cloning source code")))((("source code, cloning", seealso="Bitcoin +((("source code, cloning", seealso="Bitcoin Core")))In this example, we are using the +git+ command to create a local copy ("clone") of the source code: @@ -124,7 +124,7 @@ Resolving deltas: 100% (175649/175649), done. [TIP] ==== -((("distributed version control systems")))Git is the most widely used +Git is the most widely used distributed version control system, an essential part of any software developer's toolkit. You may need to install the +git+ command, or a graphical user interface for git, on your operating system if you do not @@ -192,7 +192,7 @@ nothing to commit, working tree clean ==== Configuring the Bitcoin Core Build ((("Bitcoin Core", "compiling from source code", "build -configuration")))((("documentation")))((("build documentation", +configuration")))((("build documentation", seealso="Bitcoin Core")))The source code includes documentation, which can be found in a number of files. Review the main documentation located in _README.md_ in the _bitcoin_ directory. @@ -303,7 +303,7 @@ fixes the error. ==== Building the Bitcoin Core Executables ((("Bitcoin Core", "compiling from source code", "core -executables")))((("core executables", seealso="Bitcoin Core")))Next, you +executables")))Next, you will compile the source code, a process that can take up to an hour to complete, depending on the speed of your CPU and available memory. If an error @@ -343,7 +343,7 @@ libtool: install: /usr/bin/install -c bitcoin-tx /usr/local/bin/bitcoin-tx ... ---- -((("", startref="BCsource03")))The default installation of +bitcoind+ +The default installation of +bitcoind+ puts it in _/usr/local/bin_. You can confirm that Bitcoin Core is correctly installed by asking the system for the path of the executables, as follows: @@ -358,7 +358,7 @@ $ which bitcoin-cli === Running a Bitcoin Core Node -((("Bitcoin Core", "running core nodes", id="BCnode03")))((("Bitcoin +((("Bitcoin nodes", "running core nodes", id="BNcore03")))Bitcoin's peer-to-peer network is composed of network "nodes," run mostly by individuals and some of the businesses that provide Bitcoin services. Those running @@ -393,7 +393,7 @@ https://blockstream.com/satellite/[Blockstream Satellite]. [TIP] ==== ((("warnings and cautions", "core node resource -requirements")))((("resource requirements")))Bitcoin Core keeps a full +requirements")))Bitcoin Core keeps a full copy of the blockchain by default, with nearly every transaction that has ever been confirmed on the Bitcoin network since its inception in 2009. This dataset is hundreds of gigabytes in size and is downloaded incrementally @@ -437,9 +437,9 @@ node. ==== Configuring the Bitcoin Core Node -((("Bitcoin Core", "running core nodes", "configuring")))((("warnings +((("warnings and cautions", "password creation")))((("passwords", -"creating")))((("security", "passwords")))Bitcoin Core will look for a +"creating")))Bitcoin Core will look for a configuration file in its data directory on every start. In this section we will examine the various configuration options and set up a configuration file. To locate the configuration file, run +bitcoind @@ -488,7 +488,7 @@ Options: [many more options] ---- -((("configuration options", seealso="Bitcoin Core")))Here are some of +Here are some of the most important options that you can set in the configuration file, or as command-line parameters to +bitcoind+: @@ -532,7 +532,7 @@ Use it to reduce memory use on memory-constrained nodes. **** ((("Bitcoin Core", "running core nodes", "database options")))((("transactions", "database configuration -options")))((("txindex option")))((("full indexing option")))By default, +options")))By default, Bitcoin Core builds a database containing _only_ the transactions related to the user's wallet. If you want to be able to access _any_ transaction with commands like +getrawtransaction+ (see @@ -654,11 +654,11 @@ that it runs continuously and restarts when the operating system restarts. You will find a number of example startup scripts for various operating systems in Bitcoin Core's source directory under _contrib/init_ and a _README.md_ file showing which system uses which script.((("", -startref="BCnode03")))((("", startref="BNcore03"))) +startref="BCnode03"))) === Bitcoin Core Application Programming Interface (API) -((("Bitcoin Core", "Bitcoin Core API", id="BCapi03")))Bitcoin Core +Bitcoin Core implements a JSON-RPC interface that can also be accessed using the command-line helper +bitcoin-cli+. The command line allows us to experiment interactively with the capabilities that are also available @@ -723,7 +723,7 @@ and their expected output. ==== Getting Information on Bitcoin Core's Status -((("Bitcoin Core", "Bitcoin Core API", "status information")))Bitcoin +Bitcoin Core provides status reports on different modules through the JSON-RPC interface. The most important commands include +getblockchaininfo+, +getmempoolinfo+, +getnetworkinfo+ and +getwalletinfo+. @@ -811,7 +811,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000 [TIP] ==== -((("transaction IDs (txd)")))((("malleability")))A transaction ID (txid) +A transaction ID (txid) is not authoritative. Absence of a txid in the blockchain does not mean the transaction was not processed. This is known as "transaction malleability," because transactions can be modified prior to @@ -905,7 +905,7 @@ transmitted from one owner to the next. ==== Exploring Blocks -((("blocks", "block height")))((("blocks", "block hash")))Exploring +Exploring blocks is similar to exploring transactions. However, blocks can be referenced either by the block _height_ or by the block _hash_. First, let's find a block by its height. @@ -985,7 +985,7 @@ we'll examine those in detail in <>. ==== Using Bitcoin Core's Programmatic Interface ((("Bitcoin Core", "Bitcoin Core API", "using programmatic -interface")))((("programmatic interface", id="progint03")))The +interface")))The +bitcoin-cli+ helper is very useful for exploring the Bitcoin Core API and testing functions. But the whole point of an application programming interface is to access functions programmatically. In this section we @@ -1102,7 +1102,7 @@ and more clearly demonstrates the use of a programmatic interface. In <>, we first retrieve a block, then retrieve each of the transactions within it by reference to each transaction ID. Next, we iterate through each of the transaction's outputs and add up the -value.((("", startref="alicethree"))) +value. [[rpc_block]] .Retrieving a block and adding all the transaction outputs @@ -1126,16 +1126,16 @@ block is 10,322.07722534 BTC (including 25 BTC reward and 0.0909 BTC in fees). Compare that to the amount reported by a block explorer site by searching for the block hash or height. Some block explorers report the total value excluding the reward and excluding the fees. See if you can -spot the difference.((("", startref="BCapi03")))((("", +spot the difference.((("", startref="progint03"))) [[alt_libraries]] === Alternative Clients, Libraries, and Toolkits -((("Bitcoin Core", "alternatives to", id="BCalt03")))((("clients, +((("clients, libraries, and toolkits", id="clients03")))((("libraries, clients, and toolkits", id="librar03")))((("toolkits, libraries, and clients", -id="toolkit03")))((("third-party API clients", id="thirdpart03")))There +id="toolkit03")))There are many alternative clients, libraries, toolkits, and even full-node implementations in the bitcoin ecosystem. These are implemented in a variety of programming languages, offering programmers native interfaces @@ -1172,9 +1172,9 @@ https://bitcoin-s.org/[bitcoin-s]:: A Bitcoin implementation in Scala https://github.com/MetacoSA/NBitcoin[NBitcoin]:: Comprehensive bitcoin library for the .NET framework Many more libraries exist in a variety of other programming languages -and more are created all the time.((("", startref="BCalt03")))((("", -startref="clients03")))((("", startref="thirdpart03")))((("", -startref="toolkit03")))((("", startref="librar03"))) +and more are created all the time.((("", +startref="clients03")))((("", +startref="toolkit03"))) If you followed the instructions in this chapter, you now have Bitcoin Core running and have begun exploring the network and blockchain using diff --git a/blockchain.adoc b/blockchain.adoc index 11b8ae95..a1d10708 100644 --- a/blockchain.adoc +++ b/blockchain.adoc @@ -8,19 +8,19 @@ structure of the blockchain and see how it uses cryptographic commitments and other clever tricks to make every part of it easy for full nodes (and sometimes light clients) to validate. -((("blockchain (the)", "overview of")))The blockchain data structure is +The blockchain data structure is an ordered, back-linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. Blocks are linked "back," each referring to the previous block in the -chain. ((("blocks", "block height")))The blockchain is often visualized +chain. The blockchain is often visualized as a vertical stack, with blocks layered on top of each other and the first block serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms such as "height" to refer to the distance from the first block, and "top" or "tip" to refer to the most recently added block. -((("blocks", "block hash")))((("blocks", "genesis block")))((("blocks", -"parent blocks")))((("genesis block")))((("parent blocks")))Each block +((("blocks", +"parent blocks")))Each block within the blockchain is identified by a hash, generated using the SHA256 cryptographic hash algorithm on the header of the block. Each block also commits to the previous block, known as the _parent_ block, @@ -58,7 +58,7 @@ years. In the blockchain, the most recent few blocks might be revised if there is a chain reorganization due to a fork. The top six blocks are like a few inches of topsoil. But once you go more deeply into the blockchain, beyond six blocks, blocks are less and less likely to -change. ((("transactions", "coinbase transactions")))((("coinbase +change. ((("coinbase transactions")))After 100 blocks back there is so much stability that the coinbase transaction--the transaction containing the reward in bitcoin for creating a new block--can be spent. @@ -70,7 +70,7 @@ infinitesimal. === Structure of a Block -((("blocks", "structure of")))((("blockchain (the)", "block +((("blockchain (the)", "block structure")))A block is a container data structure that aggregates transactions for inclusion in the blockchain. The block is made of a header, containing metadata, followed by a long list @@ -95,8 +95,8 @@ header. <> describes how Bitcoin Core stores the structure of [[block_header]] === Block Header -((("blocks", "headers")))((("blockchain (the)", "block -headers")))((("headers")))The block header consists of +((("blockchain (the)", "block +headers")))The block header consists of block metadata as shown in <>. [[block_header_structure_ch09]] @@ -118,8 +118,8 @@ process and will be discussed in more detail in <>. [[block_hash]] === Block Identifiers: Block Header Hash and Block Height -((("blockchain (the)", "block identifiers")))((("blocks", "block -height")))((("blocks", "block hash")))The primary identifier of a block +((("blocks", "block +height")))The primary identifier of a block is its cryptographic hash, a commitment made by hashing the block header twice through the SHA256 algorithm. The resulting 32-byte hash is called the _block hash_ but is more accurately the _block header @@ -178,7 +178,7 @@ the blockchain. === The Genesis Block -((("blocks", "genesis block")))((("blockchain (the)", "genesis +((("blockchain (the)", "genesis block")))The first block in the blockchain is called the _genesis block_ and was created in 2009. It is the common ancestor of all the blocks in the blockchain, meaning that if you start at any block and follow the @@ -250,7 +250,7 @@ first block by Satoshi Nakamoto, Bitcoin's creator. === Linking Blocks in the Blockchain -((("blocks", "linking blocks in the blockchain")))((("blockchain (the)", +((("blockchain (the)", "linking blocks in the blockchain")))Bitcoin full nodes validate every block in the blockchain after the genesis block. Their local view of the blockchain is constantly updated as new blocks are found and used to @@ -307,11 +307,11 @@ image::images/mbc2_0901.png[] [[merkle_trees]] === Merkle Trees -((("merkle trees", id="merkle09")))((("blockchain (the)", "merkle +((("blockchain (the)", "merkle trees", id="BCTmerkle09")))Each block in the Bitcoin blockchain contains a summary of all the transactions in the block using a _merkle tree_. -((("binary hash trees", see="merkle trees")))A _merkle tree_, also known +A _merkle tree_, also known as a _binary hash tree_, is a data structure used for efficiently summarizing and verifying the integrity of large sets of data. Merkle trees are binary trees containing cryptographic hashes. The term "tree" @@ -369,7 +369,7 @@ of the nodes. .Calculating the nodes in a merkle tree image::images/mbc2_0902.png["merkle_tree"] -((("balanced trees")))Because the merkle tree is a binary tree, it needs +Because the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash will be duplicated to create an even number of leaf nodes, also known as a _balanced tree_. This is @@ -434,7 +434,7 @@ size, just 32 bytes. Whether there is one transaction or ten thousand transactions in the block, the merkle root always summarizes them into 32 bytes. -((("authentication paths")))To prove that a specific transaction is +To prove that a specific transaction is included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte hashes, constituting an _authentication path_ or _merkle path_ connecting the specific transaction to the root of the tree. This is @@ -497,18 +497,18 @@ transaction is recorded in the blockchain. All in all, the lightweight client wi have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 2 megabytes currently).((("", -startref="BCTmerkle09")))((("", startref="merkle09"))) +startref="BCTmerkle09"))) === Bitcoin's Test Blockchains ((("blockchain (the)", "test blockchains", -id="BCTtest09")))((("mainnet", seealso="blockchain (the)")))You might be +id="BCTtest09")))You might be surprised to learn that there is more than one blockchain used with Bitcoin. The "main" Bitcoin blockchain, the one created by Satoshi Nakamoto on January 3rd, 2009, the one with the genesis block we studied in this chapter, is called _mainnet_. There are other Bitcoin blockchains that are used for testing purposes: at this time _testnet_, _signet_, and -_regtest_. Let's look at each in turn.((("testnet", id="testnet09"))) +_regtest_. Let's look at each in turn. ==== Testnet: Bitcoin's Testing Playground @@ -588,7 +588,7 @@ experiment and learn in other programming languages and frameworks. Testnet3 supports all the features of mainnet, including Segregated Witness v0 and v1 (see <> and <>). Therefore, testnet3 can also be -used to test Segregated Witness features.((("", startref="testnet09"))) +used to test Segregated Witness features. ===== Problems With Testnet @@ -695,7 +695,7 @@ $ bitcoin-cli -signet getblockchaininfo ==== Regtest—The Local Blockchain -((("regtest (Regression Testing)")))Regtest, which stands for +Regtest, which stands for "Regression Testing," is a Bitcoin Core feature that allows you to create a local blockchain for testing purposes. Unlike signet and testnet3, which are a public and shared test blockchain, the regtest blockchains are @@ -767,7 +767,7 @@ $ bitcoin-cli -regtest getbalance === Using Test Blockchains for Development -((("development environment", "test blockchains and")))Bitcoin's various +Bitcoin's various blockchains (+regtest+, +signet+, +testnet3+, +mainnet+) offer a range of testing environments for bitcoin development. Use the test blockchains whether you are developing for Bitcoin Core, or another @@ -783,7 +783,7 @@ applications. Finally, once you are confident your code works as expected, switch to +mainnet+ to deploy it in production. As you make changes, improvements, bug fixes, etc., start the pipeline again, deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally -into production.((("", startref="BCTtest09"))) +into production. Now that we know what data the blockchain contains and how cryptographic commitments securely tie the various parts together, we will look at the diff --git a/fees.adoc b/fees.adoc index 218f26f6..4b7ec048 100644 --- a/fees.adoc +++ b/fees.adoc @@ -611,7 +611,7 @@ and make a miner very happy, this is probably not what you intended. [WARNING] ==== -((("warnings and cautions", "change outputs")))If you forget to add a +If you forget to add a change output in a manually constructed transaction, you will be paying the change as a transaction fee. "Keep the change!" might not be what you intended. @@ -622,8 +622,8 @@ you intended. ((("scripting", "timelocks", "defense against fee-sniping")))((("timelocks", "defense against -fee-sniping")))((("fees", "fee sniping")))((("security", "defense -against fee-sniping")))((("sniping")))Fee-sniping is a theoretical +fee-sniping")))((("security", "defense +against fee-sniping")))Fee-sniping is a theoretical attack scenario, where miners attempting to rewrite past blocks "snipe" higher-fee transactions from future blocks to maximize their profitability. diff --git a/glossary.asciidoc b/glossary.asciidoc index a9645a45..d56cdcee 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -192,7 +192,7 @@ RIPEMD-160:: RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more. satoshi:: - A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("satoshi"))) + A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. Satoshi Nakamoto:: Satoshi Nakamoto is the name used by the person or people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown. diff --git a/intro.adoc b/intro.adoc index fcaf571f..a6b39448 100644 --- a/intro.adoc +++ b/intro.adoc @@ -2,7 +2,7 @@ [[ch01_intro_what_is_bitcoin]] == Introduction -((("bitcoin", "defined", id="GSdefine01")))Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible. +Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible. [TIP] ==== @@ -71,18 +71,18 @@ Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer netw * A decentralized peer-to-peer network (the Bitcoin protocol) * A public transaction journal (the blockchain) -* ((("mining and consensus", "consensus rules", "satisfying")))A set of rules for independent transaction validation and currency issuance (consensus rules) +* A set of rules for independent transaction validation and currency issuance (consensus rules) * A mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm) As a developer, I see Bitcoin as akin to the internet of money, a network for propagating value and securing the ownership of digital assets via distributed computation. There's a lot more to Bitcoin than first meets the eye. -In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol.((("", startref="GSdefine01"))) +In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol. [role="pagebreak-before less_space"] .Digital Currencies Before Bitcoin **** -((("digital currencies", "prior to bitcoin")))The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are: +The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are: 1. Can I trust that the money is authentic and not counterfeit? 2. Can I trust that the digital money can only be spent once (known as the “double-spend” problem)? @@ -92,13 +92,13 @@ Issuers of paper money are constantly battling the counterfeiting problem by usi When cryptography started becoming more broadly available and understood in the late 1980s, many researchers began trying to use cryptography to build digital currencies. These early digital currency projects issued digital money, usually backed by a national currency or precious metal such as gold. -((("decentralized systems", "vs. centralized", secondary-sortas="centralized")))Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted. +Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted. **** === History of Bitcoin -((("Nakamoto, Satoshi")))((("distributed computing")))((("bitcoin", +((("bitcoin", "history of")))Bitcoin was first described in 2008 with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System,"footnote:["Bitcoin: A Peer-to-Peer Electronic Cash System," @@ -107,13 +107,13 @@ alias of Satoshi Nakamoto (see <>). Nakamoto combined several prior inventions such as digital signatures and Hashcash to create a completely decentralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation -of transactions. ((("Proof-of-Work algorithm")))((("decentralized +of transactions. ((("decentralized systems", "consensus in")))((("mining and consensus", "Proof-of-Work algorithm")))A key innovation was to use a distributed computation system (called a "Proof-of-Work" algorithm) to conduct a global lottery every 10 minutes on average, allowing the decentralized network to arrive at _consensus_ about the state of transactions. ((("double-spend -problem")))((("spending bitcoin", "double-spend problem")))This +problem")))This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions @@ -127,12 +127,12 @@ increased exponentially, and their combined computational power now exceeds the combined number of computing operations of the world's top supercomputers. -Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. ((("open source licenses")))However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics. +Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics. .A Solution to a Distributed Computing Problem **** -((("Byzantine Generals' Problem")))Satoshi Nakamoto's invention is +Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to get multiple participants without a leader @@ -162,7 +162,7 @@ derived from the original implementation written by Satoshi Nakamoto. ==== Choosing a Bitcoin Wallet -((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs. +Bitcoin wallets are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs. ===== Types of Bitcoin wallets Bitcoin wallets can be categorized as follows, according to the platform: @@ -204,7 +204,7 @@ hardware signing device. ===== Full-node vs. Lightweight Another way to categorize Bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network: -Full-node:: ((("full-node")))A full node is a program that validates the +Full-node:: A full node is a program that validates the entire history of Bitcoin transactions (every transaction by every user, ever). Optionally, full nodes can also store previously validated transactions and serve data to other Bitcoin programs, either on the @@ -213,14 +213,14 @@ computer resources--about the same as watching an hour-long streaming video for each day of Bitcoin transactions--but the full node offers complete autonomy to its users. -Lightweight client:: ((("lightweight clients"))) +Lightweight client:: A lightweight client, also known as a simplified-payment-verification (SPV) client, connects to a full node or other remote server for receiving and sending Bitcoin transaction information, but stores the user wallet locally, partially validates the transactions it receives, and independently creates outgoing transactions. -Third-party API client:: ((("third-party API clients")))A third-party +Third-party API client:: A third-party API client is one that interacts with Bitcoin through a third-party system of application programming interfaces (APIs), rather than by connecting to the Bitcoin network directly. The wallet may be stored by @@ -363,11 +363,11 @@ ensure you aren't being phished. ==== Bitcoin addresses -Alice is now ready to start using her new Bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service. +Alice is now ready to start using her new Bitcoin wallet. Her wallet application randomly generated a private key (described in more detail in <>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service. [TIP] ==== -((("addresses", "security of")))((("security", "bitcoin addresses")))There +There are a variety of Bitcoin addresses and invoice formats. Addresses and invoices can be shared with other Bitcoin users who can use them to send bitcoins directly to your wallet. You can share @@ -402,7 +402,7 @@ bitcoin-accepting charity. [[getting_first_bitcoin]] ==== Getting Your First Bitcoin -((("getting started", "acquiring bitcoin")))The first task for new users is to acquire some bitcoin. +The first task for new users is to acquire some bitcoin. Bitcoin transactions are irreversible. Most electronic payment networks such as credit cards, debit cards, PayPal, and bank account transfers are reversible. For someone selling bitcoin, this difference introduces a very high risk that the buyer will reverse the electronic payment after they have received bitcoin, in effect defrauding the seller. To mitigate this risk, companies accepting traditional electronic payments in return for bitcoin usually require buyers to undergo identity verification and credit-worthiness checks, which may take several days or weeks. As a new user, this means you cannot buy bitcoin instantly with a credit card. With a bit of patience and creative thinking, however, you won't need to. @@ -411,15 +411,15 @@ Here are some methods for acquiring bitcoin as a new user: * Find a friend who has bitcoins and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoins is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com]. * Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoins. -* ((("Coin ATM Radar")))((("ATMs, locating")))Use a Bitcoin ATM in your city. A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet. -* ((("exchange rates", "listing services")))Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency. +* Use a Bitcoin ATM in your city. A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet. +* Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency. [TIP] ==== -((("privacy, maintaining")))((("security", "maintaining -privacy")))((("digital currencies", "currency exchanges")))((("currency +((("security", "maintaining +privacy")))((("currency exchanges")))((("digital currencies", "benefits of -bitcoin")))((("bitcoin", "benefits of")))One of the advantages of +bitcoin")))One of the advantages of Bitcoin over other payment systems is that, when used correctly, it affords users much more privacy. Acquiring, holding, and spending bitcoin does not require you to divulge sensitive and personally @@ -440,14 +440,14 @@ Alice was introduced to Bitcoin by a friend so she has an easy way to acquire he [[bitcoin_price]] ==== Finding the Current Price of Bitcoin -((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price +Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price of bitcoins?" The short answer is that the price is set by markets. -((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD). +Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD). There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular: -https://bitcoinaverage.com/[Bitcoin Average]:: ((("BitcoinAverage")))A site that provides a simple view of the volume-weighted-average for each currency. +https://bitcoinaverage.com/[Bitcoin Average]:: A site that provides a simple view of the volume-weighted-average for each currency. https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoins. https://www.cmegroup.com/markets/cryptocurrencies/cme-cf-cryptocurrency-benchmarks.html?redirect=/trading/cryptocurrency-indices/cf-bitcoin-reference-rate.html[Chicago Mercantile Exchange Bitcoin Reference Rate]:: A reference rate that can be used for institutional and contractual reference, provided as part of investment data feeds by the CME. @@ -460,7 +460,7 @@ currencies. ((("getting started", "sending and receiving bitcoin", id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start -example")))((("spending bitcoin", see="also transactions")))Alice has +example")))Alice has decided to buy 0.001 bitcoins. After she and Joe check the exchange rate, she gives Joe an appropriate amount of cash, opens her mobile wallet application, and selects Receive. This @@ -511,7 +511,7 @@ transaction, Alice's wallet will indicate that it is receiving [[confirmations]] .Confirmations **** -((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <>. +At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <>. **** -Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01"))) +Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail. diff --git a/keys.adoc b/keys.adoc index 50c683a3..139d8b78 100644 --- a/keys.adoc +++ b/keys.adoc @@ -29,7 +29,7 @@ the addresses used by modern Bitcoin software. === Public Key Cryptography ((("keys and addresses", "overview of", "public key -cryptography")))((("digital currencies", "cryptocurrency")))Public key +cryptography")))Public key cryptography was invented in the 1970s and is a mathematical foundation for modern computer and information security. @@ -56,14 +56,14 @@ revealing the private key. [TIP] ==== -((("keys and addresses", "overview of", "key pairs")))In some wallet +In some wallet implementations, the private and public keys are stored together as a _key pair_ for convenience. However, the public key can be calculated from the private key, so storing only the private key is also possible. ==== ((("keys and addresses", "overview of", "private and public key -pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic +pairs")))((("cryptography", "elliptic curve cryptography")))A Bitcoin wallet contains a collection of key pairs, each consisting of a private key and a public key. The private key (k) is a number, usually derived from a number picked at random. @@ -73,8 +73,8 @@ generate a public key (K). .Why Use Asymmetric Cryptography (Public/Private Keys)? **** -((("cryptography", "asymmetric")))((("digital signatures", "asymmetric -cryptography and")))((("asymmetric cryptography")))Why is asymmetric +((("digital signatures", "asymmetric +cryptography and")))Why is asymmetric cryptography used in Bitcoin? It's not used to "encrypt" (make secret) the transactions. Rather, a useful property of asymmetric cryptography is the ability to generate _digital signatures_. A private key can be @@ -92,7 +92,7 @@ signatures. ==== Private Keys ((("keys and addresses", "overview of", "private key -generation")))((("warnings and cautions", "private key protection")))A +generation")))A private key is simply a number, picked at random. Control over the private key is the root of user control over all funds associated with the corresponding Bitcoin public key. The private key is @@ -136,7 +136,7 @@ Otherwise, we simply try again with another random number. [WARNING] ==== -((("random numbers", "random number generation")))((("entropy", "random +((("entropy", "random number generation")))Do not write your own code to create a random number or use a "simple" random number generator offered by your programming language. Use a cryptographically secure pseudorandom number @@ -288,13 +288,13 @@ Now that we have defined addition, we can define multiplication in the standard way that extends addition. For a point P on the elliptic curve, if k is a whole number, then kP = P + P + P + ... + P (k times). Note that k is sometimes confusingly called an "exponent" in this case.((("", -startref="eliptic04")))((("", startref="Celliptic04"))) +startref="eliptic04"))) [[public_key_derivation]] ==== Public Keys ((("keys and addresses", "overview of", "public key -calculation")))((("generator point")))The public key is calculated from +calculation")))The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a constant point called the _generator point_, and _K_ is the resulting @@ -317,7 +317,7 @@ signatures that prove control over bitcoin funds. ==== ((("keys and addresses", "overview of", "public key -generation")))((("generator point")))Starting with a private key in the +generation")))Starting with a private key in the form of a randomly generated number _k_, we multiply it by a predetermined point on the curve called the _generator point_ _G_ to produce another point somewhere else on the curve, which is the @@ -379,7 +379,7 @@ geometric operation on the curve. [TIP] ==== -((("OpenSSL cryptographic library")))Many Bitcoin implementations use +Many Bitcoin implementations use the https://github.com/bitcoin-core/secp256k1[libsecp256k1 crytographic library] to do the elliptic curve math. ==== @@ -727,7 +727,7 @@ image::images/mbc2_0405.png["pubkey_to_address"] //https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-November/000778.html -((("public and private keys", "compressed public keys"))) + When Bitcoin was first authored, its developers only knew how to create 65-byte public keys. However, a later developer became aware of an alternative encoding for public keys that used only 33 bytes and which @@ -1375,7 +1375,7 @@ support for new Bitcoin features as soon as they become available. [[priv_formats]] ==== Private key formats -((("public and private keys", "private key formats")))The private key +The private key can be represented in a number of different formats, all of which correspond to the same 256-bit number. <> shows several common formats used to represent private keys. Different formats are used in @@ -1438,7 +1438,7 @@ can easily be converted to any other format. [[comp_priv]] ===== Compressed private keys -((("public and private keys", "compressed private keys"))) + the commonly used term "compressed private key" is a misnomer, because when a private key is exported as WIF-compressed it is actually one byte _longer_ than an "uncompressed" private key. That is because the private key has an @@ -1500,14 +1500,14 @@ from older wallets. === Advanced Keys and Addresses -((("keys and addresses", "advanced forms", id="KAadvanced04")))In the +In the following sections we will look at advanced forms of keys and addresses, such as vanity addresses and paper wallets. ==== Vanity Addresses ((("keys and addresses", "advanced forms", "vanity -addresses")))((("vanity addresses", id="vanity04")))((("addresses", +addresses")))((("addresses", "vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin addresses that contain human-readable messages. For example, +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains @@ -1603,7 +1603,7 @@ repeat until successful. ===== Vanity address security and privacy -((("security", "vanity addresses")))Vanity addresses were popular in the +Vanity addresses were popular in the early years of Bitcoin but have almost entirely disappeared from use as of 2023. There are two likely causes for this trend: @@ -1634,7 +1634,7 @@ the future unless the above problems are solved. [[paper_wallets]] ==== Paper Wallets -((("keys and addresses", "advanced forms", "paper wallets")))((("paper +((("paper wallets", id="paperw04")))((("wallets", "types of", "paper wallets", id="Wpaper04")))Paper wallets are private keys printed on paper. Often the paper wallet also includes the corresponding Bitcoin address @@ -1679,8 +1679,8 @@ opaque scratch-off stickers, or folded and sealed with tamper-proof adhesive foil. Other designs feature additional copies of the key and address, in the form of detachable stubs similar to ticket stubs, allowing you to store multiple copies to protect against fire, flood, or -other natural disasters.((("", startref="KAadvanced04")))((("", -startref="Wpaper04")))((("", startref="paperw04"))) +other natural disasters.((("", +startref="Wpaper04"))) [[paper_wallet_spw]] .An example of a paper wallet with additional copies of the keys on a backup "stub" diff --git a/mining.adoc b/mining.adoc index b1b5ec3b..46f65b69 100644 --- a/mining.adoc +++ b/mining.adoc @@ -1,7 +1,7 @@ [[mining]] == Mining and Consensus -((("mining and consensus", "purpose of")))The word "mining" is somewhat +The word "mining" is somewhat misleading. By evoking the extraction of precious metals, it focuses our attention on the reward for mining, the new bitcoins created in each block. Although mining is incentivized by this reward, the primary @@ -13,17 +13,17 @@ transactions are validated and cleared. Mining is one of the inventions that makes Bitcoin special, a decentralized consensus mechanism that is the basis for P2P digital cash. -((("mining and consensus", "decentralized consensus")))((("central +((("central trusted authority")))Mining _secures the Bitcoin system_ and enables the emergence of network-wide _consensus without a central authority_. -((("fees", "transaction fees")))The reward of newly minted bitcoins and +The reward of newly minted bitcoins and transaction fees is an incentive scheme that aligns the actions of miners with the security of the network, while simultaneously implementing the monetary supply. [TIP] ==== -((("decentralized systems", "bitcoin mining and"))) + Mining is one of the mechanisms by which Bitcoin's _consensus security_ is _decentralized_. ==== @@ -52,8 +52,8 @@ In some protocols built on top of Bitcoin, the topological order of Bitcoin transactions is also used to establish a sequence of events; we'll discuss that idea further in <>. -((("fees", "mining rewards")))((("mining and consensus", "mining rewards -and fees")))((("Proof-of-Work algorithm")))((("mining and consensus", +((("mining and consensus", "mining rewards +and fees")))((("mining and consensus", "Proof-of-Work algorithm")))Miners receive two types of rewards in return for the security provided by mining: new bitcoins created with each new block (called the _subsidy_), and transaction fees from all the transactions included in @@ -103,7 +103,7 @@ consensus. === Bitcoin Economics and Currency Creation ((("mining and consensus", "bitcoin economics and currency -creation")))((("currency creation")))((("money supply")))((("issuance +creation")))((("issuance rate")))Bitcoin are minted during the creation of each block at a fixed and diminishing rate. Each block, generated on average every 10 minutes, contains entirely new bitcoins, created from nothing. Every @@ -168,7 +168,7 @@ to inflate the supply of bitcoin. .Deflationary Money **** -((("deflationary money")))The most important and debated consequence of +The most important and debated consequence of fixed and diminishing monetary issuance is that the currency tends to be inherently _deflationary_. Deflation is the phenomenon of appreciation of value due to a mismatch in supply and demand that drives up the value @@ -206,7 +206,7 @@ outweighs the risks of deflation. === Decentralized Consensus -((("mining and consensus", "decentralized consensus")))((("decentralized +((("decentralized systems", "consensus in")))In the previous chapter we looked at the blockchain, the global list of all transactions, which everyone in the Bitcoin network accepts as the authoritative record of @@ -226,7 +226,7 @@ and assemble a copy of the same blockchain as everyone else. This chapter examines the process by which the Bitcoin network achieves global consensus without central authority. -((("emergent consensus")))((("mining and consensus", "emergent +((("mining and consensus", "emergent consensus")))One of Satoshi Nakamoto's inventions is the decentralized mechanism for _emergent consensus_. Emergent, because consensus is not achieved explicitly—there is no election or fixed moment when consensus @@ -261,7 +261,7 @@ trusted, public, global blockchain. === Independent Verification of Transactions ((("mining and consensus", "independent transaction -verification")))((("transactions", "independent verification of")))In +verification")))In <>, we saw how wallet software creates transactions by collecting UTXOs, providing the appropriate authentication data, and then constructing new outputs assigned to a new owner. The resulting @@ -316,7 +316,7 @@ _mempool_. === Mining Nodes -((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining +((("Bitcoin nodes", "mining nodes")))Some of the nodes on the Bitcoin network are specialized nodes called _miners_. Jing is a Bitcoin miner; he @@ -334,7 +334,7 @@ containing Alice's transaction was mined by Jing's mining system and follow Alice's transaction as it becomes part of this new block. Jing's mining node maintains a local copy of the blockchain. By the time -((("use cases", "buying coffee")))Alice buys something, Jing's +Alice buys something, Jing's node is caught up with the chain of blocks with the most proof-of-work. Jing's node is listening for transactions, trying to mine a new block and also listening for @@ -352,7 +352,7 @@ transactions in the memory pool and remove any that were included in that block. Whatever transactions remain in the memory pool are unconfirmed and are waiting to be recorded in a new block. -((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work +((("mining and consensus", "Proof-of-Work algorithm")))Jing's node immediately constructs a new partial block, a candidate for the next block. This block is called a _candidate block_ because it is not yet a valid block, as it does not contain a valid @@ -365,7 +365,7 @@ transaction fees he'll attempt to claim. ==== The Coinbase Transaction -((("coinbase transactions", id="coinbtrans10")))((("transactions", +((("transactions", "coinbase transactions", id="Tcoinb10")))The first transaction in any block is a special transaction, called a _coinbase transaction_. This transaction is constructed by Jing's node and pays out his _reward_ for @@ -389,8 +389,8 @@ reward. ==== Coinbase Reward and Fees -((("coinbase transactions", "rewards and fees")))((("fees", "transaction -fees")))((("mining and consensus", "rewards and fees")))To construct the +((("fees", "transaction +fees")))To construct the coinbase transaction, Jing's node first calculates the total amount of transaction fees: @@ -430,7 +430,7 @@ The initial subsidy is calculated in satoshis by multiplying 50 with the +COIN+ constant (100,000,000 satoshis). This sets the initial reward (+nSubsidy+) at 5 billion satoshis. -((("halvings")))Next, the function calculates the number of +halvings+ +Next, the function calculates the number of +halvings+ that have occurred by dividing the current block height by the halving interval (+SubsidyHalvingInterval+). @@ -458,7 +458,7 @@ only gets to spend the reward if the block is accepted by everyone. ==== Structure of the Coinbase Transaction -((("coinbase transactions", "structure of")))With these calculations, +With these calculations, Jing's node then constructs the coinbase transaction to pay himself the block reward. @@ -504,14 +504,14 @@ the miners, as we will see next. [[duplicate_transactions]] ==== Coinbase Data -((("coinbase transactions", "coinbase data")))Coinbase transactions do +Coinbase transactions do not have an input script field. Instead, this field is replaced by coinbase data, which must be between 2 and 100 bytes. Except for the first few bytes, the rest of the coinbase data can be used by miners in any way they want; it is arbitrary data. -((("nonce values")))((("blocks", "genesis block")))((("blockchain -(the)", "genesis block")))((("genesis block")))In the genesis block, for +((("blockchain +(the)", "genesis block")))In the genesis block, for example, Satoshi Nakamoto added the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the coinbase data, using it as a proof of the earliest date this block chould have been @@ -526,8 +526,8 @@ version field set to 2 or higher) must contain the block height as a script === Constructing the Block Header -((("mining and consensus", "constructing block headers")))((("blocks", -"headers")))((("headers")))((("blockchain (the)", "block headers")))To +((("blocks", +"headers")))To construct the block header, the mining node needs to fill in six fields, as listed in <>. @@ -564,7 +564,7 @@ Today, VersionBits field has no meaning unless there's an attempt to upgrade the consensus protocol underway, in which case you will need to read its documentation to determine how it is using VersionBits. -((("blocks", "parent blocks")))((("parent blocks")))Next, the mining +Next, the mining node needs to add the "Previous Block Hash" (also known as +prevhash+). That is the hash of the block header of the previous block received from the network, which Jing's node has accepted and @@ -577,7 +577,7 @@ Block Hash field in the candidate block header, Jing is committing his mining power to extending the chain that ends in that specific block. ==== -((("merkle trees")))((("blockchain (the)", "merkle trees")))The next +The next step is to commit to all the transactions using merkle trees. Each transaction is listed using its witness transaction identifier (_wtxid_) in topographical order, with 32 0x00 bytes standing in for the wtxid of @@ -622,15 +622,15 @@ the header before a version is found that satisfies the requirement. === Mining the Block -((("mining and consensus", "mining the block", id="MACmining10")))Now +Now that a candidate block has been constructed by Jing's node, it is time for Jing's hardware mining rig to "mine" the block, to find a solution to the Proof-of-Work algorithm that makes the block valid. Throughout this book we have studied cryptographic hash functions as used in various aspects of the Bitcoin system. The hash function SHA256 is the -function used in Bitcoin's mining process.((("", startref="jingten"))) +function used in Bitcoin's mining process. -((("mining and consensus", "defined")))In the simplest terms, mining is +In the simplest terms, mining is the process of hashing the candidate block header repeatedly, changing one parameter, until the resulting hash matches a specific target. The hash function's result cannot be determined in advance, nor can a pattern be @@ -641,14 +641,14 @@ until the desired hash result appears by chance. ==== Proof-of-Work Algorithm -((("Proof-of-Work algorithm", id="proof10")))((("mining and consensus", +((("mining and consensus", "Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an arbitrary-length data input and produces a fixed-length deterministic result, called a _digest_. The digest is a digital commitment to the input. For any specific input, the resulting digest will always be the same and can be easily calculated and verified by anyone implementing the same hash algorithm. -((("collisions")))A key characteristic of a cryptographic hash +A key characteristic of a cryptographic hash algorithm is that it is computationally infeasible to find two different inputs that produce the same digest (known as a _collision_). As a corollary, it is also virtually impossible to select an input in such a @@ -753,7 +753,7 @@ the target. A lower target means it is more difficult to find a hash below the target. The target and difficulty are inversely related. ==== -((("targets")))Bitcoin's Proof-of-Work is very similar to the challenge +Bitcoin's Proof-of-Work is very similar to the challenge shown in <>. The miner constructs a candidate block filled with transactions. Next, the miner calculates the hash of this block's header and sees if it is smaller than the current @@ -769,7 +769,7 @@ enough block header hash. //TODO:use visual representation like I did on bitcoin.org ((("mining and consensus", "mining the block", "target -representation")))((("targets", id="targets10"))) +representation"))) Block headers contain the target in a notation called "target bits" or just "bits," which in block 277,316 has the value of +0x1903a30c+. This notation expresses the Proof-of-Work target as a @@ -929,7 +929,7 @@ electricity into hashing computation at the highest rate possible. The primary influence on the mining market is the price of one kilowatt-hour of electricity in bitcoin, because that determines the profitability of mining and therefore the incentives to enter or exit the mining -market.((("", startref="targets10"))) +market. [[mtp]] === Median Time Past (MTP) @@ -988,7 +988,7 @@ sequence, +CLTV+, and +CSV+. === Successfully Mining the Block ((("mining and consensus", "mining the block", "successful -completion")))((("use cases", "mining for bitcoin", id="jingtentwo")))As +completion")))As we saw earlier, Jing's node has constructed a candidate block and prepared it for mining. Jing has several hardware mining rigs with application-specific integrated circuits, where hundreds of thousands of @@ -1021,12 +1021,12 @@ chain it extends. In the next section, we'll look at the process each node uses to validate a block and select the most-work chain, creating the consensus that forms the decentralized blockchain.((("", -startref="MACmining10")))((("", startref="jingtentwo"))) +startref="MACmining10"))) === Validating a New Block -((("mining and consensus", "new block validation")))((("blocks", "new -block validation")))((("validation")))The third step in Bitcoin's +((("blocks", "new +block validation")))The third step in Bitcoin's consensus mechanism is independent validation of each new block by every node on the network. As the newly solved block moves across the network, each node performs a series of tests to validate it. @@ -1154,8 +1154,8 @@ forks (in addition to other problems), so many people prefer Bitcoin's ==== ((("", -startref="Bassemble10")))((("", startref="MACassembling10")))((("", -startref="forks10")))((("", startref="BCTfork10"))) +startref="Bassemble10")))((("", +startref="forks10"))) === Mining and the Hash Lottery @@ -1181,7 +1181,7 @@ a rapid pace. [[extra_nonce]] ==== The Extra Nonce Solution -((("nonce values")))Since 2012, mining has evolved to resolve a +Since 2012, mining has evolved to resolve a fundamental limitation in the structure of the block header. In the early days of Bitcoin, a miner could find a block by iterating through the nonce until the resulting hash was below the target. As difficulty @@ -1222,7 +1222,7 @@ entire left flank of the merkle tree up to the root. [[mining_pools]] ==== Mining Pools -((("mining pools", id="MACoverpool10")))((("mining pools", "benefits +((("mining pools", "benefits of")))In this highly competitive environment, individual miners working alone (also known as solo miners) don't stand a chance. The likelihood of them finding a block to offset their electricity and hardware costs @@ -1263,7 +1263,7 @@ the miners' Bitcoin addresses, once their share of the rewards has reached a certain threshold. Typically, the pool server charges a percentage fee of the rewards for providing the pool-mining service. -((("mining pools", "operation of")))Miners participating in a pool split +Miners participating in a pool split the work of searching for a solution to a candidate block, earning "shares" for their mining contribution. The mining pool sets a higher target (lower difficulty) for earning a share, typically more than 1,000 @@ -1322,7 +1322,7 @@ whole pool wins. ===== Managed pools -((("mining pools", "managed pools")))((("pool operators", +((("pool operators", seealso="mining pools")))Most mining pools are "managed," meaning that there is a company or individual running a pool server. The owner of the pool server is called the _pool operator_, and he charges pool miners a @@ -1356,7 +1356,7 @@ using their own full node. ===== Peer-to-peer mining pool (P2Pool) -((("mining pools", "peer-to-peer pools (P2Pool)")))((("peer-to-peer +((("peer-to-peer pools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by the pool operator, who might direct the pool effort to double-spend transactions or invalidate blocks (see <>). @@ -1403,7 +1403,7 @@ robust overall, as part of a diversified mining ecosystem. As of this writing, P2Pool has fallen into disuse, but new protocols such as Stratum v2 can allow individual miners to choose the transactions they include in their blocks.((("", -startref="MAChash10")))((("", startref="MACoverpool10"))) +startref="MAChash10"))) [[consensus_attacks]] === Hashrate Attacks @@ -1486,7 +1486,7 @@ original payment to Carol. Carol is now missing the three paintings and also has no payment. Throughout all this activity, Paul's mining pool participants might remain blissfully unaware of the double-spend attempt, because they mine with automated miners and cannot monitor -every transaction or block.((("", startref="carolten"))) +every transaction or block. ((("confirmations", "of large-value transactions", secondary-sortas="large-value transactions")))To protect against this @@ -1575,7 +1575,7 @@ between all participants. [[hard_forks]] ==== Hard Forks -((("forks", "changing consensus rules", id="forks10a")))((("forks", +((("forks", "changing consensus rules", "hard forks")))In <> we looked at how the Bitcoin network may briefly diverge, with two parts of the network following two different branches of the blockchain for a short time. We @@ -1644,7 +1644,7 @@ valid block. ==== Hard Forks: Software, Network, Mining, and Chain -((("forks", "changing consensus rules", "software forks")))For software +For software developers, the term "fork" has another meaning, adding confusion to the term "hard fork." In open source software, a fork occurs when a group of developers choose to follow a different software roadmap and start a @@ -1740,7 +1740,7 @@ transactions. ==== Contentious Hard Forks ((("forks", "changing consensus rules", "contentious hard -forks")))((("hard forks")))This is the dawn of the development of software +forks")))This is the dawn of the development of software for decentralized consensus. Just as other innovations in development changed both the methods and products of software and created new methodologies, new tools, and new communities in its wake, consensus software development also @@ -1765,7 +1765,7 @@ consensus modifications. ==== Soft Forks -((("forks", "changing consensus rules", "soft forks")))((("soft forks", +((("soft forks", "defined")))Not all consensus rule changes cause a hard fork. Only consensus changes that are forward-incompatible cause a fork. If the change is implemented in such a way that an unmodified client still sees @@ -1792,7 +1792,7 @@ nonupgraded nodes out of consensus. ===== Soft forks redefining NOP opcodes -((("opcodes", "redefinition by soft forks")))((("soft forks", +((("soft forks", "redefinition of NOP codes")))Two soft forks have been implemented in Bitcoin, based on the re-interpretation of NOP opcodes. Bitcoin Script had ten opcodes reserved for future use, NOP1 through @@ -1811,7 +1811,7 @@ the old clients, the script contains an NOP code, which is ignored. ==== Criticisms of Soft Forks -((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft +((("soft forks", "drawbacks of")))Soft forks based on the NOP opcodes are relatively uncontroversial. The NOP opcodes were placed in Bitcoin Script with the explicit goal of allowing non-disruptive upgrades. @@ -1840,13 +1840,13 @@ a loss of funds under the old rules. For example, if a CLTV transaction is evaluated under the old rules, there is no timelock constraint and it can be spent at any time. Therefore, critics contend that a failed soft fork that had to be reversed because of a bug would almost certainly -lead to loss of funds.((("", startref="Crule10"))) +lead to loss of funds. [[softforksignaling]] === Soft Fork Signaling with Block Version ((("forks", "changing consensus rules", "soft fork -activation")))((("soft forks", "activation")))Since soft forks allow +activation")))Since soft forks allow unmodified clients to continue to operate within consensus, one mechanism for "activating" a soft fork is through miners signaling that they are ready and willing to enforce the new consensus rules. If @@ -2006,7 +2006,7 @@ image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram] BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ and associated BIPs (68, 112, 113). The proposal named "csv" was -activated successfully in July of 2016.((("", startref="forks10a"))) +activated successfully in July of 2016. The standard is defined in https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9 @@ -2117,7 +2117,7 @@ state of this system with only a few changes possible if there is strong consensus by a very large majority. The 95% threshold for soft forks is reflective of this reality. -((("hard forks")))It is important to recognize that there is no perfect +It is important to recognize that there is no perfect solution for consensus development. Both hard forks and soft forks involve tradeoffs. For some types of changes, soft forks may be a better choice; for others, hard forks may be a better choice. There is no diff --git a/network.adoc b/network.adoc index 215cfad8..af1de8fe 100644 --- a/network.adoc +++ b/network.adoc @@ -1,7 +1,7 @@ [[bitcoin_network_ch08]] == The Bitcoin Network -((("Bitcoin network", "peer-to-peer architecture")))((("peer-to-peer +((("peer-to-peer (P2P)")))Bitcoin is structured as a peer-to-peer network architecture on top of the internet. The term peer-to-peer, or P2P, means that the full nodes which participate in the network are peers to each other, that @@ -26,7 +26,7 @@ characteristic. Decentralization of control is a core design principle that can only be achieved and maintained by a flat and decentralized P2P consensus network. -((("Bitcoin network", "defined")))The term "Bitcoin network" refers to +The term "Bitcoin network" refers to the collection of nodes running the Bitcoin P2P protocol. In addition to the Bitcoin P2P protocol, there are other protocols that are used for mining and lightweight wallets. These additional @@ -55,8 +55,8 @@ only a subset of the blockchain and partly verify transactions using a method called _simplified payment verification_, or SPV. ((("lightweight clients")))These clients are known as lightweight clients. -((("Bitcoin nodes", "mining nodes")))((("mining and consensus", "mining -nodes")))((("Proof-of-Work algorithm")))((("mining and consensus", +((("mining and consensus", "mining +nodes")))((("mining and consensus", "Proof-of-Work algorithm")))Miners compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm. Some miners operate full nodes, validating every block on the @@ -74,7 +74,7 @@ mining pool protocols and lightweight client-access protocols. === The Network -((("", startref="BNnode08")))((("", startref="BNtype08")))((("Bitcoin +((("Bitcoin network", "extended network activities")))As of this writing, the main Bitcoin network, running the Bitcoin P2P protocol, consists of about 10,000 listening nodes running various versions of Bitcoin Core and a few @@ -249,7 +249,7 @@ several Virtual Private Servers (VPSes) hosted on infrastructure around the world and served to connect the majority of miners and mining pools. -((("Fast Internet Bitcoin Relay Engine (FIBRE)")))((("Compact Block +((("Compact Block optimization")))The original Bitcoin Relay Network was replaced in 2016 with the introduction of the _Fast Internet Bitcoin Relay Engine_ or https://bitcoinfibre.org[_FIBRE_], also created by developer Matt @@ -419,14 +419,14 @@ connection for too long, it is assumed to be disconnected and a new peer will be sought. Thus, the network dynamically adjusts to transient nodes and network problems, and can organically grow and shrink as needed without any central control.((("", -startref="BNextend08")))((("", startref="BNodiscover08"))) +startref="BNextend08"))) === Full Nodes Full nodes are nodes that verify every transaction in every block on the valid blockchain with the most proof of work. -((("blocks", "genesis block")))((("genesis block")))((("blockchain +((("blockchain (the)", "genesis block")))Full nodes independently process every block, starting after the very first block (genesis block) and building up to the latest known block in the @@ -437,11 +437,11 @@ receive updates about new blocks of transactions, which it then verifies and incorporates into its local view of which scripts control which bitcoins, called the set of _unspent transaction outputs_ (UTXOs). -((("Bitcoin nodes", "full nodes")))Running a full node gives +Running a full node gives you the pure Bitcoin experience: independent verification of all transactions without the need to rely on, or trust, any other systems. -((("Satoshi client")))There are a few alternative implementations of +There are a few alternative implementations of full nodes, built using different programming languages and software architectures, or which made different design decisions. However, the most common @@ -453,7 +453,7 @@ command +getpeerinfo+ as we saw earlier; for example, +/Satoshi:24.0.1/+. === Exchanging "Inventory" -((("Bitcoin network", "syncing the blockchain")))The first thing a full +The first thing a full node will do once it connects to peers is try to construct a complete chain of block headers. If it is a brand-new node and has no blockchain at all, it only knows one block, the genesis block, which is statically embedded in @@ -461,7 +461,7 @@ the client software. Starting after block #0 (the genesis block), the new node will have to download hundreds of thousands of blocks to synchronize with the network and reestablish the full blockchain. -((("blockchain (the)", "syncing the blockchain")))((("syncing")))The +The process of syncing the blockchain starts with the +version+ message, because that contains +BestHeight+, a node's current blockchain height (number of blocks). A node will see the +version+ messages from its @@ -607,13 +607,13 @@ incoming and outgoing transactions. Bloom filters allow lightweight clients to receive a subset of the transactions without directly revealing precisely which addresses they are interested in, through a filtering mechanism that uses probabilities -rather than fixed patterns.((("", startref="BNspvnodes08")))((("", +rather than fixed patterns.((("", startref="simple08"))) [[bloom_filters]] === Bloom Filters -((("bitcoin network", "bloom filters", id="BNebloom08")))((("bloom +((("bloom filters", id="bloom08")))((("privacy, maintaining", id="privacy08")))((("security", "maintaining privacy", id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way @@ -742,7 +742,7 @@ them) that a lightweight client receives from its peers, selecting only transactions of interest to the lightweight client without revealing exactly which addresses or keys it is interested in. -((("transaction IDs (txid)")))A lightweight client will initialize a bloom filter +A lightweight client will initialize a bloom filter as "empty"; in that state the bloom filter will not match any patterns. The lightweight client will then make a list of all the addresses, keys, and hashes that it is interested in. It will do this by extracting the @@ -751,7 +751,7 @@ controlled by its wallet. The lightweight client then adds each of these to the bloom filter, so that the bloom filter will "match" if these patterns are present in a transaction, without revealing the patterns themselves. -((("Bitcoin nodes", "full nodes")))The lightweight client will then send a +The lightweight client will then send a +filterload+ message to the peer, containing the bloom filter to use on the connection. On the peer, bloom filters are checked against each incoming transaction. The full node checks several parts of the @@ -1139,7 +1139,7 @@ client. === Encrypted and Authenticated Connections ((("Bitcoin network", "encrypted -connections")))((("encryption")))((("authentication")))Most new users of +connections")))Most new users of Bitcoin assume that the network communications of a Bitcoin node are encrypted. In fact, the original implementation of Bitcoin communicates entirely in the clear, as does the modern implementation of Bitcoin Core @@ -1151,7 +1151,7 @@ communications: _Tor Transport_. ==== Tor Transport -((("Tor network")))((("The Onion Routing network (Tor)")))Tor, which +Tor, which stands for _The Onion Routing network_, is a software project and network that offers encryption and encapsulation of data through randomized network paths that offer anonymity, untraceability and @@ -1183,8 +1183,8 @@ online tutorials. [[mempool]] === Mempools and orphan pools -((("Bitcoin network", "transaction pools")))((("transaction -pools")))((("memory pools (mempools)")))Almost every node on the Bitcoin +((("transaction +pools")))Almost every node on the Bitcoin network maintains a temporary list of unconfirmed transactions called the _memory pool_ (_mempool_). Nodes use this pool to keep track of transactions that are known to the network but are not @@ -1194,7 +1194,7 @@ As unconfirmed transactions are received and verified, they are added to the mempool and relayed to the neighboring nodes to propagate on the network. -((("orphan pools")))((("transactions", "orphaned")))Some node +Some node implementations also maintain a separate pool of orphaned transactions. If a transaction's inputs refer to a transaction that is not yet known, such as a missing parent, the orphan transaction will be stored diff --git a/overview.adoc b/overview.adoc index 5fe85ee2..54aff439 100644 --- a/overview.adoc +++ b/overview.adoc @@ -1,7 +1,7 @@ [[ch02_bitcoin_overview]] == How Bitcoin Works -((("bitcoin", "overview of", id="BCover02")))((("central trusted +((("central trusted authority")))((("decentralized systems", "bitcoin overview", id="DCSover02")))The Bitcoin system, unlike traditional banking and payment systems, does not require trust in third parties. Instead of a central @@ -22,7 +22,7 @@ transactions that are propagated across the network, and miners who produce (through competitive computation) the consensus blockchain, which is the authoritative journal of all transactions. -((("blockchain explorer sites")))Each example in this chapter is based +Each example in this chapter is based on an actual transaction made on the Bitcoin network, simulating the interactions between several users by sending funds from one wallet to another. While tracking a transaction through @@ -36,7 +36,7 @@ relationships and flows between them. .Bitcoin overview image::images/mbc2_0201.png["Bitcoin Overview"] -((("Bitcoin Block Explorer")))Popular blockchain explorers include: +Popular blockchain explorers include: * https://blockstream.info/[Blockstream Explorer] * https://mempool.space[Mempool.Space] @@ -81,7 +81,7 @@ Alice is offered the option to pay with bitcoin, in addition to the usual options. The checkout cart displays the price in US dollars and also in bitcoin (BTC), at Bitcoin's prevailing exchange rate. -((("payment requests")))((("QR codes", "payment requests")))Bob's +Bob's e-commerce system will automatically create a QR code containing an _invoice_ (<>). @@ -103,7 +103,7 @@ image::images/mbc2_0202.png["payment-request"] [TIP] ==== -((("QR codes", "warnings and cautions")))((("transactions", "warnings +((("transactions", "warnings and cautions")))((("warnings and cautions", "avoid sending money to addresses appearing in book")))Try to scan this with your wallet to see the address and amount but DO NOT SEND MONEY. @@ -131,7 +131,7 @@ register. [NOTE] ==== -((("fractional values")))((("milli-bitcoin")))((("satoshis")))The +The Bitcoin network can transact in fractional values, e.g., from millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a bitcoin, which is known as a satoshi. This book uses the same @@ -160,7 +160,7 @@ can spend that amount in subsequent transactions. === Bitcoin Transactions -((("transactions", "defined")))In simple terms, a transaction tells the +In simple terms, a transaction tells the network that the owner of certain bitcoins has authorized the transfer of that value to another owner. The new owner can now spend the bitcoin by creating another transaction that authorizes the transfer to another @@ -168,12 +168,12 @@ owner, and so on, in a chain of ownership. ==== Transaction Inputs and Outputs -((("transactions", "overview of", id="Tover02")))((("outputs and +((("outputs and inputs", "basics of")))Transactions are like lines in a double-entry bookkeeping ledger. Each transaction contains one or more _inputs_, which spend funds. On the other side of the transaction, there are one or more _outputs_, which receive funds. -((("fees", "transaction fees")))The inputs +The inputs and outputs do not necessarily add up to the same amount. Instead, outputs add up to slightly less than inputs and the difference represents an implied _transaction fee_, which is a small @@ -184,7 +184,7 @@ blockchain. A Bitcoin transaction is shown as a bookkeeping ledger entry in The transaction also contains proof of ownership for each amount of bitcoins (inputs) whose value is being spent, in the form of a digital signature from the owner, which can be independently validated by -anyone. ((("spending bitcoin", "defined")))In Bitcoin terms, spending +anyone. In Bitcoin terms, spending is signing a transaction that transfers value from a previous transaction over to a new owner identified by a Bitcoin address. @@ -194,7 +194,7 @@ image::images/mbc2_0203.png["Transaction Double-Entry"] ==== Transaction Chains -((("chain of transactions")))Alice's payment to Bob's Store uses a +Alice's payment to Bob's Store uses a previous transaction's output as its input. In the previous chapter, Alice received bitcoins from her friend Joe in return for cash. We've labeled that as _Transaction 1_ (Tx1) in <>. @@ -252,7 +252,7 @@ that's what the protocol itself uses. ==== Making Change -((("change, making")))((("change addresses")))((("addresses", "change +((("addresses", "change addresses")))In addition to one or more outputs that pay the receiver of bitcoins, many transactions will also include an output that pays the spender of the bitcoins, called a _change_ output. @@ -327,7 +327,7 @@ blockchain is _payment batching_ that pays to multiple outputs representing multiple recipients (<>). This type of transaction is sometimes used by commercial entities to distribute funds, such as when processing payroll payments to multiple -employees.((("", startref="Tover02"))) +employees. [[transaction-distributing]] .Batch transaction distributing funds @@ -335,7 +335,7 @@ image::images/mbc2_0207.png["Distributing Transaction"] === Constructing a Transaction -((("transactions", "constructing", id="Tconstruct02")))((("wallets", +((("wallets", "constructing transactions")))Alice's wallet application contains all the logic for selecting inputs and generating outputs to build a transaction to Alice's specification. Alice only needs to choose a @@ -349,7 +349,7 @@ while connected to the Bitcoin network. ==== Getting the Right Inputs -((("outputs and inputs", "locating and tracking inputs")))Alice's wallet +Alice's wallet application will first have to find inputs that can pay the amount she wants to send to Bob. Most wallets keep track of all the available outputs belonging to addresses in the wallet. Therefore, Alice's wallet @@ -373,7 +373,7 @@ wallet application creates the transaction outputs (payments). ==== Creating the Outputs -((("outputs and inputs", "creating outputs")))A transaction output is +A transaction output is created with a script that says something like, "This output is paid to whoever can present a signature from the key corresponding to Bob's public address." @@ -416,7 +416,7 @@ blocks are added. ===== Transmitting the transaction -((("propagation", "process of")))Because the transaction contains all +Because the transaction contains all the information necessary for it to be processed, it does not matter how or where it is transmitted to the Bitcoin network. The Bitcoin network is a peer-to-peer network, with each Bitcoin peer participating by @@ -425,7 +425,7 @@ network is to propagate transactions and blocks to all participants. ===== How it propagates -((("Bitcoin nodes", "defined")))((("nodes", see="Bitcoin nodes"))) + Peers in the Bitcoin peer-to-peer network are programs that have both the software logic and the data necessary for them to fully verify the correctness of a new transaction. The connections between peers are @@ -441,7 +441,7 @@ node. Her Bitcoin wallet does not have to be connected to Bob's Bitcoin wallet directly and she does not have to use the internet connection offered by Bob, though both those options are possible, too. ((("propagation", "flooding -technique")))((("flooding technique")))Any Bitcoin node that receives a +technique")))Any Bitcoin node that receives a valid transaction it has not seen before will forward it to all other nodes to which it is connected, a propagation technique known as _gossiping_. Thus, the transaction rapidly propagates out across the @@ -478,7 +478,7 @@ computation to verify as correct. The mining process serves two purposes in Bitcoin: * ((("mining and consensus", "consensus rules", "security provided -by")))((("consensus", see="mining and consensus")))Miners can only +by")))Miners can only receive honest income from creating blocks that follow all of Bitcoin's _consensus rules_. Therefore, miners are normally incentivized to only include valid transactions in their blocks and the blocks they @@ -541,7 +541,7 @@ software to create candidate blocks that assign the reward to a pool address. From there, a share of the reward is distributed to members of the pool miners in proportion to the amount of work they contributed. -((("candidate blocks")))((("blocks", "candidate blocks")))Alice's +Alice's transaction was picked up by the network and included in the pool of unverified transactions. Once validated by a full node, it was included in a candidate block. @@ -583,7 +583,7 @@ You can see the block that includes https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764611cb7acf552e90[Alice's transaction]. ==== -((("confirmations", "role in transactions")))Approximately 19 minutes +Approximately 19 minutes after the block containing Alice's transaction is broadcast, a new block is mined by another miner. Because this new block is built on top of the block that contained Alice's @@ -596,7 +596,7 @@ transaction counts as an additional confirmation. As the blocks pile on top of each other, it becomes harder to reverse the transaction, thereby giving Bob more and more confidence that Alice's payment is secure. -((("genesis block")))((("blocks", "genesis block")))((("blockchain +((("blockchain (the)", "genesis block")))In <>, we can the block which contains Alice's transaction. Below it are hundreds of thousands of blocks, linked to each other in a chain of @@ -607,7 +607,7 @@ By convention, any block with more than six confirmations is considered very hard to change, because it would require an immense amount of computation to recalculate six blocks (plus one new block). We will examine the process of mining and the way it builds confidence in more detail in -<>.((("", startref="BToverview02")))((("", +<>.((("", startref="MACover02"))) [[block-alice1]] diff --git a/preface.asciidoc b/preface.asciidoc index 77181970..cdb827a3 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -3,27 +3,27 @@ === Writing the Bitcoin Book -((("bitcoin", "benefits of", id="BCbasicbenefits0")))((("decentralized systems", "bitcoin as")))I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. ((("digital currencies", "bitcoin vs. others")))I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin. +I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin. Two years later, after creating a number of small startups to explore various Bitcoin-related services and products, I decided that it was time to write my first book. Bitcoin was the topic that had driven me into a frenzy of creativity and consumed my thoughts; it was the most exciting technology I had encountered since the internet. It was now time to share my passion about this amazing technology with a broader audience. === Intended Audience -((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies. +This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies. === Why Are There Bugs on the Cover? -((("decentralized systems", "in nature")))The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming! +The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming! Although ants form a caste-based society and have a queen for producing offspring, there is no central authority or leader in an ant colony. The highly intelligent and sophisticated behavior exhibited by a multimillion-member colony is an emergent property from the interaction of the individuals in a social network. Nature demonstrates that decentralized systems can be resilient and can produce emergent complexity and incredible sophistication without the need for a central authority, hierarchy, or complex parts. -((("decentralized systems", "benefits of")))Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination.((("", startref="BCbasicbenefits0"))) +Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination. === Conventions Used in This Book -((("typographical conventions")))The following typographical conventions are used in this book: +The following typographical conventions are used in this book: _Italic_:: Indicates new terms, URLs, email addresses, filenames, and file extensions. @@ -61,9 +61,9 @@ All the code snippets use real values and calculations where possible, so that y This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. -((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.” +We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.” -((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply. +Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply. If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at pass:[permissions@oreilly.com]. @@ -73,13 +73,13 @@ include::meta/third_edition_changes.asciidoc[] === Bitcoin Addresses and Transactions in This Book -((("getting started", "warnings and cautions")))((("warnings and cautions", "avoid sending money to addresses appearing in book")))((("keys and addresses", "warnings and cautions")))((("transactions", "warnings and cautions")))((("blockchain applications", "warnings and cautions")))((("QR codes", "warnings and cautions")))The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc. +The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc. However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here. [WARNING] ==== -DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.((("", startref="codeuse00"))) +DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever. ==== === O'Reilly Safari @@ -96,7 +96,7 @@ For more information, please visit pass:[ @@ -146,7 +146,7 @@ link:$$https://dtrt.org/$$[] _By Andreas M. Antonopoulos_ -((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin. +This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin. It is impossible to make a distinction between the Bitcoin technology and the Bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire Bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful. diff --git a/security.adoc b/security.adoc index 26441781..8db03a94 100644 --- a/security.adoc +++ b/security.adoc @@ -20,7 +20,7 @@ need to think about securing your bitcoins in a novel way too. === Security Principles -((("security", "security principles", id="Sprinc11")))((("decentralized +((("decentralized systems", "security of")))The core principle in Bitcoin is decentralization and it has important implications for security. A centralized model, such as a traditional bank or payment network, @@ -63,7 +63,7 @@ able to adequately secure their keys and get hacked, one by one. ==== Developing Bitcoin Systems Securely -((("decentralized systems", "bitcoin as")))A critical principle +A critical principle for Bitcoin developers is decentralization. Most developers will be familiar with centralized security models and might be tempted to apply these models to their Bitcoin applications, with disastrous results. @@ -93,7 +93,7 @@ ultimately subvert Bitcoin's security. ==== The Root of Trust -((("root of trust concept")))Traditional security architecture is based +Traditional security architecture is based upon a concept called the _root of trust_, which is a trusted core used as the foundation for the security of the overall system or application. Security architecture is developed around the root of trust as a series @@ -112,7 +112,7 @@ of a single system, then extending that root of trust through the operating system to higher-level system services, and finally across many servers layered in concentric circles of diminishing trust. -((("mining and consensus", "security and consensus")))Bitcoin security +Bitcoin security architecture is different. In Bitcoin, the consensus system creates a trusted blockchain that is completely decentralized. A correctly validated blockchain uses the genesis block as the root of trust, @@ -146,7 +146,7 @@ startref="Sprinc11"))) === User Security Best Practices -((("security", "user security best practices", id="Suser11")))((("use +((("use cases", "user security best practices", id="UCsecurity11")))Humans have used physical security controls for thousands of years. By comparison, our experience with digital security is less than 50 years old. Modern @@ -193,8 +193,8 @@ we will examine various best practices for practical user security. ==== Physical Bitcoin Storage -((("storage", "physical bitcoin storage")))((("paper -wallets")))((("wallets", "types of", "paper wallets")))((("paper +((("paper +wallets")))((("paper wallets", see="also wallets")))Because most users are far more comfortable with physical security than information security, a very effective method for protecting bitcoins is to convert them into physical @@ -225,7 +225,7 @@ signing devices may become the predominant method of storing bitcoins. ==== Ensuring Your Access -((("risk, balancing and diversifying", seealso="security")))Although +Although most users are rightly concerned about theft of thir bitcoins, there is an even bigger risk. Data files get lost all the time. If they contain Bitcoin keys, the loss is much more painful. In the effort to secure their Bitcoin @@ -262,7 +262,7 @@ storage). ==== Multisig and Governance -((("multisig addresses")))((("addresses", "multisig +((("addresses", "multisig addresses")))Whenever a company or individual stores large amounts of bitcoins, they should consider using a multisignature Bitcoin address. Multisignature addresses secure funds by requiring more than one @@ -277,8 +277,8 @@ stored in different locations. ==== Survivability -((("survivability")))((("digital asset executors")))((("passwords", -"survivability and")))((("security", "passwords")))One important +((("passwords", +"survivability and")))One important security consideration that is often overlooked is availability, especially in the context of incapacity or death of the key holder. Bitcoin users are told to use complex passwords and keep their keys @@ -292,7 +292,7 @@ If you have a lot of bitcoins, you should consider sharing access details with a trusted relative or lawyer. A more complex survivability scheme can be set up with multi-signature access and estate planning through a lawyer specialized as a "digital asset executor."((("", -startref="Suser11")))((("", startref="UCsecurity11"))) +startref="Suser11"))) Bitcoin is a completely new, unprecedented, and complex technology. Over time we will develop better security tools and practices that are easier diff --git a/signatures.adoc b/signatures.adoc index ba051172..fe959e84 100644 --- a/signatures.adoc +++ b/signatures.adoc @@ -1,7 +1,7 @@ [[c_signatures]] == Digital Signatures -((("digital signatures", "algorithm used")))((("Elliptic Curve Digital +((("Elliptic Curve Digital Signature Algorithm (ECDSA)")))Two signature algorithms are currently used in Bitcoin, the _schnorr signature algorithm_ and the _Elliptic Curve Digital Signature Algorithm_ (_ECDSA_). @@ -14,7 +14,7 @@ keypath spending, and by the script functions +OP_CHECKSIG+, Any time one of those is executed, a signature must be provided. -((("digital signatures", "purposes of")))A digital signature serves +A digital signature serves three purposes in Bitcoin. First, the signature proves that the controller of a private key, who is by implication the owner of the funds, has _authorized_ the spending of @@ -38,7 +38,7 @@ key. === How Digital Signatures Work -((("digital signatures", "how they work")))A digital signature +A digital signature consists of two parts. The first part is an algorithm for creating a signature for a message (the transaction) using a private key (the signing key). The second part is an algorithm @@ -70,7 +70,7 @@ In both schnorr and ECDSA signatures, the function _F_~_sig_~ produces a signatu two values. There are differences between the two values in the different algorithms, which we'll explore later. -((("Distinguished Encoding Rules (DER)")))After the two values +After the two values are calculated, they are serialized into a byte-stream. For ECDSA signatures, the encoding uses an international standard encoding scheme called the @@ -79,7 +79,7 @@ simpler serialization format is used. ==== Verifying the Signature -((("digital signatures", "verifying"))) The signature verification + The signature verification algorithm takes the message (a hash of parts of the transaction and related data), the signer's public key and the signature, and returns TRUE if the signature is valid for this message and public key. @@ -95,7 +95,7 @@ signature on this transaction." ==== Signature Hash Types (SIGHASH) ((("digital signatures", "signature hash -types")))((("commitment")))Digital signatures apply to messages, +types")))Digital signatures apply to messages, which in the case of Bitcoin, are the transactions themselves. The signature prove a _commitment_ by the signer to specific transaction data. In the simplest form, the signature applies to almost the entire @@ -104,7 +104,7 @@ transaction fields. However, a signature can commit to only a subset of the data in a transaction, which is useful for a number of scenarios as we will see in this section. -((("SIGHASH flags")))Bitcoin signatures have a way of indicating which +Bitcoin signatures have a way of indicating which part of a transaction's data is included in the hash signed by the private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte that is appended to the signature. Every signature has either an @@ -176,7 +176,7 @@ of all inputs and outputs. This is the most common signature form. Let's look at some of the other +SIGHASH+ types and how they can be used in practice: -+ALL|ANYONECANPAY+ :: ((("charitable donations")))((("use cases", ++ALL|ANYONECANPAY+ :: ((("use cases", "charitable donations")))This construction can be used to make a "crowdfunding”-style transaction. Someone attempting to raise funds can construct a transaction with a single output. The single @@ -209,7 +209,7 @@ without the cost in fees exceeding the value of the UTXO, see of signature, the uneconomical UTXOs can be donated for anyone to aggregate and spend whenever they want. -((("Bitmask Sighash Modes")))There are some proposals to modify or +There are some proposals to modify or expand the +SIGHASH+ system. The most widely discussed proposal as of this writing is BIP118, which proposes to add two new sighash flags. A signature using +SIGHASH_ANYPREVOUT+ would not @@ -886,7 +886,7 @@ as follows: [[nonce_warning]] === The Importance of Randomness in Signatures -((("digital signatures", "randomness in")))As we saw in <> and <>, +As we saw in <> and <>, the signature generation algorithm uses a random number _k_, as the basis for a private/public nonce pair. The value of _k_ is not important, _as long as it is random_. If signatures from the same @@ -898,7 +898,7 @@ key! [WARNING] ==== -((("warnings and cautions", "digital signatures")))If the same value _k_ +If the same value _k_ is used in the signing algorithm on two different transactions, the private key can be calculated and exposed to the world! ==== @@ -910,8 +910,8 @@ because of inadvertent reuse of a _k_ value. The most common reason for reuse of a _k_ value is an improperly initialized random-number generator. -((("random numbers", "random number generation")))((("entropy", "random -number generation")))((("deterministic initialization")))To avoid this +((("entropy", "random +number generation")))To avoid this vulnerability, the industry best practice is to not generate _k_ with a random-number generator seeded only with entropy, but instead to use a process seeded in part with the transaction data itself plus the diff --git a/wallets.adoc b/wallets.adoc index 096b6994..7354c075 100644 --- a/wallets.adoc +++ b/wallets.adoc @@ -20,7 +20,7 @@ In those cases, we'll describe the various options available. === Independent Key Generation -((("wallets", "contents of")))Wallets for physical cash hold that cash, +Wallets for physical cash hold that cash, so it's unsurprising that many people mistakenly believe that bitcoin wallets contain bitcoins. In fact, what many people call a Bitcoin wallet--which we call a _wallet database_ to distinguish it @@ -211,7 +211,7 @@ We'll provide a detailed exploration of HD wallets in <>. ==== Seeds and Recovery Codes -((("wallets", "technology of", "seeds and recovery codes")))((("recovery +((("recovery code words")))((("bitcoin improvement proposals", "Recovery Code Words (BIP39)")))HD wallets are a very powerful mechanism for managing many keys all derived from a single seed. If your wallet database @@ -624,7 +624,7 @@ modern standards that may provide additional features or safety. [[recovery_code_words]] ==== BIP39 Recovery Codes -((("wallets", "technology of", "recovery code words")))((("recovery code +((("recovery code words", id="mnemonic05")))((("bitcoin improvement proposals", "Recovery Code Words (BIP39)", id="BIP3905")))BIP39 recovery codes are word sequences that represent (encode) a random number used as a seed to @@ -640,7 +640,7 @@ transcribe. [TIP] ==== -((("brainwallets")))Recovery codes are often confused with +Recovery codes are often confused with "brainwallets." They are not the same. The primary difference is that a brainwallet consists of words chosen by the user, whereas recovery codes are created randomly by the wallet and presented to the user. This @@ -705,13 +705,13 @@ data and the length of recovery code in words. [[recovery_to_seed]] ===== From recovery code to seed -((("key-stretching function")))((("PBKDF2 function")))The recovery code +The recovery code represents entropy with a length of 128 to 256 bits. The entropy is then used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The seed produced is then used to build a deterministic wallet and derive its keys. -((("salts")))((("passphrases")))The key-stretching function takes two +The key-stretching function takes two parameters: the entropy and a _salt_. The purpose of a salt in a key-stretching function is to make it difficult to build a lookup table enabling a brute-force attack. In the BIP39 standard, the salt has @@ -858,7 +858,7 @@ recovery codes (or a value near 128, such as Electrum v2's 132 bits). [[recovery_passphrase]] ===== Optional passphrase in BIP39 -((("passphrases")))The BIP39 standard allows the use of an optional +The BIP39 standard allows the use of an optional passphrase in the derivation of the seed. If no passphrase is used, the recovery code is stretched with a salt consisting of the constant string +"mnemonic"+, producing a specific 512-bit seed from any given recovery code. @@ -904,7 +904,7 @@ her family to recover the cryptocurrency estate. ==== Creating an HD Wallet from the Seed ((("wallets", "technology of", "creating HD wallets from root -seed")))((("root seeds")))((("hierarchical deterministic (HD) +seed")))((("hierarchical deterministic (HD) wallets")))HD wallets are created from a single _root seed_, which is a 128-, 256-, or 512-bit random number. Most commonly, this seed is generated by or decrypted from a _recovery code_ as detailed in the previous section. @@ -936,7 +936,7 @@ creates child keys from parent keys, as we will see in the next section. ===== Private child key derivation -((("child key derivation (CKD)")))((("public and private keys", "child +((("public and private keys", "child key derivation (CKD)")))HD wallets use a _child key derivation_ (CKD) function to derive child keys from parent keys. @@ -1008,7 +1008,7 @@ operate exactly as "normal" keys. ===== Extended keys -((("public and private keys", "extended keys")))((("extended keys")))As +As we saw earlier, the key derivation function can be used to create children at any level of the tree, based on the three inputs: a key, a chain code, and the index of the desired child. The two essential @@ -1055,7 +1055,7 @@ xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLr [[public__child_key_derivation]] ===== Public child key derivation -((("public and private keys", "public child key derivation")))As +As mentioned previously, a very useful characteristic of HD wallets is the ability to derive public child keys from public parent keys, _without_ having the private keys. This gives us two ways to derive a child public @@ -1133,7 +1133,7 @@ address for the actual transaction. However, these other solutions have not been used in production as of this writing. **** -((("cold storage")))((("storage", "cold storage")))((("hardware +((("hardware wallets")))Another common application of this solution is for cold-storage or hardware signing devices. In that scenario, the extended private key can be stored on a paper wallet or hardware device, while @@ -1152,7 +1152,7 @@ image::images/mbc2_0511.png["ChildPublicDerivation"] ((("wallets", "technology of", "using extended public keys on web stores")))Let's see how HD wallets are used by looking at -Gabriel's web store.((("use cases", "web store", id="gabrielfivetwo"))) +Gabriel's web store. Gabriel first set up his web store as a hobby, based on a simple hosted Wordpress page. His store was quite basic with only a few pages and an @@ -1206,7 +1206,7 @@ software, such as the widely used open source BTCPay Server. ===== Hardened child key derivation ((("public and private keys", "hardened child key -derivation")))((("hardened derivation")))The ability to derive a branch +derivation")))The ability to derive a branch of public keys from an xpub is very useful, but it comes with a potential risk. Access to an xpub does not give access to child private keys. However, because the xpub contains the chain code, if a child @@ -1273,7 +1273,7 @@ has special meaning, using the letter _h_ is recommended. ===== HD wallet key identifier (path) -((("hierarchical deterministic (HD) wallets")))Keys in an HD wallet are +Keys in an HD wallet are identified using a "path" naming convention, with each level of the tree separated by a slash (/) character (see <>). Private keys derived from the master private key start with "m." Public keys derived @@ -1344,7 +1344,7 @@ contain two Bitcoin "accounts": m/44++'++/0++'++/0++'++ and m/44++'++/0++'++/1++'++. Each account is the root of its own subtree. -((("keys and addresses", see="also public and private keys")))On the +On the fourth level, "change," an HD wallet has two subtrees, one for creating receiving addresses and one for creating change addresses. Note that whereas the previous levels used hardened derivation, this level uses diff --git a/whitepaper.adoc b/whitepaper.adoc index c70f6284..dcddb15c 100644 --- a/whitepaper.adoc +++ b/whitepaper.adoc @@ -4,7 +4,7 @@ [NOTE] ==== -((("whitepaper", id="whitethirteen")))((("bitcoin whitepaper", id="BCwhitethirteen")))((("Nakamoto, Satoshi", id="nakamatothirteen")))This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008. +This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008. ==== === Bitcoin - A Peer-to-Peer Electronic Cash System @@ -450,7 +450,7 @@ We have proposed a system for electronic transactions without relying on trust. === License -((("open source licenses")))This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license: +This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license: The MIT License (MIT) Copyright (c) 2008 Satoshi Nakamoto @@ -459,4 +459,4 @@ Permission is hereby granted, free of charge, to any person obtaining a copy of The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. -THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.((("", startref="whitethirteen")))((("", startref="nakamatothirteen")))((("", startref="BCwhitethirteen"))) +THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.