From ab1803246f81bf26fedddad377a58860b4abb356 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Thu, 24 Aug 2023 10:47:54 +0200 Subject: [PATCH] All: harding edits for complete readthrough --- applications.adoc | 67 ++++---- author_bio.html | 2 +- authorization-authentication.adoc | 246 +++++++++++++--------------- bips.adoc | 10 +- bitcoin-core.adoc | 13 +- blockchain.adoc | 19 +-- errata.adoc | 38 ++--- fees.adoc | 31 ++-- glossary.asciidoc | 24 ++- intro.adoc | 62 +++---- keys.adoc | 43 +++-- meta/third_edition_changes.asciidoc | 2 +- mining.adoc | 246 +++++++++++----------------- network.adoc | 29 +--- overview.adoc | 163 +++++++----------- preface.asciidoc | 15 +- security.adoc | 22 +-- signatures.adoc | 51 ++---- tools/discouraged.sh | 5 + transactions.adoc | 12 +- wallets.adoc | 35 ++-- 21 files changed, 487 insertions(+), 648 deletions(-) diff --git a/applications.adoc b/applications.adoc index 2e4ba652..ea812921 100644 --- a/applications.adoc +++ b/applications.adoc @@ -1,14 +1,11 @@ [[ch12]] -== Blockchain Applications +== Second-Layer Applications -Let's now build on our understanding of Bitcoin by looking at it as an -_application platform_. Nowadays, many people use the term "blockchain" -to refer to any application platform that shares the design principles -of Bitcoin. The term is often misused and applied to many things that -fail to deliver the primary features that Bitcoin's blockchain delivers. - -In this chapter we will look at the features offered by the Bitcoin -blockchain as an application platform. We will consider the application +Let's now build on our understanding of the primary Bitcoin system (the +_first layer_) by looking at it as an +platform for other applications, or _second layers_. +In this chapter we will look at the features offered by Bitcoin +as an application platform. We will consider the application building _primitives_, which form the building blocks of any blockchain application. We will look at several important applications that use these primitives, such as client-side validation, payment channels, and @@ -43,7 +40,7 @@ Secure Timestamping:: The consensus rules reject any block whose timestamp is too far in the future and attempt to prevent blocks with timestamps too far in the past. This ensures that timestamps on blocks can be trusted to a certain degree. The timestamp on a block implies an -unspent-before guarantee for the inputs of all included transactions. +unspent-before reference for the inputs of all included transactions. Authorization:: Digital signatures, validated in a decentralized network, offer authorization guarantees. Scripts that contain a @@ -218,7 +215,7 @@ to reveal the contract used to tweak the keys. Nothing is publicly revealed about the contract--not even that a contract between them exists. -A P2C contract can arbitrary long and detailed, the terms can be written +A P2C contract can be arbitrarily long and detailed, the terms can be written in any language, and it can reference anything the participants want because the contract is not validated by full nodes and only the public key with the commitment is published to the blockchain. @@ -369,7 +366,7 @@ channels", id="BCApayment12")))((("payment (state) channels", "defined")))are a trustless mechanism for exchanging Bitcoin transactions between two parties, outside of the Bitcoin blockchain. These transactions, which would be valid if settled on the Bitcoin -blockchain, are held off-chain instead, waiting for +blockchain, are held offchain instead, waiting for eventual batch settlement. Because the transactions are not settled, they can be exchanged without the usual settlement latency, allowing extremely high transaction throughput, low latency, and @@ -403,7 +400,7 @@ channels in a routed network, first proposed under the name _Lightning Network_. Payment channels are part of the broader concept of a _state channel_, -which represents an off-chain alteration of state, secured by eventual +which represents an offchain alteration of state, secured by eventual settlement in a blockchain. A payment channel is a state channel where the state being altered is the balance of a virtual currency. @@ -420,7 +417,7 @@ of the channel. The two parties then exchange signed transactions, called _commitment transactions_, that alter the initial state. These transactions are valid transactions in that they _could_ be submitted for settlement by -either party, but instead are held off-chain by each party pending the +either party, but instead are held offchain by each party pending the channel closure. State updates can be created as fast as each party can create, sign, and transmit a transaction to the other party. In practice this means that dozens of transactions per second can be exchanged. @@ -508,7 +505,7 @@ paid to the multisignature 2-of-2 address controlled jointly between Emma and Fabian. It may have additional outputs for change back to Emma's wallet. -Once the funding transaction is confirmed, Emma can start streaming +After the funding transaction is confirmed to a sufficent depth, Emma can start streaming video. Emma's software creates and signs a commitment transaction that changes the channel balance to credit 0.01 millibit to Fabian's address and refund 35.99 millibits back to Emma. The transaction signed by Emma @@ -743,10 +740,10 @@ funding transaction locks the channel state in a 2-of-2 multisig, just like in the example of a simple channel. The funding transaction may have one or more inputs from Hitesh (adding -up to 5 bitcoin or more), and one or more inputs from Irene (adding up -to 5 bitcoin or more). The inputs have to slightly exceed the channel +up to 5 bitcoins or more), and one or more inputs from Irene (adding up +to 5 bitcoins or more). The inputs have to slightly exceed the channel capacity in order to cover the transaction fees. The transaction has one -output that locks the 10 total bitcoin to a 2-of-2 multisig address +output that locks the 10 total bitcoins to a 2-of-2 multisig address controlled by both Hitesh and Irene. The funding transaction may also have one or more outputs returning change to Hitesh and Irene if their inputs exceeded their intended channel contribution. This is a single @@ -759,17 +756,17 @@ parties sign, Hitesh and Irene create two different commitment transactions that are _asymmetric_. Hitesh has a commitment transaction with two outputs. The first output -pays Irene the 5 bitcoin she is owed _immediately_. The second output -pays Hitesh the 5 bitcoin he is owed, but only after a timelock of 1000 +pays Irene the 5 bitcoins she is owed _immediately_. The second output +pays Hitesh the 5 bitcoins he is owed, but only after a timelock of 1000 blocks. The transaction outputs look like this: ---- Input: 2-of-2 funding output, signed by Irene -Output 0 <5 bitcoin>: +Output 0 <5 bitcoins>: CHECKSIG -Output 1 <5 bitcoin>: +Output 1 <5 bitcoins>: <1000 blocks> CHECKSEQUENCEVERIFY DROP @@ -777,18 +774,18 @@ Output 1 <5 bitcoin>: ---- Irene has a different commitment transaction with two outputs. The first -output pays Hitesh the 5 bitcoin he is owed immediately. The second -output pays Irene the 5 bitcoin she is owed but only after a timelock of +output pays Hitesh the 5 bitcoins he is owed immediately. The second +output pays Irene the 5 bitcoins she is owed but only after a timelock of 1000 blocks. The commitment transaction Irene holds (signed by Hitesh) looks like this: ---- Input: 2-of-2 funding output, signed by Hitesh -Output 0 <5 bitcoin>: +Output 0 <5 bitcoins>: CHECKSIG -Output 1 <5 bitcoin>: +Output 1 <5 bitcoins>: <1000 blocks> CHECKSEQUENCEVERIFY DROP @@ -843,10 +840,10 @@ state and wants to revoke this commitment. The second output's script looks like this: ---- -Output 0 <5 bitcoin>: +Output 0 <5 bitcoins>: CHECKSIG -Output 1 <5 bitcoin>: +Output 1 <5 bitcoins>: IF # Revocation penalty output @@ -880,7 +877,7 @@ Irene will be able to redeem the output and punish Hitesh before the The revocation protocol is bilateral, meaning that in each round, as the channel state is advanced, the two parties exchange new commitments, exchange revocation secrets for the previous commitments, and sign each -other's new commitment transactions. As they accept a new state, they +other's new commitment transactions. After they accept a new state, they make the prior state impossible to use, by giving each other the necessary revocation secrets to punish any cheating. @@ -921,7 +918,7 @@ remain open indefinitely and can have billions of intermediate commitment transactions. In implementations of Lightning Network, the commitment state is identified by a 48-bit index, allowing more than 281 trillion (2.8 x 10^14^) state transitions in any single -channel!((("", startref="PSCaymetric12"))) +channel. ==== Hash Time Lock Contracts (HTLC) @@ -1147,7 +1144,7 @@ does not know that Bob is actually relaying a payment from Alice. She also doesn't know that Diana will be relaying a payment to Eric. This is a critical feature of the Lightning Network, because it ensures -privacy of payments and makes it very difficult to apply surveillance, +privacy of payments and makes it difficult to apply surveillance, censorship, or blacklists. But how does Alice establish this payment path, without revealing anything to the intermediary nodes? @@ -1212,8 +1209,8 @@ 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. -If a Lightning Network is layered on top of the Bitcoin network, the -Bitcoin network can gain a significant increase in capacity, privacy, +Lightning Network is layered on top of the Bitcoin network, giving +Bitcoin a significant increase in capacity, privacy, granularity, and speed, without sacrificing the principles of trustless operation without intermediaries: @@ -1234,9 +1231,9 @@ Granularity:: A Lightning Network can enable payments at least as small as the Bitcoin "dust" limit, perhaps even smaller. Capacity:: A Lightning Network increases the capacity of the Bitcoin -system by several orders of magnitude. There is no practical upper bound +system by several orders of magnitude. The upper bound to the number of payments per second that can be routed over a Lightning -Network, as it depends only on the capacity and speed of each node. +Network depends only on the capacity and speed of each node. Trustless Operation:: A Lightning Network uses Bitcoin transactions between nodes that operate as peers without trusting each other. Thus, a diff --git a/author_bio.html b/author_bio.html index fd0b92a1..4616e610 100644 --- a/author_bio.html +++ b/author_bio.html @@ -9,5 +9,5 @@

As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.

-

David A. Harding is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22). David previously worked freelance (2007-15).

+

David A. Harding is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22).

diff --git a/authorization-authentication.adoc b/authorization-authentication.adoc index e1901fe5..90daa7f9 100644 --- a/authorization-authentication.adoc +++ b/authorization-authentication.adoc @@ -61,7 +61,7 @@ of conditions to be expressed. ==== Turing Incompleteness -((("Turing incompleteness")))The bitcoin transaction script language +((("Turing incompleteness")))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 @@ -96,25 +96,25 @@ system. Bitcoin's legacy transaction validation engine relies on two parts of scripts to validate transactions: an output script and an input script. -An output script is a spending condition placed on an output: -it specifies the conditions that must be met to spend the output in the +An output script +specifies the conditions that must be met to spend the output in the future, such as who is authorized to spend the output and how they will be authenticated. An input script is a script that satisfies the -conditions placed on an output by an output script and allows the output +conditions placed in an output script and allows the output to be spent. Input scripts are part of every transaction input. Most of the time in legacy transactions they contain a digital signature produced by the user's wallet from his or her private key, but not all input scripts must contain signatures. -Every bitcoin validating node will validate transactions by executing +Every Bitcoin validating node will validate transactions by executing the output and input scripts. As we saw in <>, each input contains an outpoint which refers to a previous transaction output. The input also contains an input script. The validation software will copy the input script, retrieve the UTXO referenced by the input, and copy the output script from that UTXO. The -input and output scripts are then executed in sequence. The input is +input and output scripts are then executed together. The input is valid if the input script satisfies the output script's conditions (see <>). All the inputs are validated independently, as part of the overall validation of the transaction. @@ -140,11 +140,9 @@ image::images/mbc2_0603.png["input_and_output_scripts"] Bitcoin's scripting language is called a stack-based language because it uses a data structure called a _stack_. A stack is a very simple data -structure that can be visualized as a stack of cards. A stack allows two -operations: push and pop. Push adds an item on top of the stack. Pop -removes the top item from the stack. Operations on a stack can only act -on the topmost item on the stack. A stack data structure is also called -a Last-In-First-Out, or "LIFO" queue. +structure that can be visualized as a stack of cards. A stack has two +base operations: push and pop. Push adds an item on top of the stack. Pop +removes the top item from the stack. The scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. @@ -294,9 +292,7 @@ script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG ---- -When executed, this combined script will evaluate to TRUE if, and only -if, the input script matches the conditions set by the output script. -In other words, the result will be TRUE if the input script +The result will be TRUE if the input script has a valid signature from Bob's private key that corresponds to the public key hash set as an encumbrance. @@ -338,19 +334,6 @@ to tell "m" and "n" apart when they're spoken, so we use the alternative t-of-k. Both phrases refer to the same type of signature scheme. ==== -At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 3 -listed public keys, meaning you can do anything from a 1-of-1 to a -3-of-3 multisignature or any combination within that range. -You may want to check the +IsStandard()+ function to see what is currently -accepted by the network. Note that the limit of 3 keys applies only to -standard (also known as "bare") multisignature scripts, not to -multisignature scripts wrapped in a Pay-to-Script-Hash (P2SH) script. -P2SH multisignature scripts are limited by both policy and consensus to -15 keys, allowing for up to 15-of-15 multisignature. We will learn about -P2SH in <>. All other scripts are consensus limited to 20 keys -per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one -script may include multiple of those opcodes. - The general form of a output script setting a t-of-k multisignature condition is: @@ -369,7 +352,7 @@ this: ---- The preceding output script can be satisfied with an input script -containing pairs of signatures and public keys: +containing signatures: ---- @@ -381,22 +364,34 @@ to the three listed public keys. The two scripts together would form the combined validation script: ---- - 2 3 OP_CHECKMULTISIG + 2 3 OP_CHECKMULTISIG ---- -When executed, this combined script will evaluate to TRUE if, and only -if, the input script script matches the conditions set by the output script. -In this case, the condition is whether the input script has -a valid signature from the two private keys that correspond to two of +When executed, this combined script will evaluate to TRUE if +the input script has +two valid signatures from private keys that correspond to two of the three public keys set as an encumbrance. +At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 3 +listed public keys, meaning you can do anything from a 1-of-1 to a +3-of-3 multisignature or any combination within that range. +You may want to check the +IsStandard()+ function to see what is currently +accepted by the network. Note that the limit of 3 keys applies only to +standard (also known as "bare") multisignature scripts, not to +scripts wrapped in another structure like P2SH, P2WSH, or P2TR. +P2SH multisignature scripts are limited by both policy and consensus to +15 keys, allowing for up to 15-of-15 multisignature. We will learn about +P2SH in <>. All other scripts are consensus limited to 20 keys +per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one +script may include multiple of those opcodes. + [[multisig_bug]] ==== An oddity in CHECKMULTISIG execution ((("scripting", "multisignature scripts", "OP_CHECKMULTISIG oddity")))((("OP_CHECKMULTISIG oddity workaround")))There is an oddity in ++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When -+OP_CHECKMULTISIG+ executes, it should consume K+N+2 items on the stack as ++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 value or one value more than expected. @@ -404,16 +399,16 @@ Let's look at this in greater detail using the previous validation example: ---- - 2 3 OP_CHECKMULTISIG + 2 3 OP_CHECKMULTISIG ---- -First, +OP_CHECKMULTISIG+ pops the top item, which is +N+ (in this example -"3"). Then it pops +N+ items, which are the public keys that can sign. +First, +OP_CHECKMULTISIG+ pops the top item, which is +k+ (in this example +"3"). Then it pops +k+ items, which are the public keys that can sign. In this example, public keys A, B, and C. Then, it pops one item, which -is +K+, the quorum (how many signatures are needed). Here M = 2. At this -point, +OP_CHECKMULTISIG+ should pop the final +K+ items, which are the +is +t+, the quorum (how many signatures are needed). Here t = 2. At this +point, +OP_CHECKMULTISIG+ should pop the final +t+ items, which are the signatures, and see if they are valid. However, unfortunately, an oddity in -the implementation causes +OP_CHECKMULTISIG+ to pop one more item (K+1 +the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1 total) than it should. The extra item is called the _dummy stack element_ and it is disregarded when checking the signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself. @@ -429,7 +424,7 @@ replicated forever. Therefore a script should look like this: ---- -OP_0 2 3 OP_CHECKMULTISIG +OP_0 2 3 OP_CHECKMULTISIG ---- Thus the input script actually used in multisig is not: @@ -441,13 +436,13 @@ Thus the input script actually used in multisig is not: but instead it is: ---- -OP_0 +OP_0 ---- Some people believe this oddity was a bug in the original code for Bitcoin, but a plausible alternative explanation exists. Verifying t-of-k signatures can require many more than t or k signature checking -operations. Let's consider a simple example of 1-in-3, with the +operations. Let's consider a simple example of 1-in-5, with the following combined script: ---- @@ -460,7 +455,7 @@ the other keys before it is finally compared to its corresponding performed even though there's only one signature. One way to eliminate this redundancy would have been to provide OP_CHECKMULTISIG a map indicating which provided signature corresponds to which public key, -allowing the OP_CHECKMULTISIG operation to only perform exactly K +allowing the OP_CHECKMULTISIG operation to only perform exactly +t+ signature-checking operations. It's possible that Bitcoin's original developer added the extra element (which we now call the dummy stack element) in the original version of Bitcoin so that they could add the @@ -483,21 +478,20 @@ startref="Smulti07"))) ((("transactions", "advanced", "Pay-to-Script-Hash")))((("scripting", "Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was -introduced in 2012 as a powerful new type of transaction that greatly -simplifies the use of complex transaction scripts. To explain the need +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", "Pay-to-Script-Hash", "import/export example")))((("Pay-to-Script-Hash (P2SH)", "import/export example"))) Mohammed is an electronics importer based in Dubai. Mohammed's -company uses bitcoin's multisignature feature extensively for its +company uses Bitcoin's multisignature feature extensively for its corporate accounts. Multisignature scripts are one of the most common -uses of bitcoin's advanced scripting capabilities and are a very -powerful feature. ((("accounts receivable (AR)")))Mohammed's company -uses a multisignature script for all customer payments, known in -accounting terms as "accounts receivable," or AR. With the -multisignature scheme, any payments made by customers are locked in such +uses of Bitcoin's advanced scripting capabilities and are a very +powerful feature. Mohammed's company +uses a multisignature script for all customer payments. +Any payments made by customers are locked in such a way that they require at least two signatures to release. Mohammed, his three partners, and their attorney can each provide one signature. A multisignature scheme like that offers corporate governance @@ -512,9 +506,8 @@ The resulting script is quite long and looks like this: Although multisignature scripts are a powerful feature, they are cumbersome to use. Given the preceding script, Mohammed would have to communicate this script to every customer prior to payment. Each -customer would have to use special bitcoin wallet software with the -ability to create custom transaction scripts, and each customer would -have to understand how to create a transaction using custom scripts. +customer would have to use special Bitcoin wallet software with the +ability to create custom transaction scripts. Furthermore, the resulting transaction would be about five times larger than a simple payment transaction, because this script contains very long public keys. The burden of that extra data would be @@ -524,7 +517,7 @@ node, until it was spent. All of these issues make using complex output scripts difficult in practice. P2SH was developed to resolve these practical difficulties and to make -the use of complex scripts as easy as a payment to a Bitcoin address. +the use of complex scripts as easy as a payment to a single-key Bitcoin address. With P2SH payments, the complex script is replaced with a commitment, the digest of a cryptographic hash. When a transaction attempting to spend the UTXO is presented later, it must contain the script that @@ -559,7 +552,7 @@ details the conditions for spending the output (redeem script) is not presented in the output script. Instead, only a hash of it is in the output script and the reedemScript itself is presented later, as part of the input script when the output is spent. This shifts the burden -in fees and complexity from the sender to the recipient (spender) of the +in fees and complexity from the spender to the receiver of the transaction. Let's look at Mohammed's company, the complex multisignature script, and @@ -654,15 +647,9 @@ of")))((("Pay-to-Script-Hash (P2SH)", "benefits of")))The P2SH feature offers the following benefits compared to the direct use of complex scripts in outputs: -- Complex scripts are replaced by shorter commitments in the - transaction output, making the transaction smaller. - - The similarity to original legacy addresses means the sender and the sender's wallet don't need complex engineering to implement P2SH. -- P2SH shifts the burden of constructing the script to the recipient, - not the sender. - - P2SH shifts the burden in data storage for the long script from the output (which additionally to being stored on the blockchain is in the UTXO set) to the input (only stored on the blockchain). @@ -694,7 +681,7 @@ risk, because you can send bitcoin to a P2SH address that cannot be spent later. ==== ((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts contain the hash of a redeem script, which gives no clues as to -the content of the redeem script. The P2SH transaction will be +the content of the redeem script. The P2SH output will be considered valid and accepted even if the redeem script is invalid. You might accidentally receive bitcoin in such a way that it cannot later be spent. @@ -707,28 +694,28 @@ spent. "data recording output")))((("OP_RETURN operator")))((("data recording (nonpayment data)")))((("nonpayment data")))((("blockchain (the)", "nonpayment data recording")))((("digital notary services")))Bitcoin's -distributed and timestamped ledger, the blockchain, has potential uses +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 -the system for applications such as digital notary services -and smart contracts. Early attempts to use bitcoin's +the system for applications such as digital notary services. +Early attempts to use Bitcoin's script language for these purposes involved creating transaction outputs -that recorded data on the blockchain; for example, to record a digital -fingerprint of a file in such a way that anyone could establish +that recorded data on the blockchain; for example, to record a commitment +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 -unrelated to bitcoin payments is a controversial subject. Many +(UTXO)")))((("UTXO sets")))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 technology and want to encourage such experimentation. Those who object -to the inclusion of nonpayment data argue that it causes "blockchain -bloat," burdening those running full Bitcoin nodes with carrying the +to the inclusion of nonpayment data argue that it +burdens those running full Bitcoin nodes with carrying the cost of disk storage for data that the blockchain was not intended to -carry. Moreover, such transactions create UTXOs that cannot be spent, -using the destination legacy Bitcoin address as a freeform 20-byte field. +carry. Moreover, such transactions may create UTXOs that cannot be spent, +using legacy Bitcoin address as a freeform 20-byte field. Because the address is used for data, it doesn't correspond to a private key and the resulting UTXO can _never_ be spent; it's a fake payment. These transactions that can never be spent are therefore never removed @@ -789,10 +776,10 @@ Let's explain that with the following example. However: -* Alice can create another transaction, double-spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed. +* Alice can create a conflicting transaction, spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed. * Bob has no guarantee that Alice won't do that. -It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. To guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify. +It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. One way to guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify. ==== Check Lock Time Verify (OP_CLTV) @@ -804,7 +791,7 @@ timelock was introduced to Bitcoin as a soft fork upgrade. Based on a specification in BIP65, a new script operator called _OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language. +OP_CLTV+ is a per-output timelock, rather than a per-transaction timelock -as is the case with lock time. This allows for much greater +as is the case with lock time. This allows for additional flexibility in the way timelocks are applied. In simple terms, by committing to the +OP_CLTV+ opcode in an @@ -823,25 +810,24 @@ results in TRUE, execution continues. In order to use +OP_CLTV+, you insert it into the redeem script of the output in the transaction that creates the output. For -example, if Alice is paying Bob's address, the output would normally -contain a P2PKH script like this: +example, if Alice is paying Bob, he might usually accept payment to +the following P2SH script: ---- -OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG + OP_CHECKSIG ---- -To lock it to a time, say 3 months from now, the transaction would be a -P2SH transaction with a redeem script like this: +To lock it to a time, say 3 months from now, his P2SH script would +instead be: ---- - OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG + OP_CHECKSIGVERIFY OP_CHECKLOCKTIMEVERIFYG ---- where ++ is a block height or time value estimated 3 months from the time the transaction is mined: current block height {plus} 12,960 (blocks) or current Unix epoch time {plus} 7,760,000 -(seconds). For now, don't worry about the +OP_DROP+ opcode that follows -+OP_CHECKLOCKTIMEVERIFY+; it will be explained shortly. +(seconds). When Bob tries to spend this UTXO, he constructs a transaction that references the UTXO as an input. He uses his signature and public key in @@ -855,8 +841,8 @@ lock time, script execution continues (acts as if a _no operation_ or OP_NOP opcode was executed). Otherwise, script execution halts and the transaction is deemed invalid. -More precisely, +OP_CHECKLOCKTIMEVERIFY+ fails and halts execution, marking -the transaction invalid if (source: BIP65): +More precisely, BIP65 explains that +OP_CHECKLOCKTIMEVERIFY+ fails and +halts execution if: 1. the stack is empty; or 2. the top item on the stack is less than 0; or @@ -875,7 +861,7 @@ that of +OP_CLTV+ in the outputs--they must both reference either block height or time in seconds. The above implies that a script can never be valid if it must execute -two different calls to +OP_CLTV+, one which uses a height and one which +two different calls to +OP_CLTV+, one that uses a height and one that uses a time. It can be easy to make this mistake when writing advanced scripts, so be sure to thoroughly test your scripts on a test network or use a tool designed to prevent this issue, like a Miniscript compiler. @@ -1001,12 +987,12 @@ various programming languages that use the construct +IF...THEN...ELSE+. Bitcoin conditional clauses look a bit different, but are essentially the same construct. -At a basic level, bitcoin conditional opcodes allow us to construct a +At a basic level, Bitcoin conditional opcodes allow us to construct a script that has two ways of being unlocked, depending on a +TRUE+/+FALSE+ outcome of evaluating a logical condition. For example, if x is +TRUE+, the executed code path is A and the ELSE code path is B. -Additionally, bitcoin conditional expressions can be "nested" +Additionally, Bitcoin conditional expressions can be "nested" indefinitely, meaning that a conditional clause can contain another within it, which contains another, etc. Bitcoin Script flow control can be used to construct very complex scripts with hundreds @@ -1018,7 +1004,7 @@ Bitcoin implements flow control using the +OP_IF+, +OP_ELSE+, +OP_ENDIF+, and +OP_NOTIF+ opcodes. Additionally, conditional expressions can contain boolean operators such as +OP_BOOLAND+, +OP_BOOLOR+, and +OP_NOT+. -At first glance, you may find the bitcoin's flow control scripts +At first glance, you may find the Bitcoin's flow control scripts confusing. That is because Bitcoin Script is a stack language. The same way that +1 {plus} 1+ looks "backward" when expressed as +1 1 OP_ADD+, flow control clauses in bitcoin also look "backward." @@ -1201,17 +1187,12 @@ startref="flow07")))((("", startref="condition07"))) script example", id="Scomplex07")))In this section we combine many of the concepts from this chapter into a single example. -((("use cases", "import/export", id="mohamseventwo")))Our example uses -the story of Mohammed, the company owner in Dubai who is operating an -import/export business. - -((("transactions", "advanced", "multisignature -scripts")))((("scripting", "multisignature scripts", "import/export -example")))((("multisignature scripts")))In this example, Mohammed +Mohammed is company owner in Dubai who is operating an import/export +business; he wishes to construct a company capital account with flexible rules. The scheme he creates requires different levels of authorization depending on timelocks. The participants in the multisig scheme are Mohammed, his -two partners Saeed and Zaira, and their company lawyer Abdul. The three +two partners Saeed and Zaira, and their company lawyer. The three partners make decisions based on a majority rule, so two of the three must agree. However, in the case of a problem with their keys, they want their lawyer to be able to recover the funds with one of the three @@ -1232,13 +1213,13 @@ number prefixed as XX): 03 2 04 OP_ELSE 05 <30 days> OP_CHECKSEQUENCEVERIFY OP_DROP -06 OP_CHECKSIGVERIFY +06 OP_CHECKSIGVERIFY 07 1 08 OP_ENDIF 09 3 OP_CHECKMULTISIG 10 OP_ELSE 11 <90 days> OP_CHECKSEQUENCEVERIFY OP_DROP -12 OP_CHECKSIG +12 OP_CHECKSIG 13 OP_ENDIF ---- ==== @@ -1269,14 +1250,14 @@ described in <>. The second execution path can only be used after 30 days have elapsed from the creation of the UTXO. At that time, it requires the signature -of Abdul the lawyer and one of the three partners (a 1-of-3 multisig). +of the lawyer and one of the three partners (a 1-of-3 multisig). This is achieved by line 7, which sets the quorum for the multisig to +1+. To select this execution path, the input script would end in +OP_FALSE OP_TRUE+: .Spending data for the second execution path (Lawyer + 1-of-3) ---- -OP_0 OP_FALSE OP_TRUE +OP_0 OP_FALSE OP_TRUE ---- [TIP] @@ -1286,13 +1267,13 @@ stack and +TRUE+ is pushed on top of it. +TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode. ==== -Finally, the third execution path allows Abdul the lawyer to spend the +Finally, the third execution path allows the lawyer to spend the funds alone, but only after 90 days. To select this execution path, the input script has to end in +OP_FALSE+: .Input script for the third execution path (Lawyer only) ---- - OP_FALSE + OP_FALSE ---- Try running the script on paper to see how it behaves on the stack. @@ -1345,9 +1326,9 @@ would have to include a signature within the transaction input: ---- [...] "vin" : [ -"txid": "abcdef12345...", -"vout": 0, - "scriptSig": “”, + "txid": "abcdef12345...", + "vout": 0, + "scriptSig": “”, ] [...] ---- @@ -1360,9 +1341,9 @@ input script and includes a witness structure: ---- [...] "vin" : [ -"txid": "abcdef12345...", -"vout": 0, - "scriptSig": “”, + "txid": "abcdef12345...", + "vout": 0, + "scriptSig": “”, ] [...] “witness”: “” @@ -1372,9 +1353,9 @@ input script and includes a witness structure: ===== Wallet construction of P2WPKH It is extremely important to note that P2WPKH witness programs should only be created by -the payee (recipient) and not converted by the sender from a known -public key, P2PKH script, or address. The sender has no way of knowing -if the recipient's wallet has the ability to construct segwit +the receiver and not converted by the spender from a known +public key, P2PKH script, or address. The spender has no way of knowing +if the receiver's wallet has the ability to construct segwit transactions and spend P2WPKH outputs. Additionally, P2WPKH outputs must be constructed from the hash of a @@ -1387,7 +1368,7 @@ private key. [WARNING] ==== -P2WPKH should be constructed by the recipient by converting a compressed +P2WPKH should be constructed by the receiver by converting a compressed public key to a P2WPKH hash. Neither the spender nor anyone else should ever transform a P2PKH script, Bitcoin address, or uncompressed public key to a P2WPKH witness script. In general, a spender should only send @@ -1418,9 +1399,9 @@ satisfy that redeem script, all inside the transaction input: ---- [...] "vin" : [ -"txid": "abcdef12345...", -"vout": 0, - "scriptSig": “ <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>”, + "txid": "abcdef12345...", + "vout": 0, + "scriptSig": “ <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>”, ] ---- @@ -1462,9 +1443,9 @@ the legacy input script field. ---- [...] "vin" : [ -"txid": "abcdef12345...", -"vout": 0, - "scriptSig": “”, + "txid": "abcdef12345...", + "vout": 0, + "scriptSig": “”, ] [...] “witness”: “ <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>” @@ -1507,10 +1488,10 @@ Legacy P2PKH and P2SH continue to work for nonupgraded wallets. That leaves two important scenarios, which are addressed in the next section: -- Ability of a sender's wallet that is not segwit-aware to make a +- Ability of a spender's wallet that is not segwit-aware to make a payment to a recipient's wallet that can process segwit transactions. -- Ability of a sender's wallet that is segwit-aware to recognize and +- Ability of a spender's wallet that is segwit-aware to recognize and distinguish between recipients that are segwit-aware and ones that are not, by their _addresses_. @@ -1523,8 +1504,8 @@ likely want to use segwit to reduce transaction fees, taking advantage of the reduced cost of witness structure. In this case Bob's wallet can construct a P2SH address that contains a -segwit script inside it. Alice's wallet sees this as a "normal" P2SH -address and can make payments to it without any knowledge of segwit. +segwit script inside it. Alice's wallet can make payments to it without +any knowledge of segwit. Bob's wallet can then spend this payment with a segwit transaction, taking advantage of segwit and reducing transaction fees. @@ -1697,7 +1678,7 @@ included in the authorization data); we could also have four commitments for the same cost. An extra commitment would give us up to eight conditions. With just 16 commitments--512 bytes of commitments--we could have over 32,000 authorization conditions, far more than could be effectively -used in an entire block of +OP_IF+ statements. With 128 commitments +used in an entire block of transactions filled with +OP_IF+ statements. With 128 commitments (4,096 bytes), the number of conditions we could create in theory far exceeds the number of conditions that all the computers in the world could create. @@ -1857,7 +1838,7 @@ leaked. There are two downsides of scriptless multisignatures. The first is that all known secure algorithms for creating them for Bitcoin require more -rounds of interaction or more careful management of state (or both) than +rounds of interaction or more careful management of state than scripted multisignature. This can be challenging in cases where signatures are being generated by nearly stateless hardware signing devices and the keys are physically distributed. For example, if you @@ -1943,10 +1924,10 @@ may appear because any transaction created by a single user who wants it to be satisfied by a single signature (or a multisignature generated by multiple different wallets they control) looks identical onchain to a mutual-satisfaction spend. There's no onchain difference in this case -between a spend by million users involved in an extraordinarily complex +between a spend by a million users involved in an extraordinarily complex contract or a single user just spending their saved bitcoins. -When spending is possible using just the key, such for a single signature +When spending is possible using just the key, such as for a single signature or scriptless multisignature, that is called _keypath spending_. When the tree of scripts is used, that is called _scriptpath spending_. For keypath spending, the data that gets put onchain is the public key @@ -1962,7 +1943,7 @@ in this context. The witness structure includes the following information: merkle root to produce the taproot output key. This underlying key is called the _taproot internal key_ -3. The leaf script to execute +3. The script to execute, called the _leaf script_ 4. One 32-byte hash for each junction in merkle tree along the path that connects the leaf to the merkle root @@ -2016,7 +1997,8 @@ Additionally, any signature-checking operation which is not expected OP_SUCCESSx opcodes:: Opcodes in previous versions of script which were unusable are now redefined to cause an entire script to succeed if they are used. - This allows future soft forks to redefine them as not succeeding, which + This allows future soft forks to redefine them as not succeeding under + certain circumstances, which is a restriction and so is possible to do in a soft fork. (The opposite, to define a not-succeeding operation as a success can only be done in a hard fork, which is a much more challenging upgrade diff --git a/bips.adoc b/bips.adoc index 64702f42..949e2044 100644 --- a/bips.adoc +++ b/bips.adoc @@ -2,18 +2,18 @@ [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", "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. As per BIP1 _BIP Purpose and Guidelines_, there are three kinds of BIPs: -_Standard_ BIP:: Describes any change that affects most or all bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using bitcoin. -_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. +_Standard_ BIP:: Describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. +_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]. An MIT-licensed document from the open source Bitcoin Core project, reproduced here in edited form, describes which BIPs it implements, including listing -the version of Bitcoin Core where support for each BIP was added or +the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or significantly changed. BIPs that are implemented by Bitcoin Core: diff --git a/bitcoin-core.adoc b/bitcoin-core.adoc index d557c251..85399d4a 100644 --- a/bitcoin-core.adoc +++ b/bitcoin-core.adoc @@ -9,7 +9,7 @@ verify the integrity of the bitcoins they receive. The Bitcoin system was designed so that it's possible for software running entirely on your local computer to perfectly prevent counterfeiting, debasement, and several other critical problems. Software which provides that function -is called a full verification node because it verifies every confirmed +is called a _full verification node_ because it verifies every confirmed Bitcoin transaction against every rule in the system. Full verification nodes, _full nodes_ for short, may also provide tools and data for understanding how Bitcoin works and what is currently happening in the @@ -306,8 +306,7 @@ fixes the error. executables")))((("core executables", seealso="Bitcoin Core")))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. -During the compilation process you should see output every few seconds -or every few minutes, or an error if something goes wrong. If an error +If an error occurs, or the compilation process is interrupted, it can be resumed any time by typing +make+ again. Type +make+ to start compiling the executable application: @@ -650,10 +649,10 @@ afterward continues to download the full blocks, validating them as it goes. Once you are happy with the configuration options you have selected, you -should add bitcoin to the startup scripts in your operating system, so +should add Bitcoin Core to the startup scripts in your operating system, so that it runs continuously and restarts when the operating system restarts. You will find a number of example startup scripts for various -operating systems in bitcoin's source directory under _contrib/init_ and +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"))) @@ -1025,9 +1024,7 @@ any higher level Bitcoin Core RPC wrappers), as seen in <>. $ cat .bitcoin/.cookie __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 -$ curl \ - --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0\ - --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/ +$ curl --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/ {"result":{"chain":"main","blocks":799278,"headers":799278,"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879","difficulty":53911173001054.59,"time":1689703111,"mediantime":1689701260,"verificationprogress":0.9999979206082515,"initialblockdownload":false,"chainwork":"00000000000000000000000000000000000000004f3e111bf32bcb47f9dfad5b","size_on_disk":563894577967,"pruned":false,"warnings":""},"error":null,"id":"curltest"} ---- diff --git a/blockchain.adoc b/blockchain.adoc index 86b4726c..11b8ae95 100644 --- a/blockchain.adoc +++ b/blockchain.adoc @@ -46,7 +46,7 @@ following it, it cannot be changed without forcing a recalculation of all subsequent blocks. Because such a recalculation would require enormous computation (and therefore energy consumption), the existence of a long chain of blocks makes the blockchain's deep history impractical to change, -which is a key feature of bitcoin's security. +which is a key feature of Bitcoin's security. One way to think about the blockchain is like layers in a geological formation, or glacier core sample. The surface layers might change with @@ -72,7 +72,7 @@ infinitesimal. ((("blocks", "structure of")))((("blockchain (the)", "block structure")))A block is a container data structure that aggregates -transactions for inclusion in the public ledger, the blockchain. The +transactions for inclusion in the blockchain. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The block header is 80 bytes, whereas the total size of all transactions in a block can be @@ -88,7 +88,7 @@ header. <> describes how Bitcoin Core stores the structure of |Size| Field | Description | 4 bytes | Block Size | The size of the block, in bytes, following this field | 80 bytes | Block Header | Several fields form the block header -| 1-9 bytes (compactSize) | Transaction Counter | How many transactions follow +| 1-3 bytes (compactSize) | Transaction Counter | How many transactions follow | Variable | Transactions | The transactions recorded in this block |======= @@ -120,20 +120,19 @@ process and will be discussed in more detail in <>. ((("blockchain (the)", "block identifiers")))((("blocks", "block height")))((("blocks", "block hash")))The primary identifier of a block -is its cryptographic hash, a digital fingerprint, made by hashing the +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 hash_, pass:[because only the block header is used to compute it. For example,] +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is -the block hash of the first block on Bitcoin's block chain. The block hash +the block hash of the first block on Bitcoin's blockchain. The block hash identifies a block uniquely and unambiguously and can be independently derived by any node by simply hashing the block header. Note that the block hash is not actually included inside the block's -data structure, neither when the block is transmitted on the network, -nor when it is stored on a node's persistent storage as part of the -blockchain. Instead, the block's hash is computed by each node as the +data structure. +Instead, the block's hash is computed by each node as the block is received from the network. The block hash might be stored in a separate database table as part of the block's metadata, to facilitate indexing and faster retrieval of blocks from disk. @@ -202,7 +201,7 @@ The following identifier hash belongs to the genesis block: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f ---- -You can search for that block hash in any block explorer website, such +You can search for that block hash in almost any block explorer website, such as _blockstream.info_, and you will find a page describing the contents of this block, with a URL containing that hash: @@ -327,7 +326,7 @@ transactions and permitting a very efficient process to verify whether a transaction is included in a block. A merkle tree is constructed by recursively hashing pairs of elements until there is only one hash, called the _root_, or _merkle root_. The cryptographic hash algorithm used in -bitcoin's merkle trees is SHA256 applied twice, also known as +Bitcoin's merkle trees is SHA256 applied twice, also known as double-SHA256. When N data elements are hashed and summarized in a merkle tree, you can diff --git a/errata.adoc b/errata.adoc index 2a259244..b33a07ff 100644 --- a/errata.adoc +++ b/errata.adoc @@ -14,8 +14,8 @@ sections in Nakamoto's original paper. === Abstract ____ -The longest chain not only serves as proof of the sequence of events -witnessed, but proof that it came from the largest pool of CPU power. +"The longest chain not only serves as proof of the sequence of events +witnessed, but proof that it came from the largest pool of CPU power." ____ * *Implementation detail:* If each link in the chain (called "blocks" @@ -44,9 +44,9 @@ instead of saying "CPU power" it is perhaps more correct to say in generating the POW. ____ -As long as a majority of CPU power is controlled by nodes that are not +"As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain -and outpace attackers. +and outpace attackers." ____ * *Terminology change:* The term "nodes" today is used to refer to @@ -84,10 +84,10 @@ than about 30% of the network". === Transactions ____ -We define an electronic coin as a chain of digital signatures. Each +"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding -these to the end of the coin. +these to the end of the coin." ____ * *Implementation detail:* Bitcoin implements a more general version of @@ -107,9 +107,9 @@ chain-like; it’s more accurately described as a directed acyclic graph === Proof-of-Work ____ -we implement the proof-of-work by incrementing a nonce in the block +"we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero -bits. +bits." ____ * *Implementation detail:* Adam Back’s Hashcash implementation requires @@ -119,7 +119,7 @@ specified integer, which effectively allows a fractional number of bits to be specified. ____ -Proof-of-work is essentially one-CPU-one-vote. +"Proof-of-work is essentially one-CPU-one-vote." ____ * *Important note:* the vote here is not on the rules of the system but @@ -135,8 +135,8 @@ transaction as payment, and honest nodes will never accept a block containing them." ____ -proof-of-work difficulty is determined by a moving average targeting an -average number of blocks per hour. +"proof-of-work difficulty is determined by a moving average targeting an +average number of blocks per hour." ____ * *Implementation detail:* A moving average is not used. Instead, every @@ -153,8 +153,8 @@ that the adjustment can not increase block production speed by more than === Reclaiming Disk Space ____ -Once the latest transaction in a coin is buried under enough blocks, the -spent transactions before it can be discarded to save disk space +"Once the latest transaction in a coin is buried under enough blocks, the +spent transactions before it can be discarded to save disk space" ____ * *Possible post-publication discovery:* Although the Merkle Tree @@ -168,10 +168,10 @@ nodes will need to process all transactions. === Simplified Payment Verification ____ -One strategy to protect against this would be to accept alerts from +"One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm -the inconsistency. +the inconsistency." ____ * *Important Note:* although software has been produced that implements @@ -184,8 +184,8 @@ the past. === Privacy ____ -Some linking is still unavoidable with multi-input transactions, which -necessarily reveal that their inputs were owned by the same owner +"Some linking is still unavoidable with multi-input transactions, which +necessarily reveal that their inputs were owned by the same owner" ____ * *Post-publication invention:* it isn't clear that different inputs @@ -203,11 +203,11 @@ it has been in use since 2015. === Calculations ____ -The receiver generates a new key pair and gives the public key to the +"The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at -that moment. +that moment." ____ * *Post-publication discovery:* nothing about the receiver generating a diff --git a/fees.adoc b/fees.adoc index f0472f0f..218f26f6 100644 --- a/fees.adoc +++ b/fees.adoc @@ -13,9 +13,9 @@ use to determine which keys control which bitcoins. To protect himself against conflicting transactions, it would be wise for Bob to wait until the transaction from Alice is included in the -blockchain before he considers the money he received as his to spend. -He may want to wait even longer than that, as we discussed in -<>. For Alice's transaction to be included in the +blockchain to a sufficient depth before he considers the money he +received as his to spend (see <>). +For Alice's transaction to be included in the blockchain, it must be included in a _block_ of transactions. There are a limited number of blocks produced in a given amount of time and each block only has a limited amount of space. Only the miner who creates @@ -92,7 +92,7 @@ Bitcoin for spenders to pay transaction fees. There are exceptions, such as for merchants which accept unconfirmed transactions and in protocols that don't immediately broadcast transactions after they are signed (preventing the spender from being able to choose an appropriate -fee for the current market). +fee for the current market). We'll explore those exceptions later. === Fees and fee rates @@ -123,7 +123,7 @@ fee rates. [WARNING] ==== -Be careful accepting input for fee rates. If a user copy and pastes a +Be careful accepting input for fee rates. If a user copies and pastes a fee rate printed in one denominator into a field using a different enumerator, they could overpay fees by 1,000 times. If they instead switch the enumerator, they could theoretically overpay by 100,000,000 @@ -196,7 +196,7 @@ bumping in Bitcoin, Replace-By-Fee (RBF) and Child Pays For Parent To increase the fee of a transaction using RBF fee bumping, you create a conflicting version of the transaction which pays a higher fee. Two or more transactions are considered to be _conflicting transactions_ if -only one of them can be included in a valid block chain, forcing a miner +only one of them can be included in a valid blockchain, forcing a miner to chose only one of them. Conflicts occur when two or more transactions each try to spend one of the same UTXOs, i.e. they each include an input that has the same outpoint (reference to the output of a previous @@ -292,9 +292,16 @@ having "Sending support" on https://bitcoinops.org/en/compatibility/#replace-by-fee-rbf As a developer, if you plan to implement RBF fee bumping, you will first -need to implement the signaling specified in BIP125, which is a simple +need to decided whether to perform opt-in RBF or full RBF. At the time +of writing, opt-in RBF is the only method that's sure to work. Even if +full RBF becomes reliable, there will likely be several years where +replacements of opt-in transactions get confirmed slightly faster than +full-RBF replacements. If you choose opt-in RBF, your wallet will need +to implement the signaling specified in BIP125, which is a simple modification to any one of the sequence fields in a transaction (see -<>). +<>). If you choose full RBF, you don't need to include any +signaling in your transactions. Everything else related to RBF is the +same for both approaches. When you need to fee bump a transaction, you will simply create a new transaction that spends at least one of the same UTXOs as the original @@ -361,7 +368,7 @@ transaction is called a _child transaction_. As we learned in <>, every input in a confirmed transaction must reference the unspent output of a transaction which appears earlier -in the block chain (whether earlier in the same block or in a previous +in the blockchain (whether earlier in the same block or in a previous block). That means a miner who wants to confirm a child transaction must also ensure that its parent transaction is confirmed. If the parent transaction hasn't been confirmed yet but the child transaction @@ -453,12 +460,12 @@ is that they can sometimes prevent someone from being able to use fee bumping. Making it impossible or difficult to fee bump a transaction is called _transaction pinning_. -One of the major denial of service concerns revolve around the effect of +One of the major denial of service concerns revolve's around the effect of transaction relationships. Whenever the output of a transaction is spent, that transaction's identifier (txid) is referenced by the child transaction. However, when a transaction is replaced, the replacement has a different txid. If that replacement transaction gets confirmed, -none of its descendants can be included in the same block chain. It's +none of its descendants can be included in the same blockchain. It's possible to recreate and re-sign the descendant transactions, but that's not guaranteed to happen. This has related but divergent implications for RBF and CPFP: @@ -497,7 +504,7 @@ Additionally, a transaction and all of its descendants is not that transaction is mined--none of those transactions can now be confirmed unless there's a rare blockchain reorganization. Bitcoin Core will remove from its mempool every transaction that can no longer - be confirmed on the current block chain. At it's worst, that can + be confirmed on the current blockchain. At it's worst, that can waste an enormous amount of your node's bandwidth and possibly be used to prevent transactions from propagating correctly. + diff --git a/glossary.asciidoc b/glossary.asciidoc index f608a99b..a9645a45 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -15,7 +15,7 @@ bitcoin:: The name of the currency unit (the coin), the network, and the software. block:: - A grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus. + A grouping of transactions, marked with a timestamp, and a commitment to the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus. blockchain:: A list of validated blocks, each linking to its predecessor all the way to the genesis block. @@ -41,7 +41,7 @@ confirmations:: Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed. consensus:: - When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best block chain. + When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best blockchain. Not to be confused with consensus rules. consensus rules:: @@ -58,7 +58,7 @@ difficulty target:: A difficulty at which all the computation in the network will find blocks approximately every 10 minutes. double-spending:: - Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent. + Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the blockchain to ensure that the inputs for the transaction had not previously already been spent. ECDSA:: Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners. @@ -70,7 +70,7 @@ fees:: The sender of a transaction often includes a fee to the network for processing the requested transaction. Most transactions require a minimum fee of 0.5 mBTC. fork:: - Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack. + Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the blockchain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack. genesis block:: The first block in the blockchain, used to initialize the cryptocurrency. @@ -82,8 +82,9 @@ hard fork:: hardware wallet:: A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device. +//FIXME: needs improvement hash:: - A digital fingerprint of some binary input. + A digital commitment to some binary input. hashlocks:: A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time. @@ -110,7 +111,7 @@ Lightning Networks:: Lightning Network is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other. Lock time:: - Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain. + Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain. mempool:: The bitcoin Mempool (memory pool) is a collection of all transaction data in a block that have been verified by Bitcoin nodes, but are not yet confirmed. @@ -133,15 +134,12 @@ network:: nonce:: The "nonce" in a bitcoin block is a 32-bit (4-byte) field whose value is set so that the hash of the block will contain a run of leading zeros. The rest of the fields may not be changed, as they have a defined meaning. -off-chain transactions:: - An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. +offchain transactions:: + An offchain transaction is the movement of value outside of the blockchain. While an onchain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an offchain transaction relies on other methods to record and validate the transaction. opcode:: Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script. -Open Assets protocol:: - The Open Assets Protocol is a simple and powerful protocol built on top of the Bitcoin blockchain. It allows issuance and transfer of user-created assets. The Open Assets protocol is an evolution of the concept of colored coins. - OP_RETURN:: An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction. @@ -176,7 +174,7 @@ paper wallet:: In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes. payment channels:: - A micropayment channel or payment channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants. + A micropayment channel or payment channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the blockchain but an unlimited or nearly unlimited number of payments can be made between the participants. pooled mining:: Pooled mining is a mining approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. @@ -229,7 +227,7 @@ soft fork:: Not to be confused with fork, hard fork, software fork or Git fork. stale block:: - Block that was successfully mined but that isn’t included on the current best block chain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block. + Block that was successfully mined but that isn’t included on the current best blockchain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block. timelocks:: A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts. diff --git a/intro.adoc b/intro.adoc index 13ff8115..fcaf571f 100644 --- a/intro.adoc +++ b/intro.adoc @@ -36,7 +36,7 @@ transactions. Any participant in the Bitcoin network may operate as a miner, using their computing devices to help secure transactions. Every 10 minutes, on average, one Bitcoin miner can add security to past transactions and is rewarded with both brand new -bitcoin and the fees paid by recent transactions. Essentially, Bitcoin +bitcoins and the fees paid by recent transactions. Essentially, Bitcoin mining decentralizes the currency-issuance and clearing functions of a central bank and replaces the need for any central bank. @@ -54,14 +54,14 @@ mining function across the network. The difficulty of the computational task that miners must perform is adjusted dynamically so that, on average, someone succeeds every 10 minutes regardless of how many miners (and how much processing) are competing at any moment. The protocol also -periodically decreases the number of new bitcoins are created, -limiting the total number of bitcoins that will be created to a fixed total +periodically decreases the number of new bitcoins that are created, +limiting the total number of bitcoins that will ever be created to a fixed total just below 21 million coins. The result is that the number of bitcoins in circulation closely follows an easily predictable curve where half of the remaining coins are added to circulation every four years. At approximately block 1,411,200, which is expected to be produced around the year 2035, 99% of all bitcoins -that will ever exist will have been issued. Due to bitcoin's +that will ever exist will have been issued. Due to Bitcoin's diminishing rate of issuance, over the long term, the Bitcoin currency is deflationary. Furthermore, nobody can force you to accept any bitcoins that were created beyond the @@ -70,7 +70,7 @@ expected issuance rate. Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer network, and a distributed computing innovation. Bitcoin builds on decades of research in cryptography and distributed systems and includes at least four key innovations brought together in a unique and powerful combination. Bitcoin consists of: * A decentralized peer-to-peer network (the Bitcoin protocol) -* A public transaction ledger (the blockchain) +* 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 mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm) @@ -164,7 +164,6 @@ derived from the original implementation written by Satoshi Nakamoto. ((("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. -[role="pagebreak-before"] ===== Types of Bitcoin wallets Bitcoin wallets can be categorized as follows, according to the platform: @@ -203,7 +202,7 @@ role in how much security and privacy the user obtains when using the 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: +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 entire history of Bitcoin transactions (every transaction by every user, @@ -247,8 +246,8 @@ A very important additional consideration is _who controls the keys_. As we will see in subsequent chapters, access to bitcoins is controlled by "private keys", which are like very long PIN numbers. If you are the only one to have *control* over these private -keys, you are in control of your bitcoin. Conversely, if you do not have -control, then your bitcoin is managed by a third-party who +keys, you are in control of your bitcoins. Conversely, if you do not have +control, then your bitcoins are managed by a third-party who ultimately controls your funds on your behalf. Key management software falls into two important categories based on control: _wallets_, where you control the keys, and the funds and accounts with custodians where some @@ -264,16 +263,6 @@ accounts with third parties (you don't control the keys). The lines between diff are sometimes blurry, as software runs on multiple platforms and can interact with the network in different ways. -For the purposes of this book, we will be demonstrating the use of a -variety of downloadable Bitcoin software, from the reference -implementation (Bitcoin Core) to mobile and web software. Some of the -examples will require the use of Bitcoin Core, which, in addition to -being a full node, also exposes APIs to the wallet, network, and -transaction services. If you are planning to explore the programmatic -interfaces into the Bitcoin system, you will need to run Bitcoin Core, -or one of the alternative full node implementations.((("", startref="GSwallet01")))((("", -startref="Wselect01"))) - ==== Quick Start ((("getting started", "quick start example", @@ -374,19 +363,19 @@ 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. ((("", 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. [TIP] ==== ((("addresses", "security of")))((("security", "bitcoin addresses")))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 bitcoin directly to your wallet. You can share +invoices can be shared with other Bitcoin users +who can use them to send bitcoins directly to your wallet. You can share an address or invoice with other people without worrying about the security of your bitcoins. Unlike a bank account number, nobody who learns one of your Bitcoin addresses can withdraw money from your wallet--you must initiate all spends. However, if you give two people the same -address, they will be able to see how much bitcoin the other person sent +address, they will be able to see how many bitcoins the other person sent you. If you post your address publicly, everyone will be able to see how much bitcoin other people sent to that address. To protect your privacy, you should generate a new invoice with a new address each time you request a @@ -420,10 +409,10 @@ Bitcoin transactions are irreversible. Most electronic payment networks such as [role="pagebreak-before"] Here are some methods for acquiring bitcoin as a new user: -* Find a friend who has bitcoin 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 bitcoin 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 bitcoin. -* ((("Coin ATM Radar")))((("ATMs, locating")))Use a bitcoin ATM in your city. A bitcoin ATM is a machine that accepts cash and sends bitcoin 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 bitcoin with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of bitcoin exchanges for each currency. +* 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. [TIP] ==== @@ -439,26 +428,27 @@ touches traditional systems, such as currency exchanges, national and international regulations often apply. In order to exchange bitcoin for your national currency, you will often be required to provide proof of identity and banking information. Users should be aware that once a -Bitcoin address is attached to an identity, other associated bitcoin +Bitcoin address is attached to an identity, other associated Bitcoin transactions may also become easy to identify and track--including transactions made earlier. This is one reason many users choose to maintain dedicated exchange accounts independent from their wallets. ==== -Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoin. Next, we will look at how she buys bitcoin from her friend Joe and how Joe sends the bitcoin to her wallet. +Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her wallet. [[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 bitcoin price?" The short answer is that the price is set by markets. +((("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 +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 bitcoin 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). +((("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). 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://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoin. +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. In addition to these various sites and applications, some bitcoin @@ -471,7 +461,7 @@ currencies. ((("getting started", "sending and receiving bitcoin", id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start example")))((("spending bitcoin", see="also transactions")))Alice has -decided to buy 0.001 bitcoin. After she and Joe check the exchange rate, +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 displays a QR code with Alice's first Bitcoin address. @@ -479,7 +469,7 @@ displays a QR code with Alice's first Bitcoin address. Joe then selects Send on his smartphone wallet and opens the QR code scanner. This allows Joe to scan the barcode with his smartphone camera so that he doesn't have to type in Alice's Bitcoin address, which is -quite long and difficult to type. +quite long. Joe now has Alice's Bitcoin address set as the recipient. Joe enters the amount as 0.001 bitcoins (BTC), see <>. Some wallets may @@ -521,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 ledger, 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 <>. +((("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 <>. **** -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.((("", startref="BCbasic01"))) diff --git a/keys.adoc b/keys.adoc index 63c723e0..50c683a3 100644 --- a/keys.adoc +++ b/keys.adoc @@ -44,7 +44,7 @@ of unforgeable digital signatures. Bitcoin uses elliptic curve addition and multiplication as the basis for its cryptography. In Bitcoin, we can use public key cryptography to create a key pair that -controls access to bitcoin. The key pair consists of a private key +controls access to bitcoins. The key pair consists of a private key and a public key derived from the private key. The public key is used to receive funds, and the private key is used to sign transactions to spend the funds. @@ -75,13 +75,13 @@ generate a public key (K). **** ((("cryptography", "asymmetric")))((("digital signatures", "asymmetric cryptography and")))((("asymmetric cryptography")))Why is asymmetric -cryptography used in bitcoin? It's not used to "encrypt" (make secret) -the transactions. Rather, the useful property of asymmetric cryptography +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 -applied to the digital fingerprint of a transaction to produce a +applied to a transaction to produce a numerical signature. This signature can only be produced by someone with knowledge of the private key. However, anyone with access to the public -key and the transaction fingerprint can use them to _verify_ the +key and the transaction can use them to _verify_ the signature. This useful property of asymmetric cryptography makes it possible for anyone to verify every signature on every transaction, while ensuring that only the owners of private keys can produce valid @@ -96,7 +96,7 @@ generation")))((("warnings and cautions", "private key protection")))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 -used to create signatures that are used to spend bitcoin by proving +used to create signatures that are used to spend bitcoins by proving control of funds used in a transaction. The private key must remain secret at all times, because revealing it to third parties is equivalent to giving them control over the bitcoins secured by that key. The private @@ -106,7 +106,7 @@ forever lost, too. [TIP] ==== -A bitcoin private key is just a number. You can pick your private keys +A Bitcoin private key is just a number. You can pick your private keys randomly using just a coin, pencil, and paper: toss a coin 256 times and you have the binary digits of a random private key you can use in a Bitcoin wallet. The public key can then be generated from the private @@ -156,7 +156,7 @@ bits): [TIP] ==== -The size of bitcoin's private key space, (2^256^) is an unfathomably +The size of Bitcoin's private key space, (2^256^) is an unfathomably large number. It is approximately 10^77^ in decimal. For comparison, the visible universe is estimated to contain 10^80^ atoms. ==== @@ -213,7 +213,7 @@ two dimensions, which makes it difficult to visualize. However, the math is identical to that of an elliptic curve over real numbers. As an example, <> shows the same elliptic curve over a much smaller finite field of prime order 17, showing a pattern of dots on a -grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much +grid. The +secp256k1+ Bitcoin elliptic curve can be thought of as a much more complex pattern of dots on a unfathomably large grid. [[ecc-over-F17-math]] @@ -499,8 +499,8 @@ This brings us back to the problem of receivers like Bob having to give spenders like Alice a long public key. The shortest version of Bitcoin public keys known to the developers of early Bitcoin were 65 bytes, the equivalent of 130 characters when written in hexadecimal. However, Bitcoin -already contained several data structures much larger than 65 bytes -which needed to be securely referenced in other parts of Bitcoin using the +already contains several data structures much larger than 65 bytes +that need to be securely referenced in other parts of Bitcoin using the smallest amount of data that was secure. Bitcoin accomplishes that with a _hash function_, a function which takes @@ -819,7 +819,7 @@ in later protocol upgrades. However, some software still needs to support uncompressed public keys, such as a wallet application importing private keys from an older -wallet. When the new wallet scans the block chain for old P2PKH outputs +wallet. When the new wallet scans the blockchain for old P2PKH outputs and inputs, it needs to know whether to scan the 65-byte keys (and commitments to those keys) or 33-byte keys (and their commitments). Failure to scan for the correct type can lead to the user not being able to @@ -928,7 +928,7 @@ All addresses based on hash functions are theoretically vulnerable to an attacker independently finding the same input that produced the hash function output (commitment). In the case of Bitcoin, if they find the input the same way the original user did, they'll know the user's private -key and be able to spend that user's bitcoin. The chance of an attacker +key and be able to spend that user's bitcoins. The chance of an attacker independently generating the input for an existing commitment is proportional to the strength of the hash algorithm. For a secure 160-bit algorithm like HASH160, the probability is 1-in-2^160^. This is @@ -1414,9 +1414,8 @@ For more information, see <>. [options="header"] |======= |Type|Prefix|Description -| Raw | None | 32 bytes | Hex | None | 64 hexadecimal digits -| WIF | 5 | Base58Check encoding: base58 with version prefix of 128- and 32-bit checksum +| WIF | 5 | Base58Check encoding: base58 with version prefix of 128 and 32-bit checksum | WIF-compressed | K or L | As above, with added suffix 0x01 before encoding |======= @@ -1434,9 +1433,7 @@ For more information, see <>. All of these representations are different ways of showing the same number, the same private key. They look different, but any one format -can easily be converted to any other format. Note that the "raw binary" -is not shown in <> as any encoding for display here would, by -definition, not be raw binary data. +can easily be converted to any other format. [[comp_priv]] ===== Compressed private keys @@ -1489,7 +1486,7 @@ prefix). The goal here is to signal to the wallet importing these private keys whether it must search the blockchain for compressed or uncompressed public keys and addresses. -If a bitcoin wallet is able to implement compressed public keys, it will +If a Bitcoin wallet is able to implement compressed public keys, it will use those in all transactions. The private keys in the wallet will be used to derive the public key points on the curve, which will be compressed. The compressed public keys will be used to produce Bitcoin @@ -1524,7 +1521,7 @@ checking to see if it matches the desired vanity pattern, repeating billions of times until a match is found. Once a vanity address matching the desired pattern is found, the private -key from which it was derived can be used by the owner to spend bitcoin +key from which it was derived can be used by the owner to spend bitcoins in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same Elliptic Curve Cryptography (ECC) and SHA as any other address. You can @@ -1533,7 +1530,7 @@ pattern than you can any other address. Eugenia is a children's charity director operating in the Philippines. Let's say that Eugenia is -organizing a bitcoin fundraising drive and wants to use a vanity Bitcoin +organizing a fundraising drive and wants to use a vanity Bitcoin address to publicize the fundraising. Eugenia will create a vanity address that starts with "1Kids" to promote the children's charity fundraiser. Let's see how this vanity address will be created and what @@ -1639,7 +1636,7 @@ the future unless the above problems are solved. ((("keys and addresses", "advanced forms", "paper wallets")))((("paper wallets", id="paperw04")))((("wallets", "types of", "paper wallets", -id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper. +id="Wpaper04")))Paper wallets are private keys printed on paper. Often the paper wallet also includes the corresponding Bitcoin address for convenience, but this is not necessary because it can be derived from the private key. @@ -1649,7 +1646,7 @@ from the private key. Paper wallets are an OBSOLETE technology and are dangerous for most users. There are many subtle pitfalls involved in generating them, not least of which the possibility that the generating code is compromised -with a "back door". Hundreds of bitcoin have been stolen this way. Paper +with a "back door". Many bitcoins have been stolen this way. Paper wallets are shown here for informational purposes only and should not be used for storing bitcoin. Use a recovery code to backup your keys, possibly with a hardware signing device to store keys and sign transactions. DO NOT diff --git a/meta/third_edition_changes.asciidoc b/meta/third_edition_changes.asciidoc index 9d417fc9..b60fb9cd 100644 --- a/meta/third_edition_changes.asciidoc +++ b/meta/third_edition_changes.asciidoc @@ -28,7 +28,7 @@ Chapter 8:: multisignatures, and threshold signatures. Chapter 9:: - Almost entirely new text about fees, fee market, RBF and CPFP fee + Almost entirely new text about fees, RBF and CPFP fee bumping, transaction pinning, package relay, and CPFP carve-out. Chapter 10:: diff --git a/mining.adoc b/mining.adoc index afa1debd..b1b5ec3b 100644 --- a/mining.adoc +++ b/mining.adoc @@ -3,10 +3,10 @@ ((("mining and consensus", "purpose of")))The word "mining" is somewhat misleading. By evoking the extraction of precious metals, it focuses our -attention on the reward for mining, the new bitcoin created in each +attention on the reward for mining, the new bitcoins created in each block. Although mining is incentivized by this reward, the primary -purpose of mining is not the reward or the generation of new coins. If -you view mining only as the process by which coins are created, you are +purpose of mining is not the reward or the generation of new bitcoins. If +you view mining only as the process by which bitcoins are created, you are mistaking the means (incentives) as the goal of the process. Mining is the mechanism that underpins the decentralized clearinghouse, by which transactions are validated and cleared. Mining is one of the inventions that @@ -16,7 +16,7 @@ basis for P2P digital cash. ((("mining and consensus", "decentralized consensus")))((("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 coins and +((("fees", "transaction fees")))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. @@ -28,17 +28,17 @@ Mining is one of the mechanisms by which Bitcoin's _consensus security_ is _decentralized_. ==== -Miners record new transactions on the global ledger. A +Miners record new transactions on the global blockchain. A new block, containing transactions that occurred since the last block, -is "mined" every 10 minutes on average, thereby adding those +is _mined_ every 10 minutes on average, thereby adding those transactions to the blockchain. Transactions that become part of a block -and added to the blockchain are considered "confirmed," which allows the -new owners of bitcoin to know that irrevocable effort was expended -securing the bitcoin they received in those +and added to the blockchain are considered _confirmed_, which allows the +new owners of the bitcoins to know that irrevocable effort was expended +securing the bitcoins they received in those transactions. Additionally, transactions in the blockchain have a _topological order_ -defined by their position in the block chain. One transaction is +defined by their position in the blockchain. One transaction is earlier than another if it appears in an earlier block or if it appears earlier in the same block. In the Bitcoin protocol, a transaction is only valid if it spends the outputs of transactions that appeared @@ -55,7 +55,7 @@ we'll discuss that idea further in <>. ((("fees", "mining rewards")))((("mining and consensus", "mining rewards and fees")))((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work algorithm")))Miners receive two types of rewards in -return for the security provided by mining: new coins created with each +return for the security provided by mining: new bitcoins created with each new block (called the _subsidy_), and transaction fees from all the transactions included in the block. To earn this reward, miners compete to satisfy a challenge based on a cryptographic hash algorithm. The @@ -71,23 +71,23 @@ amount of newly created bitcoin a miner can add to a block decreases approximately every four years (or precisely every 210,000 blocks). It started at 50 bitcoins per block in January of 2009 and halved to 25 bitcoins per block in November of 2012. It halved again to 12.5 bitcoins -in July 2016, and again to 6.25 in May 2020. Based on this formula, bitcoin mining rewards decrease -exponentially until approximately the year 2140, when all bitcoin +in July 2016, and again to 6.25 in May 2020. Based on this formula, mining rewards decrease +exponentially until approximately the year 2140, when all bitcoins will have been issued. After 2140, no new bitcoin will be issued. Bitcoin miners also earn fees from transactions. Every transaction may -include a transaction fee, in the form of a surplus of bitcoin between +include a transaction fee, in the form of a surplus of bitcoins between the transaction's inputs and outputs. The winning bitcoin miner gets to "keep the change" on the transactions included in the winning block. -Today, the fees usually represent only a small percentage of a bitcoin +Today, the fees usually represent only a small percentage of a miner's income, with the -vast majority coming from the newly minted bitcoin. However, as the +vast majority coming from the newly minted bitcoins. However, as the reward decreases over time and the number of transactions per block -increases, a greater proportion of bitcoin mining earnings will come +increases, a greater proportion of mining earnings will come from fees. Gradually, the mining reward will be dominated by transaction fees, which will form the primary incentive for miners. After 2140, the -amount of new bitcoin in each block drops to zero and bitcoin mining +amount of new bitcoins in each block drops to zero and mining will be incentivized only by transaction fees. In this chapter, we will first examine mining as a monetary supply @@ -104,24 +104,24 @@ consensus. ((("mining and consensus", "bitcoin economics and currency creation")))((("currency creation")))((("money supply")))((("issuance -rate")))Bitcoin are "minted" during the creation of each block at a +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 bitcoin, created from nothing. Every +minutes, contains entirely new bitcoins, created from nothing. Every 210,000 blocks, or approximately every four years, the currency issuance rate is decreased by 50%. For the first four years of operation of the -network, each block contained 50 new bitcoin. +network, each block contained 50 new bitcoins. The first halving occurred at block 210,000. The next expected halving after publication of this book will occur at block 840,000, which will probably be produced in April or May of 2024. -The rate of new coins decreases +The rate of new bitcoins decreases exponentially over 32 of these _halvings_ until block 6,720,000 (mined approximately in year 2137), when it reaches the minimum currency unit of 1 satoshi. Finally, after 6.93 million blocks, in approximately 2140, almost 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin, -will have been issued. Thereafter, blocks will contain no new bitcoin, and +will have been issued. Thereafter, blocks will contain no new bitcoins, and miners will be rewarded solely through the transaction fees. -<> shows the total bitcoin in circulation over +<> shows the total bitcoins in circulation over time, as the issuance of currency decreases. [[bitcoin_money_supply]] @@ -130,8 +130,8 @@ image::images/mbc2_1001.png["BitcoinMoneySupply"] [NOTE] ==== -The maximum number of coins mined is the _upper limit_ of possible -mining rewards for bitcoin. In practice, a miner may intentionally mine +The maximum number of bitcoinss mined is the _upper limit_ of possible +mining rewards for Bitcoin. In practice, a miner may intentionally mine a block taking less than the full reward. Such blocks have already been mined and more may be mined in the future, resulting in a lower total issuance of the currency. @@ -187,7 +187,7 @@ deflation is associated with a collapse in demand because that is the most obvious example of deflation we have to study. In a fiat currency with the possibility of unlimited printing, it is very difficult to enter a deflationary spiral unless there is a complete collapse in demand and an -unwillingness to print money. Deflation in bitcoin is not caused by a +unwillingness to print money. Deflation in Bitcoin is not caused by a collapse in demand, but by a predictably constrained supply. The positive aspect of deflation, of course, is that it is the opposite @@ -217,17 +217,17 @@ about who owns what, without having to trust anyone? All traditional payment systems depend on a trust model that has a central authority providing a clearinghouse service, basically verifying and clearing all transactions. Bitcoin has no central authority, yet somehow every full -node has a complete copy of a public ledger that it can trust as the +node has a complete copy of a public blockchain that it can trust as the authoritative record. The blockchain is not created by a central authority, but is assembled independently by every node in the network. Somehow, every node in the network, acting on information transmitted across insecure network connections, can arrive at the same conclusion -and assemble a copy of the same public ledger as everyone else. This +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 -consensus")))Satoshi Nakamoto's main invention is the decentralized +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 occurs. Instead, consensus is an emergent artifact of the asynchronous @@ -239,7 +239,6 @@ authority or trust, derive from this invention. Bitcoin's decentralized consensus emerges from the interplay of four processes that occur independently on nodes across the network: -[role="pagebreak-before"] - Independent verification of each transaction, by every full node, based on a comprehensive list of criteria @@ -256,7 +255,7 @@ processes that occur independently on nodes across the network: In the next few sections we will examine these processes and how they interact to create the emergent property of network-wide consensus that allows any Bitcoin node to assemble its own copy of the authoritative, -trusted, public, global ledger. +trusted, public, global blockchain. [[tx_verification]] === Independent Verification of Transactions @@ -285,7 +284,7 @@ criteria: - The transaction weight is low enough to allow it to fit in a block. - Each output value, as well as the total, must be within the allowed - range of values (zero or more, but less than 21m coins). + range of values (zero or more, but not exceeding 21 million bitcoins). - Lock time is equal to +INT_MAX+, or lock time and sequence values are satisfied according to the lock time and BIP68 rules. @@ -319,46 +318,20 @@ _mempool_. ((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining nodes")))Some of the nodes on the Bitcoin network are specialized nodes -called _miners_. Jing is a computer -engineering student in Shanghai, China, who is a Bitcoin miner. Jing +called _miners_. Jing is a +Bitcoin miner; he earns bitcoin by running a "mining rig," which is a specialized computer-hardware system designed to mine bitcoin. Jing's specialized mining hardware is connected to a server running a full node. -Unlike Jing, some miners mine without a full node, as we will see in -<>. Like every other full node, Jing's node receives and +Like every other full node, Jing's node receives and propagates unconfirmed transactions on the Bitcoin network. Jing's node, however, also aggregates these transactions into new blocks. -Jing's node is listening for new blocks, propagated on the Bitcoin -network, as do all nodes. However, the arrival of a new block has -special significance for a mining node. Each round of mining -effectively ends with the propagation of a new block that acts as an -announcement of a winner. To miners, receiving a valid new block means -someone else won. However, the end of one -round is also the beginning of the next round. The new -block is -also the start of the search for the next block. - -=== Aggregating Unconfirmed Transactions into Blocks - -((("mining and consensus", "aggregating transactions into blocks", -id="MACaggreg10")))((("transactions", "aggregating into blocks", -id="Taggreg10")))((("blocks", "aggregating transactions into", -id="Baggreg10")))((("blocks", "candidate blocks")))((("candidate -blocks")))((("transaction pools")))((("memory pools (mempools)")))After -validating transactions, a Bitcoin node will add them to the mempool -where transactions wait until they can be -included (mined) into a block. Jing's node collects, validates, and -relays new transactions just like any other node. Unlike other nodes, -however, Jing's node will then aggregate these unconfirmed transactions into a -_candidate block_. - Let's follow the blocks that were created during the time Alice made a -purchase from Bob (see <>). Alice's -transaction was included in a block. For the purpose of -demonstrating the concepts in this chapter, let's assume that block was -mined by Jing's mining system and follow Alice's transaction as it -becomes part of this new block. +purchase from Bob (see <>). For the purpose of +demonstrating the concepts in this chapter, let's assume the block +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 @@ -373,7 +346,7 @@ of the search to create the next block. During the previous several minutes, while Jing's node was searching for a solution to the previous block, it was also collecting transactions in preparation for the next block. By now it has collected a few thousand -transactions in the memory pool. Upon receiving the new block and +transactions in its memory pool. Upon receiving the new block and validating it, Jing's node will also compare it against all the transactions in the memory pool and remove any that were included in that block. Whatever transactions remain in the memory pool are @@ -400,13 +373,13 @@ the mining effort. Jing's node creates the coinbase transaction as a payment to his own wallet. The total amount of -reward that Jing collects for mining a block is the sum of the coinbase -reward (6.25 new bitcoin in 2023) and the transaction fees from all +reward that Jing collects for mining a block is the sum of the block +subsidy (6.25 new bitcoins in 2023) and the transaction fees from all the transactions included in the block. Unlike regular transactions, the coinbase transaction does not consume (spend) UTXOs as inputs. Instead, it has only one input, called the -_coinbase input_, which creates bitcoin from nothing. The coinbase transaction +_coinbase input_, which implicitly contains the block reward. The coinbase transaction must have at least one output and may have as many outputs as will fit in the block. It's common for coinbase transactions in 2023 to have two outputs: one of these is a zero-value output that uses +OP_RETURN+ to @@ -516,7 +489,7 @@ structure of the coinbase transaction's input. |Size| Field | Description | 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference | 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF -| 1–9 bytes (VarInt) | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes +| 1 byte | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes | Variable | Coinbase Data | Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height | 4 bytes | Sequence Number | Set to 0xFFFFFFFF |======= @@ -582,8 +555,8 @@ nonce field. [TIP] ==== The protocol upgrades defined in BIPs 34, 66, and 65 occurred in that -order--with BIP66 (strict DER) occuring before BIP65 -(+OP_CHECKTIMELOCKVERIFY+)--so Bitcoin developers often list them in +order, with BIP66 (strict DER) occuring before BIP65 +(+OP_CHECKTIMELOCKVERIFY+), so Bitcoin developers often list them in that order rather than sorted numerically. ==== @@ -609,7 +582,7 @@ 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 the first transaction (the coinbase). As we saw in the <> -the last wtxid is hashed with itslef if there are an odd number of wtxids, +the last wtxid is hashed with itself if there are an odd number of wtxids, creating nodes that each containing the hash of one transaction. The transaction hashes are then combined, in pairs, creating each level of the tree, until all the transactions are summarized into one node at the @@ -618,7 +591,7 @@ transactions into a single 32-byte value, which is the _witness root hash_. The witness root hash is added to an output of the coinbase transaction. -This step may be skipped in none of the transactions in the blook are +This step may be skipped if none of the transactions in the blook are required to contain a witness structure. Each transaction (including the coinbase transaction) is then listed using its transaction identifier (_txid_) and used to build a second merkle tree, the root of @@ -675,7 +648,7 @@ 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")))The key characteristic of a cryptographic hash +((("collisions")))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 @@ -683,7 +656,7 @@ way as to produce a desired digest, other than trying random inputs. With SHA256, the output is always 256 bits long, regardless of the size -of the input. For example, we will to calculate the SHA256 hash of the +of the input. For example, we will calculate the SHA256 hash of the phrase, "Hello, World!" ---- @@ -692,13 +665,13 @@ d9014c4624844aa5bac314773d6b689ad467fa4e1d1a50a1b8a99d5a95f72ff5 - ---- This -256-bit number (represented in hex) is the _hash_ or _digest_ of the phrase and depends on +256-bit output (represented in hex) is the _hash_ or _digest_ of the phrase and depends on every part of the phrase. Adding a single letter, punctuation mark, or any other character will produce a different hash. -The number used as a variable in such a scenario is called a _nonce_. +A variable used in such a scenario is called a _nonce_. The nonce is used to vary the output of a cryptographic function, in -this case to vary the SHA256 fingerprint of the phrase. +this case to vary the output of the SHA256 commitment to the phrase. To make a challenge out of this algorithm, let's set a target: find a phrase that produces a hexadecimal hash that starts with a zero. @@ -733,7 +706,7 @@ first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let's say a few rounds later the target is down to 5. Now, more than half the dice throws will exceed the target and -therefore be invalid. It takes exponentially more dice throws to win, +therefore be invalid. It takes more dice throws to win the lower the target gets. Eventually, when the target is 2 (the minimum possible), only one throw out of every 36, or about 3% of them, will produce a winning result. @@ -769,7 +742,7 @@ us 32 hash computations to find a nonce that worked. If we had a lower target (higher difficulty) it would take many more hash computations to find a suitable nonce, but only one hash computation for anyone to verify. Furthermore, by knowing the target, anyone can estimate the -difficulty using statistics and therefore know how much work was needed +difficulty using statistics and therefore know roughly how much work was needed to find such a nonce. [TIP] @@ -937,14 +910,6 @@ persist through the next 2,016 blocks. Therefore, large discrepancies between hashing power and difficulty might take several 2,016 block cycles to balance out. -[TIP] -==== -The difficulty of mining a bitcoin block is approximately '10 minutes of -processing' for the entire network, based on the time it took to mine -the previous 2,016 blocks, adjusted every 2,016 blocks. This is achieved -by lowering or raising the target. -==== - Note that the target is independent of the number of transactions or the value of transactions. This means that the amount of hashing power and therefore electricity expended to secure bitcoin is also entirely @@ -975,8 +940,8 @@ a decentralized network, which means that each participant has his or her own perspective of time. Events on the network do not occur instantaneously everywhere. Network latency must be factored into the perspective of each node. Eventually everything is synchronized to -create a common ledger. Bitcoin reaches consensus every 10 minutes about -the state of the ledger as it existed in the _past_. +create a common blockchain. Bitcoin reaches consensus every 10 minutes about +the state of the blockchain as it existed in the _past_. The timestamps set in block headers are set by the miners. There is a certain degree of latitude allowed by the consensus rules to account for @@ -1100,7 +1065,7 @@ don't miners write themselves a transaction for a thousand bitcoins instead of the correct reward? Because every node validates blocks according to the same rules. An invalid coinbase transaction would make the entire block invalid, which would result in the block being rejected -and, therefore, that transaction would never become part of the ledger. +and, therefore, that transaction would never become part of the blockchain. The miners have to construct a block, based on the shared rules that all nodes follow, and mine it with a correct solution to the Proof-of-Work. To do so, they expend a lot of electricity in mining, and @@ -1124,9 +1089,9 @@ The best chain may also have branches with blocks that are "siblings" to the blocks on the best chain. These blocks are valid but not part of the best chain. They are kept for future reference, in case one of those -many secondary chains later becomes primary. When sibling blocks occur, +secondary chains later becomes primary. When sibling blocks occur, they're usually the result of an -almost simultaneous mining of blocks at the same height. +almost simultaneous mining of different blocks at the same height. When a new block is received, a node will try to add it onto the existing blockchain. The node will look at the block's "previous block @@ -1136,7 +1101,8 @@ of the time, the parent will be the "tip" of the best chain, meaning this new block extends the best chain. Sometimes the new block does not extend -the best chain. In that case, the node will attach the new block to a +the best chain. In that case, the node will attach the new block's +header to a secondary chain and then compare the work of the secondary chain to the previous best chain. If the secondary chain is now the best chain, the node will accordingly _reorganize_ its view of confirmed transactions @@ -1179,7 +1145,7 @@ network hash rate in order to create a chain with equal proof of work. Shorter times between blocks doesn't result in earlier settlement. Its only advantage is providing weaker guarantees to people who are willing to accept those guarantees. For example, if you're willing to accept -three minutes of miners agreeing on the best block chain as sufficient +three minutes of miners agreeing on the best blockchain as sufficient security, you'd prefer a system with 1-minute blocks, where you could wait for three blocks, over a system with 10-minute blocks. The shorter the time between blocks, the more miner work is wasted on accidental @@ -1215,9 +1181,9 @@ a rapid pace. [[extra_nonce]] ==== The Extra Nonce Solution -((("nonce values")))Since 2012, bitcoin mining has evolved to resolve a +((("nonce values")))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 +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 increased, miners often cycled through all 4 billion values of the nonce without finding a block. However, this was easily resolved by updating @@ -1226,11 +1192,11 @@ timestamp is part of the header, the change would allow miners to iterate through the values of the nonce again with different results. Once mining hardware exceeded 4 GH/sec, however, this approach became increasingly difficult because the nonce values were exhausted in less -than a second. As ASIC mining equipment started pushing and then +than a second. As ASIC mining equipment started exceeding the TH/sec hash rate, the mining software needed more space for nonce values in order to find valid blocks. The timestamp could be stretched a bit, but moving it too far into the future would cause the -block to become invalid. A new source of "change" was needed in the +block to become invalid. A new source of variation was needed in the block header. One solution that was widely implemented was to use the coinbase transaction as a @@ -1262,8 +1228,8 @@ alone (also known as solo miners) don't stand a chance. The likelihood of them finding a block to offset their electricity and hardware costs is so low that it represents a gamble, like playing the lottery. Even the fastest consumer ASIC mining system cannot keep up with commercial -systems that stack tens of thousands of these chips in giant warehouses -near hydroelectric powerstations. Many miners now collaborate to form mining +operations that stack tens of thousands of these systems in giant warehouses +near powerstations. Many miners now collaborate to form mining pools, pooling their hashing power and sharing the reward among thousands of participants. By participating in a pool, miners get a smaller share of the overall reward, but typically get rewarded every @@ -1440,11 +1406,9 @@ include in their blocks.((("", startref="MAChash10")))((("", startref="MACoverpool10"))) [[consensus_attacks]] -=== Consensus Attacks +=== Hashrate Attacks -((("mining and consensus", "consensus attacks", -id="Cattack10")))((("security", "consensus attacks", -id="Sconsens10")))Bitcoin's consensus mechanism is, at least +Bitcoin's consensus mechanism is, at least theoretically, vulnerable to attack by miners (or pools) that attempt to use their hashing power to dishonest or destructive ends. As we saw, the consensus mechanism depends on having a majority of the miners acting @@ -1453,17 +1417,17 @@ can achieve a significant share of the mining power, they can attack the consensus mechanism so as to disrupt the security and availability of the Bitcoin network. -It is important to note that consensus attacks have the greatest effect on future +It is important to note that hashrate attacks have the greatest effect on future consensus. Confirmed transactions on the best blockchain become more and more immutable as time passes. While in theory, a fork can be achieved at any depth, in practice, the computing power needed to force a very deep fork is immense, making old blocks -very hard to change. Consensus attacks also do not affect the security +very hard to change. Hashrate attacks also do not affect the security of the private keys and signing algorithms. One attack scenario against the consensus mechanism is called the _majority attack_ or _51% attack._ In this scenario a group of miners, controlling a majority -of the total network's hashing power (such as 51%), collude to attack bitcoin. +of the total network's hashing power (such as 51%), collude to attack Bitcoin. With the ability to mine the majority of the blocks, the attacking miners can cause deliberate "forks" in the blockchain and double-spend transactions or execute denial-of-service attacks against specific @@ -1488,7 +1452,7 @@ customer service. This is similar to the practice of coffee shops that accept credit card payments without a signature for amounts below $25, because the risk of a credit-card chargeback is low while the cost of delaying the transaction to obtain a signature is comparatively larger. -In contrast, selling a more expensive item for bitcoin runs the risk of +In contrast, selling a more expensive item for bitcoins runs the risk of a double-spend attack, where the buyer broadcasts a competing transaction that spends one of the same inputs (UTXOs) and cancels the payment to the merchant. @@ -1497,12 +1461,12 @@ to double-spend their own transactions in the new chain, thus undoing the corresponding transaction in the old chain. //TODO:distinguish between majority attack and sub-majority "reorg" -//attack. Consensus attack +//attack. In our example, malicious attacker Mallory goes to ((("use cases", "retail sales", id="carolten")))Carol's gallery and purchases a -set of beautiful triptych paintings depicting Satoshi Nakamoto as Prometheus. -Carol sells "The Great Fire" paintings for $250,000 in bitcoin to +set of beautiful paintings depicting Satoshi Nakamoto as Prometheus. +Carol sells the paintings for $250,000 in bitcoins to Mallory. Instead of waiting for six or more confirmations on the transaction, Carol wraps and hands the paintings to Mallory after only one confirmation. Mallory works with an accomplice, Paul, who operates a @@ -1513,13 +1477,13 @@ transaction, replacing Mallory's payment to Carol with a transaction that double-spends the same input as Mallory's payment. The double-spend transaction consumes the same UTXO and pays it back to Mallory's wallet, instead of paying it to Carol, essentially allowing Mallory to keep the -bitcoin. Paul then directs the mining pool to mine an additional block, +bitcoins. Paul then directs the mining pool to mine an additional block, so as to make the chain containing the double-spend transaction longer than the original chain (causing a fork below the block containing Mallory's transaction). When the blockchain fork resolves in favor of the new (longer) chain, the double-spent transaction replaces the original payment to Carol. Carol is now missing the three paintings and -also has no bitcoin payment. Throughout all this activity, Paul's mining +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"))) @@ -1537,7 +1501,7 @@ be convenient and efficient even if the buyer has to wait 24 hours for delivery, which would correspond to approximately 144 confirmations. In addition to a double-spend attack, the other scenario for a consensus -attack is to deny service to specific bitcoin participants (specific +attack is to deny service to specific participants (specific Bitcoin addresses). An attacker with a majority of the mining power can censor transactions. If they are included in a block mined by another miner, the attacker can deliberately fork and remine @@ -1553,7 +1517,7 @@ Despite its name, the 51% attack scenario doesn't actually require 51% of the hashing power. In fact, such an attack can be attempted with a smaller percentage of the hashing power. The 51% threshold is simply the level at which such an attack is almost guaranteed to succeed. A -consensus attack is essentially a tug-of-war for the next block and the +hashrate attack is essentially a tug-of-war for the next block and the "stronger" group is more likely to win. With less hashing power, the probability of success is reduced, because other miners control the generation of some blocks with their "honest" mining power. One way to @@ -1561,7 +1525,7 @@ look at it is that the more hashing power an attacker has, the longer the fork he can deliberately create, the more blocks in the recent past he can invalidate, or the more blocks in the future he can control. Security research groups have used statistical modeling to claim that -various types of consensus attacks are possible with as little as 30% of +various types of hashrate attacks are possible with as little as 30% of the hashing power. The centralization of control caused by mining pools has @@ -1571,26 +1535,24 @@ blocks and also controls which transactions are included. This gives the pool operator the power to exclude transactions or introduce double-spend transactions. If such abuse of power is done in a limited and subtle way, a pool operator could conceivably profit from a -consensus attack without being noticed. +hashrate attack without being noticed. Not all attackers will be motivated by profit, however. One potential attack scenario is where an attacker intends to disrupt the Bitcoin network without the possibility of profiting from such disruption. A -malicious attack aimed at crippling bitcoin would require enormous +malicious attack aimed at crippling Bitcoin would require enormous investment and covert planning, but could conceivably be launched by a well-funded, most likely state-sponsored, attacker. Alternatively, a -well-funded attacker could attack Bitcoin's consensus by simultaneously +well-funded attacker could attack Bitcoin by simultaneously amassing mining hardware, compromising pool operators, and attacking other pools with denial-of-service. All of these scenarios are theoretically possible. -Undoubtedly, a serious consensus attack would erode confidence in +Undoubtedly, a serious hashrate attack would erode confidence in Bitcoin in the short term, possibly causing a significant price decline. However, the Bitcoin network and software are constantly evolving, so -consensus attacks would be met with immediate countermeasures by the -Bitcoin community, making Bitcoin more robust.((("", -startref="Cattack10")))((("", startref="MACattack10")))((("", -startref="Sconsens10"))) +attacks would be met with countermeasures by the +Bitcoin community. [[consensus_changes]] === Changing the Consensus Rules @@ -1709,7 +1671,7 @@ fork. Consensus rules may differ in obvious and explicit ways, in the validation of transactions or blocks. The rules may also differ in more subtle ways, in the implementation of the consensus rules as they apply -to bitcoin scripts or cryptographic primitives such as digital +to Bitcoin scripts or cryptographic primitives such as digital signatures. Finally, the consensus rules may differ in unanticipated ways because of implicit consensus constraints imposed by system limitations or implementation details. An example of the latter was seen @@ -1783,7 +1745,7 @@ for decentralized consensus. Just as other innovations in development changed bo and products of software and created new methodologies, new tools, and new communities in its wake, consensus software development also represents a new frontier in computer science. Out of the debates, -experiments, and tribulations of the bitcoin development roadmap, we +experiments, and tribulations of Bitcoin development, we will see new development tools, practices, methodologies, and communities emerge. @@ -1793,18 +1755,9 @@ system into two competing systems is seen by many as an unacceptable risk. As a result, many developers are reluctant to use the hard fork mechanism to implement upgrades to the consensus rules, unless there is near-unanimous support from the entire network. Any hard fork proposals -that do not have near-unanimous support are considered too "contentious" +that do not have near-unanimous support are considered too contentious to attempt without risking a partition of the system. -The issue of hard forks is highly controversial in the bitcoin -development community. Some -developers are opposed to any form of hard fork, seeing it as too risky. -Others see the mechanism of hard fork as an essential tool for upgrading -the consensus rules in a way that avoids "technical debt" and provides a -clean break with the past. Finally, some developers see hard forks as a -mechanism that should be used rarely, with a lot of advance planning and -only under near-unanimous consensus. - Already we have seen the emergence of new methodologies to address the risks of hard forks. In the next section, we will look at soft forks, and the methods for signaling and activation of @@ -1840,8 +1793,8 @@ nonupgraded nodes out of consensus. ===== Soft forks redefining NOP opcodes ((("opcodes", "redefinition by soft forks")))((("soft forks", -"redefinition of NOP codes")))A number of soft forks have been -implemented in bitcoin, based on the re-interpretation of NOP opcodes. +"redefinition of NOP codes")))Two soft forks have been +implemented in Bitcoin, based on the re-interpretation of NOP opcodes. Bitcoin Script had ten opcodes reserved for future use, NOP1 through NOP10. Under the consensus rules, the presence of these opcodes in a script is interpreted as a null-potent operator, meaning they have no @@ -1904,7 +1857,7 @@ This mechanism was introduced by BIP34. ==== BIP34 Signaling and Activation ((("bitcoin improvement proposals", "Block v2, Height in Coinbase -(BIP34)")))The first implementation, in BIP34, used the block version +(BIP34)")))BIP34 used the block version field to allow miners to signal readiness for a specific consensus rule change. Prior to BIP34, the block version was set to "1" by _convention_ not enforced by _consensus_. @@ -1914,7 +1867,7 @@ BIP34 defined a consensus rule change that required the coinbase field to BIP34, the coinbase could contain any arbitrary data the miners chose to include. After activation of BIP34, valid blocks had to contain a specific block-height at the beginning of the coinbase and be -identified with a version number greater than or equal to "2." +identified with a block version number greater than or equal to "2." To signal their readiness to enforce the rules of BIP34, miners set the block version to "2," instead of "1." This did not immediately make version @@ -1948,12 +1901,11 @@ mechanism was used twice more to activate soft forks: - https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP66] Strict DER Encoding of Signatures was activated by BIP34 style - signaling with a block version "3" and invalidating version "2" - blocks. + signaling with a block version "3". - https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65] +CHECKLOCKTIMEVERIFY+ was activated by BIP34 style signaling with a - block version "4" and invalidating version "3" blocks. + block version "4". After the activation of BIP65, the signaling and activation mechanism of BIP34 was retired and replaced with the BIP9 signaling mechanism @@ -2147,7 +2099,7 @@ future attempt to activate a soft fork. development")))((("development environment", "consensus software development")))Consensus software continues to evolve and there is much discussion on the various mechanisms for changing the consensus rules. -By its very nature, bitcoin sets a very high bar on coordination and +By its very nature, Bitcoin sets a very high bar on coordination and consensus for changes. As a decentralized system, it has no "authority" that can impose its will on the participants of the network. Power is diffused between multiple constituencies such as miners, protocol diff --git a/network.adoc b/network.adoc index 1385fdba..215cfad8 100644 --- a/network.adoc +++ b/network.adoc @@ -29,7 +29,7 @@ consensus network. ((("Bitcoin network", "defined")))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 or mobile wallets. These additional +are used for mining and lightweight wallets. These additional protocols are provided by gateway routing servers that access the Bitcoin network using the Bitcoin P2P protocol and then extend that network to nodes running other protocols. For example, Stratum servers @@ -48,9 +48,8 @@ supporting. A Bitcoin full node validates blocks and may contain other functions, such as routing, mining, and wallet services. Some nodes, called _archival full nodes_, also maintain a -complete and up-to-date copy of the blockchain. Full nodes can -autonomously and authoritatively verify any transaction without external -reference. Those nodes can +complete and up-to-date copy of the blockchain. +Those nodes can serve data to clients that store only a subset of the blockchain and partly verify transactions using a method called _simplified payment verification_, or SPV. ((("lightweight @@ -89,21 +88,13 @@ mining or wallet functions. These nodes act as network edge routers, allowing various other services (exchanges, wallets, block explorers, merchant payment processing) to be built on top. -The extended Bitcoin network includes the network running the Bitcoin -P2P protocol, described earlier, as well as nodes running specialized -protocols. Attached to the main Bitcoin P2P network are a number of pool -servers and protocol gateways that connect nodes running other -protocols. These other protocol nodes are mostly pool mining nodes (see -<>) and lightweight wallet clients, which do not carry a full -copy of the blockchain. - === Compact Block Relay When a miner finds a new block, they announce it to the Bitcoin network (which includes other miners). The miner who found that block can start building on top of it immediately; all other miners who haven't learned about the block yet will continue building on top of the previous block -until they do learn about it (and, ideally, they also validate it). +until they do learn about it. If, before they learn about the new block, one of those other miners creates a block, their block will be in competition with the @@ -476,7 +467,7 @@ because that contains +BestHeight+, a node's current blockchain height (number of blocks). A node will see the +version+ messages from its peers, know how many blocks they each have, and be able to compare to how many blocks it has in its own blockchain. Peered nodes will exchange -a +getheaders+ message that contains the hash (fingerprint) of the top +a +getheaders+ message that contains the hash of the top block on their local blockchain. One of the peers will be able to identify the received hash as belonging to a block that is not at the top, but rather belongs to an older block, thus deducing that its own @@ -1197,11 +1188,9 @@ pools")))((("memory pools (mempools)")))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 -yet included in the blockchain. For example, a wallet node will use the -mempool to track incoming payments to the user's wallet that -have been received on the network but are not yet confirmed. +yet included in the blockchain, called _unconfirmed transactions_. -As transactions are received and verified, they are added to the +As unconfirmed transactions are received and verified, they are added to the mempool and relayed to the neighboring nodes to propagate on the network. @@ -1236,9 +1225,7 @@ Whereas the mempool and orphan pools represent a single node's local perspective and might vary significantly from node to node depending upon when the node was started or restarted, the UTXO database represents the emergent consensus of the network and therefore will not usually -vary between nodes. Furthermore, the mempool and orphan pools only -contain unconfirmed transactions, while the UTXO database only contains -confirmed outputs. +vary between nodes. Now that we have a understanding of many of the data types and structures used by nodes and clients to send data across the Bitcoin diff --git a/overview.adoc b/overview.adoc index c39033e7..5fe85ee2 100644 --- a/overview.adoc +++ b/overview.adoc @@ -8,9 +8,9 @@ payment systems, does not require trust in third parties. Instead of a central trusted authority, in Bitcoin, each user can use software running on their own computer to verify the correct operation of every aspect of the Bitcoin system. -In this chapter, we will examine bitcoin from a high level by tracking a +In this chapter, we will examine Bitcoin from a high level by tracking a single transaction through the Bitcoin system and watch as it -is recorded on the blockchain, the distributed ledger of all +is recorded on the blockchain, the distributed journal of all transactions. Subsequent chapters will delve into the technology behind transactions, the network, and mining. @@ -20,7 +20,7 @@ In the overview diagram shown in <>, we see that the Bitcoin system consists of users with wallets containing keys, transactions that are propagated across the network, and miners who produce (through competitive computation) the consensus blockchain, -which is the authoritative ledger of all transactions. +which is the authoritative journal of all transactions. ((("blockchain explorer sites")))Each example in this chapter is based on an actual transaction made on the Bitcoin network, simulating the @@ -54,7 +54,7 @@ it in detail. ==== Searching information on a block explorer may disclose to its operator that you're interested in that information, allowing them to associate -it with your IP address, browser fingerprint, past searches, or other +it with your IP address, browser details, past searches, or other identifiable information. If you look up the transactions in this book, the operator of the block explorer might guess that you're learning about Bitcoin, which shouldn't be a problem. But if you look up your @@ -69,10 +69,10 @@ Alice, introduced in the previous chapter, is a new user who has just acquired her first bitcoins. In <>, Alice met with her friend Joe to exchange some cash for bitcoins. Since then, Alice has bought additional bitcoins. Now Alice will make -her first retail transaction, buying access to a premium podcast episode from Bob's online store. +her first spending transaction, buying access to a premium podcast episode from Bob's online store. Bob's web store recently started accepting bitcoin payments by adding a -bitcoin option to its website. The prices at Bob's store are listed in +Bitcoin option to its website. The prices at Bob's store are listed in the local currency (US dollars), but at checkout, customers have the option of paying in either dollars or bitcoin. @@ -88,7 +88,7 @@ _invoice_ (<>). Unlike a QR code that simply contains a destination Bitcoin address, this invoice is a QR-encoded URI that contains a destination address, a payment amount, and a description. -This allows a bitcoin wallet application to prefill the +This allows a Bitcoin wallet application to prefill the information used to send the payment while showing a human-readable description to the user. You can scan the QR code with a bitcoin wallet application to see what Alice would see. @@ -161,7 +161,7 @@ can spend that amount in subsequent transactions. === Bitcoin Transactions ((("transactions", "defined")))In simple terms, a transaction tells the -network that the owner of some bitcoin value has authorized the transfer +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 owner, and so on, in a chain of ownership. @@ -170,21 +170,21 @@ owner, and so on, in a chain of ownership. ((("transactions", "overview of", id="Tover02")))((("outputs and inputs", "basics of")))Transactions are like lines in a double-entry -bookkeeping ledger. Each transaction contains one or more "inputs," +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. +the transaction, there are one or more _outputs_, which receive funds. ((("fees", "transaction fees")))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 payment collected by the miner who includes the transaction in the -ledger. A bitcoin transaction is shown as a bookkeeping ledger entry in +blockchain. A Bitcoin transaction is shown as a bookkeeping ledger entry in <>. The transaction also contains proof of ownership for each amount of -bitcoin (inputs) whose value is being spent, in the form of a digital +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. ((("spending bitcoin", "defined")))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. @@ -196,7 +196,7 @@ image::images/mbc2_0203.png["Transaction Double-Entry"] ((("chain of transactions")))Alice's payment to Bob's Store uses a previous transaction's output as its input. In the previous chapter, -Alice received bitcoin from her friend Joe in return for cash. +Alice received bitcoins from her friend Joe in return for cash. We've labeled that as _Transaction 1_ (Tx1) in <>. Tx1 sent 0.001 bitcoins (100,000 satoshis) to an output locked by @@ -260,7 +260,7 @@ This is because transaction inputs, like currency notes, cannot be partly spent. If you purchase a $5 US dollar item in a store but use a $20 dollar bill to pay for the item, you expect to receive $15 dollars in change. The same concept applies to -bitcoin transaction inputs. If you purchased an item that costs 5 +Bitcoin transaction inputs. If you purchased an item that costs 5 bitcoins but only had an input worth 20 bitcoins to use, you would send one output of 5 bitcoins to the store owner and one output of 15 bitcoins back to yourself as change (not counting your transaction fee). @@ -298,8 +298,8 @@ the desired payment plus transaction fees, the wallet will need to generate some change. This is very similar to how people handle cash. If you always use the largest bill in your pocket, you will end up with a pocket full of loose change. If you only use the loose change, you'll -always have only big bills. People subconsciously find a balance between -these two extremes, and bitcoin wallet developers strive to program this +often have only big bills. People subconsciously find a balance between +these two extremes, and Bitcoin wallet developers strive to program this balance. ==== Common Transaction Forms @@ -322,8 +322,8 @@ generated by wallets and businesses to clean up lots of smaller amounts. .Consolidation transaction aggregating funds image::images/mbc2_0206.png["Aggregating Transaction"] -Finally, another transaction form that is seen often on the bitcoin -ledger is _payment batching_ that pays to multiple outputs +Finally, another transaction form that is seen often on the +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 @@ -394,8 +394,8 @@ Finally, for the transaction to be processed by the network in a timely fashion, Alice's wallet application will add a small fee. The fee is not explicitly stated in the transaction; it is implied by the difference in value between inputs and outputs. This _transaction fee_ is collected by the -miner as a fee for validating and including the transaction in a block -to be recorded on the blockchain. +miner as a fee for including the transaction in a block +that gets recorded on the blockchain. [[transaction-alice-url]] [TIP] @@ -403,7 +403,7 @@ to be recorded on the blockchain. View the https://blockstream.info/tx/466200308696215bbc949d5141a49a4138ecdfdfaa2a8029c1f9bcecd1f96177[transaction from Alice to Bob's Store]. ==== -==== Adding the Transaction to the Ledger +==== Adding the Transaction to the Blockchain The transaction created by Alice's wallet application contains everything necessary to confirm ownership of the funds and @@ -417,7 +417,7 @@ blocks are added. ===== Transmitting the transaction ((("propagation", "process of")))Because the transaction contains all -the information necessary to process, it does not matter how or where it +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 connecting to several other Bitcoin peers. The purpose of the Bitcoin @@ -437,8 +437,8 @@ Alice's wallet application can send the new transaction to any Bitcoin node over any type of connection: wired, WiFi, mobile, etc. It can also send the transaction to another program (such as a block explorer) that will relay it to a -node. Her bitcoin wallet does not have -to be connected to Bob's bitcoin wallet directly and she does not have +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 @@ -450,7 +450,7 @@ few seconds. ===== Bob's view -If Bob's bitcoin wallet application is directly connected to Alice's +If Bob's Bitcoin wallet application is directly connected to Alice's wallet application, Bob's wallet application might be the first to receive the transaction. However, even if Alice's wallet sends the transaction through other nodes, it will reach Bob's wallet within a few @@ -475,7 +475,7 @@ Transactions are bundled into _blocks_. Blocks have a very small header that must be formed in a very specific way, requiring an enormous amount of computation to get right--but only a small amount of computation to verify as correct. -The mining process serves two purposes in bitcoin: +The mining process serves two purposes in Bitcoin: * ((("mining and consensus", "consensus rules", "security provided by")))((("consensus", see="mining and consensus")))Miners can only @@ -485,7 +485,7 @@ only include valid transactions in their blocks and the blocks they build upon. This allows users to optionally make a trust-based assumption that any transaction in a block is a valid transaction. -* Mining currently creates new bitcoin's in each block, almost like a central bank +* Mining currently creates new bitcoins in each block, almost like a central bank printing new money. The amount of bitcoin created per block is limited and diminishes with time, following a fixed issuance schedule. @@ -493,25 +493,25 @@ and diminishes with time, following a fixed issuance schedule. Mining achieves a fine balance between cost and reward. Mining uses electricity to solve a computational problem. A successful miner will collect a _reward_ in the form of new bitcoins and transaction fees. -However, the reward will only be collected if the miner has correctly -validated all the transactions, to the satisfaction of the rules of -_consensus_. This delicate balance provides security for Bitcoin without -a central authority. +However, the reward will only be collected if the miner has only +included valid transactions, with the Bitcoin Protocol's rules for +_consensus_ dermining what is valid. This delicate balance provides +security for Bitcoin without a central authority. Mining is designed to be a decentralized lottery. Each miner can create -their own lottery ticket by creating a _block template_ that includes +their own lottery ticket by creating a _candidate block_ that includes the new transactions they want to mine plus some additional data fields. -The miner inputs their template into a specially-designed algorithm that +The miner inputs their candidate into a specially-designed algorithm that scrambles (or "hashes") the data, producing output that looks nothing like the input data. This _hash_ function will always produce the same output for the same input--but nobody can predict what the output will look like for a new input, even if it is only slighly different from a previous input. If the output of hash function matches a template determined by the Bitcoin protocol, the miner wins the lottery and -Bitcoin users will accept the block template with its transactions as a +Bitcoin users will accept the block with its transactions as a valid block. If the output doesn't match the template, the miner makes -a small change to their block template and tries again. As of this -writing, the number of block templates miners need to try before finding +a small change to their candidate block and tries again. As of this +writing, the number of candidate blocks miners need to try before finding a winning combination is about 168 billion trillions. That's also how many times the hash function needs to be run. @@ -523,77 +523,35 @@ verification process is able to probabalistically prove the work was done, so the data necessary to generate that proof--in this case, the block--is called Proof-of-Work (PoW). -((("mining and consensus", "mining farms and pools"))) -((("use cases", "mining for -bitcoin")))Jing is an entrepreneur in Shanghai. Jing runs a _mining farm_, -which is a business that runs thousands of specialized mining computers, -competing for the block reward. Jing's mining -computers compete against thousands of similar systems in the global -lottery to create the next block. - -Jing started mining in 2010 using a very fast desktop computer to find a -suitable Proof-of-Work for new blocks. As more miners started joining -the Bitcoin network, the Bitcoin protocol automatically increased the -difficulty of finding a new block. -Soon, Jing and other miners upgraded to more specialized hardware, such -as high-end dedicated graphical processing units (GPUs) -used in gaming desktops. At the time of this writing, -the difficulty is so high that it is profitable only to mine with -((("application-specific integrated circuits -(ASIC)")))application-specific integrated circuits (ASIC), essentially -hundreds of mining algorithms printed in hardware, running in parallel -on a single silicon chip. ((("mining pools", "defined")))Jing's company -also participates in a _mining pool_, which much like a lottery pool -allows several participants to share their efforts and rewards. Jing's -company now runs a warehouse containing thousands of ASIC miners to -mine for bitcoins 24 hours a day. The company pays its electricity costs -by selling the bitcoins it is able to generate from mining, creating some -income from the profits. - -[[confirmation_score]] -=== Mining Transactions in Blocks - -((("blocks", "mining transactions in")))New transactions are constantly -flowing into the network from user wallets and other applications. As -these are seen by the Bitcoin network nodes, they get added to a -temporary pool of unverified transactions maintained by each node. As -miners construct a new _candidate block_, they add unverified transactions from this -pool to the candidate block and then attempt to prove the validity of that -candidate block, with the mining algorithm (Proof-of-Work). The process of mining -is explained in detail in <>. - Transactions are added to the new block, prioritized by the highest fee rate transactions first and a few other criteria. Each miner starts the -process of mining a new candidate block of transactions as soon as he receives the +process of mining a new candidate block of transactions as soon as they receive the previous block from the network, knowing that some other miner won that -iteration of the lottery. He immediately creates a new candidate block -with a commitment to the previous block, fills it with transactions, and starts +iteration of the lottery. They immediately create a new candidate block +with a commitment to the previous block, fill it with transactions, and start calculating the Proof-of-Work for the candidate block. Each miner includes a -special transaction in his candidate block, one that pays his own Bitcoin address +special transaction in their candidate blocks, one that pays their own Bitcoin address the block reward plus the sum of -transaction fees from all the transactions included in the candidate block. If he -finds a solution that makes the candidate into a valid block, he receives this reward +transaction fees from all the transactions included in the candidate block. If they +finds a solution that makes the candidate into a valid block, they receives this reward after his successful block is added to the global blockchain and the reward transaction he included becomes spendable. ((("mining pools", -"operation of")))Jing, who participates in a mining pool, has set up his +"operation of")))Miners who participates in a mining pool have set up their software to create candidate blocks that assign the reward to a pool address. -From there, a share of the reward is distributed to Jing and other -miners in proportion to the amount of work they contributed in the last -round. +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 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 block template generated by Jing's -mining pool. All the miners participating in that mining pool -immediately start trying to generate a Proof-of-Work for the block template. +included in a candidate block. Approximately five minutes after the transaction was first transmitted -by Alice's wallet, one of Jing's ASIC miners found a solution for the -block and announced it to the network. After each other miner +by Alice's wallet, a miner finds a solution for the +block and announces it to the network. After each other miner validates the winning block, they start a new lottery to generate the next block. -Jing's winning block containing Alice's transaction became part of the +The winning block containing Alice's transaction became part of the blockchain. The block containing Alice's transaction is counted as one _confirmation_ of that transaction. After the block containing Alice's transaction has propagated through the network, creating an alternative @@ -612,7 +570,7 @@ Alice paying miners a share of the money she previously paid Bob. This dishonest behavior will require they expend the effort required to create two new blocks. Instead, miners who behave honestly can create a single new block and and receive all of the fees from the transactions -they include in it, plus the block reward. Normally, the high cost of +they include in it, plus the block subsidy. Normally, the high cost of dishonestly creating two blocks for a small additional payment is much less profitable than honestly creating a new block, making it unlikely that a confirmed transaction will be deliberately changed. For Bob, this @@ -626,7 +584,8 @@ https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764 ==== ((("confirmations", "role in transactions")))Approximately 19 minutes -after Jing's block, a new block is mined by another miner. Because this +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 transaction (giving Alice's transaction two confirmations) Alice's transaction can now only be changed if two alternative blocks are @@ -659,24 +618,24 @@ image::images/mbc2_0209.png["Alice's transaction included in a block"] Now that Alice's transaction has been embedded in the blockchain as part of a block, it -is part of the distributed ledger of Bitcoin and visible to all Bitcoin -applications. Each bitcoin full node can independently verify the +is visible to all Bitcoin +applications. Each Bitcoin full node can independently verify the transaction as valid and spendable. Full nodes validate every transfer -of the funds from the moment the bitcoin were first generated in +of the funds from the moment the bitcoins were first generated in a block through each subsequent transaction until they reach -Bob's address. Lightweight clients can do what is called a simplified -payment verification (see <>) by confirming that the +Bob's address. Lightweight clients can partially verify payments +by confirming that the transaction is in the blockchain and has several blocks mined after it, thus providing assurance that the miners expended significant effort -committing to it. +committing to it (see <>). Bob can now spend the output from this and other transactions. For example, Bob can pay a contractor or supplier by transferring value from Alice's podcast payment to these new owners. As Bob spends the payments received from Alice and other customers, he extends the chain of transactions. Let's assume that Bob pays his web -designer Gopesh((("use cases", "offshore contract services"))) in -Bangalore for a new website page. Now the chain of transactions will +designer Gopesh +for a new website page. Now the chain of transactions will look like <>. [[block-alice2]] diff --git a/preface.asciidoc b/preface.asciidoc index 09ab6bb0..77181970 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -9,7 +9,7 @@ Two years later, after creating a number of small startups to explore various Bi === 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. +((("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. === Why Are There Bugs on the Cover? @@ -55,13 +55,13 @@ All the code snippets can be replicated on most operating systems with a minimal Some of the code snippets and code output have been reformatted for print. In all such cases, the lines have been split by a backslash (\) character, followed by a newline character. When transcribing the examples, remove those two characters and join the lines again and you should see identical results as shown in the example. -All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values. For example, many of the private keys and corresponding public keys and addresses are real. The sample transactions, blocks, and blockchain references are all part of the actual Bitcoin blockchain, so you can review them on any Bitcoin system. +All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values. === Using Code Examples 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 Andreas M. Antonopoulos, 978-1-491-95438-6.” +((("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.” ((("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. @@ -119,7 +119,6 @@ Follow us on Twitter: link:$$https://twitter.com/oreillymedia$$[] Watch us on YouTube: link:$$https://www.youtube.com/oreillymedia$$[] -[role="pagebreak-before"] === Contacting the Authors You can contact Andreas M. Antonopoulos on his personal site: @@ -147,9 +146,9 @@ 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. +((("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. -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. +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. The journey to becoming an author starts long before the first book, of course. My first language (and schooling) was Greek, so I had to take a remedial English writing course in my first year of university. I owe thanks to Diana Kordas, my English writing teacher, who helped me build confidence and skills that year. Later, as a professional, I developed my technical writing skills on the topic of data centers, writing for _Network World_ magazine. I owe thanks to John Dix and John Gallant, who gave me my first writing job as a columnist at _Network World_ and to my editor Michael Cooney and my colleague Johna Till Johnson who edited my columns and made them fit for publication. Writing 500 words a week for four years gave me enough experience to eventually consider becoming an author. @@ -157,7 +156,7 @@ Thanks also to those who supported me when I submitted my book proposal to O'Rei Thanks to Cricket Liu, author of the O'Reilly title _DNS and BIND_, who introduced me to O'Reilly. Thanks also to Michael Loukides and Allyson MacDonald at O'Reilly, who worked for months to help make this book happen. Allyson was especially patient when deadlines were missed and deliverables delayed as life intervened in our planned schedule. For the second edition, I thank Timothy McGovern for guiding the process, Kim Cofer for patiently editing, and Rebecca Panzer for illustrating many new diagrams. -The first few drafts of the first few chapters were the hardest, because bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of bitcoin through the stories of the people using bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design. +The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design. During the development of the book, I made early drafts available on GitHub and invited public comments. More than a hundred comments, suggestions, corrections, and contributions were submitted in response. Those contributions are explicitly acknowledged, with my thanks, in <>. Most of all, my sincere thanks to my volunteer GitHub editors Ming T. Nguyen (1st edition) and Will Binns (2nd edition), who worked tirelessly to curate, manage and resolve pull requests, issue reports, and perform bug fixes on GitHub. @@ -201,7 +200,7 @@ of you often and know that my contributions to this book would not have been possible without all that you've done for me. [[github_contrib]] -==== Early Release Draft (GitHub Contributions) +=== Early Release Draft (GitHub Contributions) Many contributors offered comments, corrections, and additions to the early-release draft on GitHub. Thank you all for your contributions to this book. diff --git a/security.adoc b/security.adoc index 7306dc29..26441781 100644 --- a/security.adoc +++ b/security.adoc @@ -50,7 +50,7 @@ It does not reveal any private information, such as the identities of the parties, and cannot be used to authorize additional payments. Therefore, a Bitcoin payment network does not need to be encrypted or protected from eavesdropping. In fact, you can broadcast -bitcoin transactions over an open public channel, such as unsecured WiFi +Bitcoin transactions over an open public channel, such as unsecured WiFi or Bluetooth, with no loss of security. Bitcoin's decentralized security model puts a lot of power in the hands @@ -63,7 +63,7 @@ able to adequately secure their keys and get hacked, one by one. ==== Developing Bitcoin Systems Securely -((("decentralized systems", "bitcoin as")))The most important principle +((("decentralized systems", "bitcoin as")))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. @@ -114,7 +114,7 @@ many servers layered in concentric circles of diminishing trust. ((("mining and consensus", "security and consensus")))Bitcoin security architecture is different. In Bitcoin, the consensus system creates a -trusted public ledger that is completely decentralized. A correctly +trusted blockchain that is completely decentralized. A correctly validated blockchain uses the genesis block as the root of trust, building a chain of trust up to the current block. Bitcoin systems can and should use the blockchain as their root of trust. When designing a @@ -140,7 +140,7 @@ The numerous examples of hacked Bitcoin exchanges serve to underscore this point because their security architecture and design fails even under the most casual scrutiny. These centralized implementations had invested trust explicitly in numerous components outside the Bitcoin -blockchain, such as hot wallets, centralized ledger databases, +blockchain, such as hot wallets, centralized databases, vulnerable encryption keys, and similar schemes.((("", startref="Sprinc11"))) @@ -197,7 +197,7 @@ we will examine various best practices for practical user security. wallets")))((("wallets", "types of", "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 bitcoin is to convert them into physical +effective method for protecting bitcoins is to convert them into physical form. Bitcoin keys, and the seeds used to create them, are nothing more than long numbers. This means that they can be stored in a physical form, such as printed on paper or etched on a metal plate. Securing the keys then becomes as simple as @@ -219,9 +219,9 @@ form of tamper-proof hardware signing devices. Unlike a smartphone or desktop computer, a Bitcoin hardware signing device only needs to hold keys and use them to generate signatures. Without general-purpose software to compromise and -with limited interfaces, hardware signing devices can deliver an almost -foolproof level of security to nonexpert users. Hardware -signing devices may become the predominant method of bitcoin storage. +with limited interfaces, hardware signing devices can deliver strong +security to nonexpert users. Hardware +signing devices may become the predominant method of storing bitcoins. ==== Ensuring Your Access @@ -235,7 +235,7 @@ project lost almost 7,000 bitcoin. In their effort to prevent theft, the owners had implemented a complex series of encrypted backups. In the end they accidentally lost the encryption keys, making the backups worthless and losing a fortune. Like hiding money by burying it in the desert, if -you secure your bitcoins too well you might not be able to find it again. +you secure your bitcoins too well you might not be able to find them again. [WARNING] ==== @@ -253,7 +253,7 @@ more details, see <>. Would you carry your entire net worth in cash in your wallet? Most people would consider that reckless, yet Bitcoin users often keep all -their bitcoin using a single wallet application. Instead, users should spread the risk +their bitcoins using a single wallet application. Instead, users should spread the risk among multiple and diverse Bitcoin applications. Prudent users will keep only a small fraction, perhaps less than 5%, of their bitcoins in an online or mobile wallet as "pocket change." The rest should be split between a few @@ -264,7 +264,7 @@ storage). ((("multisig addresses")))((("addresses", "multisig addresses")))Whenever a company or individual stores large amounts of -bitcoin, they should consider using a multisignature Bitcoin address. +bitcoins, they should consider using a multisignature Bitcoin address. Multisignature addresses secure funds by requiring more than one signature to make a payment. The signing keys should be stored in a number of different locations and under the control of different people. diff --git a/signatures.adoc b/signatures.adoc index b8337725..ba051172 100644 --- a/signatures.adoc +++ b/signatures.adoc @@ -111,7 +111,7 @@ that is appended to the signature. Every signature has either an explicit or implicit +SIGHASH+ flag and the flag can be different from input to input. A transaction with three signed inputs may have three signatures with different +SIGHASH+ -flags, each signature signing (committing) different parts of the +flags, each signature signing (committing) to different parts of the transaction. Remember, each input may contain one or more signatures. As @@ -167,14 +167,6 @@ By including the +SIGHASH+ flag itself, the signature commits the +SIGHASH+ type as well, so it can't be changed (e.g., by a miner). -[NOTE] -==== -All +SIGHASH+ types sign the transaction lock time field (see -<>). In addition, the +SIGHASH+ type -itself is appended to the transaction before it is signed, so that it -can't be modified once signed. -==== - In <>, we will see that the last part of the DER-encoded signature was +01+, which is the +SIGHASH_ALL+ flag for ECDSA signatures. This @@ -282,14 +274,14 @@ Linearity:: variables and then running a function on that sum will produce the same value as running the function on each of the variables independently and then summing together the results, e.g. - +f(x + y + z) = f(x) + f(y) + f(z)+; this property is called + +f(x + y + z) == f(x) + f(y) + f(z)+; this property is called _additivity_. The second property is that multiplying a variable and then running a function on that product will produce the same value as running the function on the variable and then multiplying it by the - same amount, e.g. +f(a * x) = a * f(x)+; this property is called + same amount, e.g. +f(a * x) == a * f(x)+; this property is called _homogeneity of degree 1_. + -In cryptographic operations, some of the functions may be private (such +In cryptographic operations, some functions may be private (such as functions involving private keys or secret nonces), so being able to get the same result whether performing an operation inside or outside of a function makes it easy for multiple parties to coordinate @@ -366,7 +358,7 @@ generator +G=5+ to get her public key +xG=15+. She gives Bob +15+. 2. Bob chooses +e=11+ and gives it to Alice. -3. Alice generates +s = 40 = 7 + 11*3+. She gives Bob +40+. +3. Alice generates +s = 40 = 7 + 11 * 3+. She gives Bob +40+. 4. Bob derives +sG = 200 = 40 * 5+ and +exG = 165 = 11 * 15+. He then verifies that +200 == 35 + 165+. Note that this is the same operation @@ -406,21 +398,21 @@ identity protocol that make it secure: commits to her public nonce. Consider what could happen if someone who didn't know +x+ wanted to impersonate Alice, and Bob accidentally gave them the challenge scalar +e+ before they told him the public - nonce +kG+. This allows them to change parameters on both sides of + nonce +kG+. This allows the impersonator to change parameters on both sides of the equation that Bob will use for verification, +sG == kG + exG+, specifically they can change both +sG+ and +kG+. Think about a simplified form of that expression: x = y + a. If you can change both - +x+ and +y+, you can cancel out +a+ using +x = (x - a) + a+. Any + +x+ and +y+, you can cancel out +a+ using +x' = (x - a) + a+. Any value you choose for +x+ will now satisfy the equation. For the - actual equation they simply choose a random number for +s+, generate - +sG+, and then use EC subtraction to select a +kG+ that equals +kG = + actual equation the impersonator simply chooses a random number for +s+, generates + +sG+, and then uses EC subtraction to select a +kG+ that equals +kG = sG - exG+. They give Bob their calculated +kG+ and later their random +sG+, and Bob thinks that's valid because +sG == (sG - exG) + exG+. This explains why the order of operations in the protocol is essential: Bob must only give Alice the challenge scalar after Alice has committed to her public nonce. -The interactive identity protocol described matches part of Claus +The interactive identity protocol described here matches part of Claus Schnorr's original description, but it lacks two essential features we need for the decentralized Bitcoin network. The first of these is that it relies on Bob waiting for Alice to commit to her public nonce and @@ -475,8 +467,9 @@ concern. In BIP32 key derivation, as described in takes a public key and adds to it a non-secret value to produce a derived public key. That means it's also possible to add that non-secret value to a valid signature for one key to produce a signature -for a related key that's valid but which wasn't authorized by someone -possessing the private key. To protect BIP32 unhardened derivation and +for a related key. That related signature is valid but it wasn't +authorized by the person possessing the private key, which is a major +security failure. To protect BIP32 unhardened derivation and also support several protocols people wanted to build on top of schnorr signatures, Bitcoin's version of schnorr signatures, called _BIP340 schnorr signatures for secp256k1_, also commits to the public key being @@ -539,7 +532,7 @@ They're serialized in the order of +kG+ and then +s+, producing exactly 64 bytes. The taproot soft fork, also called v1 segwit, introduced schnorr signatures -to Bitcoin and is the only way they are used as of this writing. When +to Bitcoin and is the only way they are used in Bitcoin as of this writing. When used with either taproot keypath or scriptpath spending, a 64-byte schnorr signature is considered to use a default signature hash (sighash) that is +SIGHASH_ALL+. If an alternative sighash is used, or if the @@ -823,10 +816,10 @@ signatures are created by a mathematical function _F_~_sig_~ that produces a signature composed of two values. In ECDSA, those two values are _R_ and _s_. -((("public and private keys", "key pairs", "ephemeral")))The signature +The signature algorithm first generates a private nonce (_k_) and derives from it a public nonce (_K_). The _R_ value of the digital signature is then the x -coordinate of the ephemeral public key _K_. +coordinate of the nonce _K_. From there, the algorithm calculates the _s_ value of the signature, such that. Like we did with schnorr signatures, operations involving @@ -858,9 +851,6 @@ where: If the x coordinate of the calculated point _K_ is equal to _R_, then the verifier can conclude that the signature is valid. -Note that in verifying the signature, the private key is neither known -nor revealed. - [TIP] ==== ECDSA is necessarily a fairly complicated piece of math; a full @@ -893,10 +883,6 @@ as follows: * +S+—++4b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813++ * A suffix (+0x01+) indicating the type of hash used (+SIGHASH_ALL+) -See if you can decode Alice's serialized (DER-encoded) signature using -this list. The important numbers are +R+ and +S+; the rest of the data -is part of the DER encoding scheme. - [[nonce_warning]] === The Importance of Randomness in Signatures @@ -952,11 +938,6 @@ startref="Tdigsig06"))) === Segregated Witness's New Signing Algorithm -Segregated Witness modified the semantics of the four signature -verification functions from legacy Bitcoin Script (+CHECKSIG+, +CHECKSIGVERIFY+, +CHECKMULTISIG+, -and +CHECKMULTISIGVERIFY+), changing the way a transaction commitment -hash is calculated. - Signatures in bitcoin transactions are applied on a _commitment hash_, which is calculated from the transaction data, locking specific parts of the data indicating the signer's commitment to those values. For diff --git a/tools/discouraged.sh b/tools/discouraged.sh index ac713139..937ddf24 100755 --- a/tools/discouraged.sh +++ b/tools/discouraged.sh @@ -15,6 +15,7 @@ done for f in $( git ls-files | grep -v "$0" ) ; do { echo -n + grep "bitcoin's" $f } | if grep . ; then echo "DISCOURAGED WORDS FOUND IN $f" ; exit 1 ; fi done @@ -34,6 +35,8 @@ BIP [0-9] \ \ \ +\ +\ witness field witness element feerate @@ -44,3 +47,5 @@ k-of-n blockchain.info blockchain.com [a-zA-Z]---[a-zA-Z] +fingerprint +block chain diff --git a/transactions.adoc b/transactions.adoc index 5b9d72ec..bcbbf3a3 100644 --- a/transactions.adoc +++ b/transactions.adoc @@ -290,7 +290,7 @@ pieces of information from it: One of Bitcoin's consensus rules forbids any output from being spent more than once within a valid blockchain. This is the rule against _double spending_: Alice can't use the same previous output to pay - both Bob and Carol is separate transactions. Two transactions which each try to spend the + both Bob and Carol in separate transactions. Two transactions which each try to spend the same previous output are called _conflicting transactions_ because only one of them can be included in a valid blockchain. @@ -707,7 +707,7 @@ have various processes for interrogating witnesses to (ideally) only accept evidence from those who are reliable. Imagine what a witness would look like for a math problem. For example, -if the important problem was _x + 2 = 4_ and someone claimed they +if the important problem was _x + 2 == 4_ and someone claimed they witnessed the solution, what would we ask them? We'd want a mathematical proof that showed a value which could be summed with two to equal four. We could even omit the need for a person and just use the @@ -844,7 +844,7 @@ example, Alice can use a sighash to allow Bob to help her pay some transaction fees. This mutates Alice's transaction but only in a way that Alice wants. For that reason, we will occasionally prefix the word _unwanted_ to the term _transaction malleability_. Even when we -and other Bitcoin technical writers use the base term, we're almost +and other Bitcoin technical writers use the shorter term, we're almost certainly talking about the unwanted variant of malleability. ==== @@ -867,11 +867,11 @@ money, so she cooperates with Bob to create a chain of transactions. bitcoins to two outputs. The first output spends some of Alice's money; the second output returns the remainder of the bitcoins back to the script requiring Alice and Bob's signatures. Before signing this - transaction, they create a new refund transaction, Tx~1~. + transaction, they create a new refund transaction, Tx~1~ - Tx~1~ spends the second output of Tx~0~ to two new outputs, one to Alice for her share of the joint funds, and one to Bob for his share. - Alice and Bob both sign this transaction before they sign Tx~0~. + Alice and Bob both sign this transaction before they sign Tx~0~ There's no circular dependency here and, if we ignore third-party transaction malleability, this looks like it should provide us with a @@ -1038,7 +1038,7 @@ Some of the special rules for coinbase transactions include: - They may only have one input. -- The single input must have outpoint with a null txid (consisting entirely +- The single input must have an outpoint with a null txid (consisting entirely of zeroes) and a maximal output index (0xffffffff). This prevents the coinbase transaction from referencing a previous transaction output, which would (at the very least) be confusing given that the coinbase diff --git a/wallets.adoc b/wallets.adoc index ae31def3..096b6994 100644 --- a/wallets.adoc +++ b/wallets.adoc @@ -303,7 +303,7 @@ Aezeed:: in the recovery code, a reference to the date when the user created the wallet database; this allows a restoration process to find all of the funds associated with a wallet without scanning the entire - blockchain, which is especially useful for privacy-focused wallets. + blockchain, which is especially useful for privacy-focused lightweight clients. It includes support for changing the passphrase or changing other aspects of the recovery code without needing to move funds to a new seed--the user need only back up a new recovery code. One @@ -414,8 +414,9 @@ The most important data in a wallet database is its private keys. If you lose access to the private keys, you lose the ability to spend your bitcoins. Deterministic key derivation and recovery codes provide a reasonably robust solution for backing up and recovering your keys and -the bitcoins they control. But many wallet databases store more than -just keys. They also also store user-provided information about every +the bitcoins they control. However, it's important to consider that +many wallet databases store more than +just keys--they also also store user-provided information about every transaction they sent or received. For example, when Bob creates a new address as part of sending an @@ -499,7 +500,7 @@ even a small fraction of every possible key in a BIP32 tree, which means that recovering from data loss requires knowing more than just the recovery code, the algorithm for obtaining your seed (e.g. BIP39), and the deterministic key derivation algorithm -(e.g., BIP32)---it also requires knowing what paths in the tree of keys +(e.g., BIP32)--it also requires knowing what paths in the tree of keys your wallet application used for generating the specific keys it distributed. Two solutions to this problem have been adopted. The first is using @@ -592,7 +593,7 @@ A few example descriptors are shown in <>. | P2SH multi-signature requring two signatures corresponding to these two keys | pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*) -| P2PKH scripts for the BIP32 wallet with fingerprint d34db33f with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub. +| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub. |=== It has long been the trend for wallet applications designed only for @@ -899,18 +900,6 @@ combination with a carefully planned process for backup and recovery, considering the possibility of surviving the owner and allowing his or her family to recover the cryptocurrency estate. -===== Working with BIP39 recovery codes - -BIP39 is implemented as a library in many different programming -languages: - -https://github.com/trezor/python-mnemonic[python-mnemonic]:: The -reference implementation of the standard by the SatoshiLabs team that -proposed BIP39, in Python - -https://github.com/bitcoinjs/bip39[bitcoinjs/bip39]:: An implementation -of BIP39, as part of the popular bitcoinJS framework, in JavaScript - [[hd_wallet_details]] ==== Creating an HD Wallet from the Seed @@ -1077,7 +1066,7 @@ An extended public key can be used, therefore, to derive all of the _public_ keys (and only the public keys) in that branch of the HD wallet structure. -This shortcut can be used to create very secure public key-only +This shortcut can be used to create public key-only deployments where a server or application has a copy of an extended public key and no private keys whatsoever. That kind of deployment can produce an infinite number of public keys and Bitcoin addresses, but @@ -1162,17 +1151,17 @@ image::images/mbc2_0511.png["ChildPublicDerivation"] ==== Using an Extended Public Key on a Web Store ((("wallets", "technology of", "using extended public keys on web -stores")))Let's see how HD wallets are used by continuing our story with +stores")))Let's see how HD wallets are used by looking at Gabriel's web store.((("use cases", "web store", id="gabrielfivetwo"))) 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 order form with a single bitcoin address. -Gabriel used the first bitcoin address generated by his regular wallet as +Gabriel used the first Bitcoin address generated by his regular wallet as the main bitcoin address for his store. Customers would submit an order using the form and send payment to -Gabriel's published bitcoin address, triggering an email with the order +Gabriel's published Bitcoin address, triggering an email with the order details for Gabriel to process. With just a few orders each week, this system worked well enough, even though it weakened the privacy of Gabriel, his clients, and the people he paid. @@ -1351,7 +1340,7 @@ m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++. The third level of the tree is "account," which allows users to subdivide their wallets into separate logical subaccounts, for accounting or organizational purposes. For example, an HD wallet might -contain two bitcoin "accounts": m/44++'++/0++'++/0++'++ +contain two Bitcoin "accounts": m/44++'++/0++'++/0++'++ and m/44++'++/0++'++/1++'++. Each account is the root of its own subtree. @@ -1363,7 +1352,7 @@ normal derivation. This is to allow this level of the tree to export extended public keys for use in a nonsecured environment. Usable addresses are derived by the HD wallet as children of the fourth level, making the fifth level of the tree the "address_index." For example, the -third receiving address for bitcoin payments in the primary account +third receiving address for payments in the primary account would be M/44++'++/0++'++/0++'++/0/2. <> shows a few more examples.