arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-21 15:48:09 +00:00
Code Issues Releases Wiki Activity

PR and QC1

Browse Source
This commit is contained in:
Clare Laylock 2023-10-23 11:18:30 -04:00
parent ebbf5c9865
commit 74355b72a3
21 changed files with 414 additions and 429 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
appb_errata.adoc
View File

@ -19,7 +19,7 @@ witnessed, but proof that it came from the largest pool of CPU power."
____ ____
* *Implementation detail:* If each link in the chain (called "blocks" * *Implementation detail:* If each link in the chain (called "blocks"
in Bitcoin) was built using the same amount of proof of work (PoW), the in Bitcoin) was built using the same amount of _proof of work_ (PoW), the
longest chain would be the one backed by the largest pool of longest chain would be the one backed by the largest pool of
computational power. However, Bitcoin was implemented in such a way that computational power. However, Bitcoin was implemented in such a way that
the amount of PoW can vary between blocks, so it became important not to the amount of PoW can vary between blocks, so it became important not to
@ -37,7 +37,7 @@ occurred in July 2010, long after Bitcoin’s initial release:
+ if (pindexNew->bnChainWork > bnBestChainWork) + if (pindexNew->bnChainWork > bnBestChainWork)
---- ----
* *Terminology change:* General CPUs were used to generate the POW for * *Terminology change:* General CPUs were used to generate the POW for
the earliest Bitcoin blocks but POW generation today is mostly performed the earliest Bitcoin blocks, but POW generation today is mostly performed
by specialist Application Specific Integrated Circuits (ASICs), so by specialist Application Specific Integrated Circuits (ASICs), so
instead of saying "CPU power" it is perhaps more correct to say instead of saying "CPU power" it is perhaps more correct to say
"computational power" or, simply, "hash rate" for the hashing used "computational power" or, simply, "hash rate" for the hashing used
@ -56,7 +56,7 @@ called "miners" based on Nakamoto’s analogy to gold miners in section
6 of the paper. Nakamoto expected all miners to be nodes but the 6 of the paper. Nakamoto expected all miners to be nodes but the
software he released did not require all nodes to be miners. In the software he released did not require all nodes to be miners. In the
original software, a simple menu item in the node GUI allowed toggling original software, a simple menu item in the node GUI allowed toggling
the mining function or or off. the mining function on or off.
+ +
Today it is the case that the overwhelming number of nodes are not Today it is the case that the overwhelming number of nodes are not
miners and that many individuals who own mining hardware do not use it miners and that many individuals who own mining hardware do not use it
@ -77,7 +77,7 @@ known as the _selfish mining attack_ to allow an attacker with around
30% of total network hash rate to make other miners less profitable, 30% of total network hash rate to make other miners less profitable,
perhaps driving them into following the attacking miner’s policy. So perhaps driving them into following the attacking miner’s policy. So
instead of saying "a majority of CPU power is controlled by nodes that instead of saying "a majority of CPU power is controlled by nodes that
are not cooperating to attack the network" it is perhaps more correct are not cooperating to attack the network," it is perhaps more correct
to say "as long as nodes cooperating to attack the network control less to say "as long as nodes cooperating to attack the network control less
than about 30% of the network." than about 30% of the network."
@ -94,11 +94,11 @@ ____
this system where digital signatures are not used directly but rather a this system where digital signatures are not used directly but rather a
"deterministic expression" is used instead. Just as a signature that "deterministic expression" is used instead. Just as a signature that
matches a known public key can be used to enable a payment, the data matches a known public key can be used to enable a payment, the data
that satisfies an known expression can also enable a payment. that satisfies a known expression can also enable a payment.
Generically, the expression that must be satisfied in Bitcoin in order Generically, the expression that must be satisfied in Bitcoin in order
to spend a coin is known as an "encumbrance." Almost all encumbrances to spend a coin is known as an "encumbrance." Almost all encumbrances
in Bitcoin to date require providing at least one signature. So instead in Bitcoin to date require providing at least one signature. So instead
of saying "a chain of digital signatures" it is more correct to say of saying "a chain of digital signatures," it is more correct to say
"a chain of encumbrances." Given that transactions often have more "a chain of encumbrances." Given that transactions often have more
than one input and more than one output, the structure is not very than one input and more than one output, the structure is not very
chain-like; it’s more accurately described as a directed acyclic ((("transactions", "errata in Bitcoin whitepaper", startref="transaction-errata")))graph chain-like; it’s more accurately described as a directed acyclic ((("transactions", "errata in Bitcoin whitepaper", startref="transaction-errata")))graph
@ -185,7 +185,7 @@ the past.
____ ____
"Some linking((("privacy", "errata in Bitcoin whitepaper"))) is still unavoidable with multi-input transactions, which "Some linking((("privacy", "errata in Bitcoin whitepaper"))) is still unavoidable with multi-input transactions, which
necessarily reveal that their inputs were owned by the same owner" necessarily reveal that their inputs were owned by the same owner."
____ ____
* *Post-publication invention:* It isn't clear that different inputs * *Post-publication invention:* It isn't clear that different inputs
@ -197,7 +197,7 @@ toward paying Charlie and Dan than there is between just Alice
contributing two of her inputs toward paying Charlie and Dan. contributing two of her inputs toward paying Charlie and Dan.
+ +
This technique is known today as This technique is known today as
https://oreil.ly/UBEJX[CoinJoin] and software implementing https://oreil.ly/UBEJX[CoinJoin], and software implementing
it has been in use since 2015. it has been in use since 2015.
=== Calculations === Calculations

8
appc_bips.adoc
View File

@ -7,8 +7,8 @@ Bitcoin Improvement Proposals are design documents providing information to the
As per BIP1 _BIP Purpose and Guidelines_, there are three((("Bitcoin Improvement Proposals (BIPs)", "types of"))) kinds of BIPs: As per BIP1 _BIP Purpose and Guidelines_, there are three((("Bitcoin Improvement Proposals (BIPs)", "types of"))) 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. _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. _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. _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. 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.
BIPs are recorded in a https://oreil.ly/jjO0R[versioned repository on GitHub]. BIPs are recorded in a https://oreil.ly/jjO0R[versioned repository on GitHub].
An MIT-licensed document from the open source Bitcoin Core project, An MIT-licensed document from the open source Bitcoin Core project,
@ -18,7 +18,7 @@ significantly changed.
BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core: BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core:
- BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575) - BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575).
- BIP11: Multisig outputs are standard since v0.6.0 (PR #669). - BIP11: Multisig outputs are standard since v0.6.0 (PR #669).
- BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669). - BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669).
- BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669). - BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669).
@ -44,7 +44,7 @@ BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin
- BIP84: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP84. (PR #16528) - BIP84: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP84. (PR #16528)
- BIP86: Descriptor wallets by default use the Hierarchical Deterministic Wallet derivation proposed by BIP86 since v23.0 (PR #22364). - BIP86: Descriptor wallets by default use the Hierarchical Deterministic Wallet derivation proposed by BIP86 since v23.0 (PR #22364).
- BIP90: Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since v0.14.0 (PR #8391). - BIP90: Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since v0.14.0 (PR #8391).
- BIP111: NODE_BLOOM service bit added, and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641). - BIP111: NODE_BLOOM service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
- BIP112: The CHECKSEQUENCEVERIFY opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060). - BIP112: The CHECKSEQUENCEVERIFY opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
- BIP113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566), and has been buried since v0.19.0 (PR #16060). - BIP113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566), and has been buried since v0.19.0 (PR #16060).
- BIP125: Opt-in full replace-by-fee signaling partially implemented. See doc/policy/mempool-replacements.md. - BIP125: Opt-in full replace-by-fee signaling partially implemented. See doc/policy/mempool-replacements.md.

2
author_bio.html
View File

@ -5,7 +5,7 @@
<p>Andreas grew up with the internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in computer science, data communications, and distributed systems from University College London (UCL)—recently ranked among the world’s top 10 universities. After moving to the United States, Andreas cofounded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers, and cloud computing. More than 200 of his articles on security, cloud computing, and data centers have been published in print and syndicated worldwide. He holds two patents in networking and security.</p> <p>Andreas grew up with the internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in computer science, data communications, and distributed systems from University College London (UCL)—recently ranked among the world’s top 10 universities. After moving to the United States, Andreas cofounded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers, and cloud computing. More than 200 of his articles on security, cloud computing, and data centers have been published in print and syndicated worldwide. He holds two patents in networking and security.</p>
<p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p> <p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt, he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p>
<p>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.</p> <p>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.</p>

32
ch01_intro.adoc
View File

@ -83,9 +83,9 @@ In this chapter we'll get started by explaining some of the main concepts and te
The ((("digital currencies, history of")))((("history", "of digital currencies", secondary-sortas="digital currencies")))((("cryptography")))emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are: The ((("digital currencies, history of")))((("history", "of digital currencies", secondary-sortas="digital currencies")))((("cryptography")))emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
1. Can I trust that the money is authentic and not counterfeit? * Can I trust that the money is authentic and not counterfeit?
2. Can I trust that the digital money can only be spent once (known as the “double-spend” problem)? * Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
3. Can I be sure that no one else can claim this money belongs to them and not me? * Can I be sure that no one else can claim this money belongs to them and not me?
Issuers of paper money are constantly battling the counterfeiting problem by using increasingly sophisticated papers and printing technology. Physical money addresses the double-spend issue easily because the same paper note cannot be in two places at once. Of course, conventional money is also often stored and transmitted digitally. In these cases, the counterfeiting and double-spend issues are handled by clearing all electronic transactions through central authorities that have a global view of the currency in circulation. For digital money, which cannot take advantage of esoteric inks or holographic strips, cryptography provides the basis for trusting the legitimacy of a user’s claim to value. Specifically, cryptographic digital signatures enable a user to sign a digital asset or transaction proving the ownership of that asset. With the appropriate architecture, digital signatures also can be used to address the double-spend issue. Issuers of paper money are constantly battling the counterfeiting problem by using increasingly sophisticated papers and printing technology. Physical money addresses the double-spend issue easily because the same paper note cannot be in two places at once. Of course, conventional money is also often stored and transmitted digitally. In these cases, the counterfeiting and double-spend issues are handled by clearing all electronic transactions through central authorities that have a global view of the currency in circulation. For digital money, which cannot take advantage of esoteric inks or holographic strips, cryptography provides the basis for trusting the legitimacy of a user’s claim to value. Specifically, cryptographic digital signatures enable a user to sign a digital asset or transaction proving the ownership of that asset. With the appropriate architecture, digital signatures also can be used to address the double-spend issue.
@ -99,7 +99,7 @@ Although these earlier digital currencies worked, they were centralized and, as
Bitcoin was((("Bitcoin", "history of")))((("history", "of Bitcoin", secondary-sortas="Bitcoin")))((("Nakamoto, Satoshi"))) first described in 2008 with the publication of a Bitcoin was((("Bitcoin", "history of")))((("history", "of Bitcoin", secondary-sortas="Bitcoin")))((("Nakamoto, Satoshi"))) first described in 2008 with the publication of a
paper titled "Bitcoin: A Peer-to-Peer Electronic Cash paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System,"] System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System"],
Satoshi Nakamoto.] written under the Satoshi Nakamoto.] written under the
alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
combined several prior inventions such as digital signatures and Hashcash to create combined several prior inventions such as digital signatures and Hashcash to create
@ -153,12 +153,12 @@ derived from the original implementation written by Satoshi Nakamoto.
==== Choosing a Bitcoin Wallet ==== Choosing a Bitcoin Wallet
Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs. Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore, it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
===== Types of Bitcoin wallets ===== Types of Bitcoin wallets
Bitcoin wallets ((("wallets", "types of", id="wallet-type")))can be categorized as follows, according to the platform: Bitcoin wallets ((("wallets", "types of", id="wallet-type")))can be categorized as follows, according to the platform:
Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation and many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured. Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation. Many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured.
Mobile wallet:: A ((("mobile wallets")))mobile wallet is the most common type of Bitcoin Mobile wallet:: A ((("mobile wallets")))mobile wallet is the most common type of Bitcoin
wallet. Running on smart-phone operating systems such as Apple iOS and wallet. Running on smart-phone operating systems such as Apple iOS and
@ -212,7 +212,7 @@ creates outgoing transactions.
Third-party API client:: A third-party Third-party API client:: A third-party
API client ((("third-party API clients")))is one that interacts with Bitcoin through a third-party API client ((("third-party API clients")))is one that interacts with Bitcoin through a third-party
system of APIs, rather than by system of APIs rather than by
connecting to the Bitcoin network directly. The wallet may be stored by connecting to the Bitcoin network directly. The wallet may be stored by
the user or by third-party servers, but the client trusts the remote the user or by third-party servers, but the client trusts the remote
server to provide it with accurate information and protect its ((("wallets", "types of", startref="wallet-type")))privacy. server to provide it with accurate information and protect its ((("wallets", "types of", startref="wallet-type")))privacy.
@ -242,9 +242,7 @@ ultimately controls your funds on your behalf. Key management software falls int
important categories based on control: _wallets_, where you important categories based on control: _wallets_, where you
control the keys, and the funds and accounts with custodians where some control the keys, and the funds and accounts with custodians where some
third-party controls the keys. To emphasize this point, I (Andreas) third-party controls the keys. To emphasize this point, I (Andreas)
coined the phrase: coined the phrase: _Your keys, your coins. Not your keys, not your coins_.
_Your keys, your coins. Not your keys, not your coins_.
Combining these categorizations, many Bitcoin wallets fall into a few Combining these categorizations, many Bitcoin wallets fall into a few
groups, with the three most common being desktop full node groups, with the three most common being desktop full node
@ -275,8 +273,8 @@ to restore her wallet.
[[recovery_code_intro]] [[recovery_code_intro]]
==== Recovery Codes ==== Recovery Codes
Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a _recovery Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a recovery
code_ for their user code for their user
to back up. The recovery code usually consists of numbers, letters, or words to back up. The recovery code usually consists of numbers, letters, or words
selected randomly by the software, and is used as the basis for the keys selected randomly by the software, and is used as the basis for the keys
that are generated by the wallet. See <<recovery_code_sample>> for that are generated by the wallet. See <<recovery_code_sample>> for
@ -384,7 +382,7 @@ payment.
Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_ button, which displays a QR code, shown in <<wallet_receive>>. Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_ button, which displays a QR code, shown in <<wallet_receive>>.
[[wallet_receive]] [[wallet_receive]]
.Alice uses the Receive screen on her mobile Bitcoin wallet, and displays her address in a QR code format .Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format
image::images/mbc3_0101.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"] image::images/mbc3_0101.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"]
The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera. The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@ -429,7 +427,7 @@ many users choose to maintain dedicated exchange accounts independent from
their ((("bitcoins", "currency exchanges", startref="bitcoin-exchange")))((("currency exchanges", startref="currency-exchange")))wallets. their ((("bitcoins", "currency exchanges", startref="bitcoin-exchange")))((("currency exchanges", startref="currency-exchange")))wallets.
==== ====
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 ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))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 ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))wallet.
[[bitcoin_price]] [[bitcoin_price]]
==== Finding the Current Price of Bitcoin ==== Finding the Current Price of Bitcoin
@ -441,11 +439,11 @@ Bitcoin, like most other currencies, has a _floating exchange rate_. That means
There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular: 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]:: A site that provides a simple view of the volume-weighted-average for each currency. https://bitcoinaverage.com[Bitcoin Average]:: A site that provides a simple view of the volume-weighted average for each currency.
https://coincap.io[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of cryptocurrencies, including bitcoins. https://coincap.io[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of cryptocurrencies, including bitcoins.
https://oreil.ly/ACieC[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. https://oreil.ly/ACieC[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 In addition to these various sites and applications, some Bitcoin
wallets will automatically convert amounts between bitcoin and other((("bitcoins", "exchange rate", startref="bitcoin-exchange-rate")))((("exchange rate", startref="exchange-rate")))((("current price of bitcoins", startref="current-price"))) wallets will automatically convert amounts between bitcoin and other((("bitcoins", "exchange rate", startref="bitcoin-exchange-rate")))((("exchange rate", startref="exchange-rate")))((("current price of bitcoins", startref="current-price")))
currencies. currencies.
@ -484,7 +482,7 @@ amount, because he is about to transmit money and mistakes will soon become
irreversible. After double-checking the address and amount, he presses irreversible. After double-checking the address and amount, he presses
Send to transmit the transaction. Joe's mobile Bitcoin wallet constructs Send to transmit the transaction. Joe's mobile Bitcoin wallet constructs
a transaction that assigns 0.001 BTC to the address provided by Alice, a transaction that assigns 0.001 BTC to the address provided by Alice,
sourcing the funds from Joe's wallet and signing the transaction with sourcing the funds from Joe's wallet, and signing the transaction with
Joe's private keys. This tells the Bitcoin network that Joe has Joe's private keys. This tells the Bitcoin network that Joe has
authorized a transfer of value to Alice's new address. As the authorized a transfer of value to Alice's new address. As the
transaction is transmitted via the peer-to-peer protocol, it quickly transaction is transmitted via the peer-to-peer protocol, it quickly

41
ch02_overview.adoc
View File

@ -26,7 +26,7 @@ interactions between several users by sending
funds from one wallet to another. While tracking a transaction through funds from one wallet to another. While tracking a transaction through
the Bitcoin network to the blockchain, we will use a _blockchain the Bitcoin network to the blockchain, we will use a _blockchain
explorer_ site to visualize each step. A blockchain explorer is a web explorer_ site to visualize each step. A blockchain explorer is a web
application that operates as a bitcoin search engine, in that it allows application that operates as a Bitcoin search engine, in that it allows
you to search for addresses, transactions, and blocks and see the you to search for addresses, transactions, and blocks and see the
relationships and flows between them. relationships and flows between them.
@ -67,7 +67,7 @@ Alice, ((("transactions", "spending bitcoins", id="transaction-spend")))((("bitc
acquired her first bitcoins. In <<getting_first_bitcoin>>, Alice met with acquired her first bitcoins. In <<getting_first_bitcoin>>, Alice met with
her friend Joe to exchange some cash for bitcoins. Since then, Alice has her friend Joe to exchange some cash for bitcoins. Since then, Alice has
bought additional bitcoins. Now Alice will make bought additional bitcoins. Now Alice will make
her first spending 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 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
@ -75,7 +75,7 @@ the local currency (US dollars), but at checkout, customers have the
option of paying in either dollars or bitcoin. option of paying in either dollars or bitcoin.
Alice finds the podcast episode she wants to buy and proceeds to the checkout page. At checkout, Alice finds the podcast episode she wants to buy and proceeds to the checkout page. At checkout,
Alice is offered the option to pay with bitcoin, in addition to the Alice is offered the option to pay with bitcoin in addition to the
usual options. The checkout cart displays the price in US dollars and usual options. The checkout cart displays the price in US dollars and
also in bitcoin (BTC), at Bitcoin's prevailing exchange rate. also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.
@ -139,16 +139,7 @@ rules also apply to other bitcoin bookkeeping units, such as
millibitcoins and satoshis. millibitcoins and satoshis.
==== ====
You can examine Alice's transaction to Bob's Store on the blockchain You can use a block explorer to examine blockchain data, such as the payment made to Bob in Alice's((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) https://oreil.ly/hAeyh[transaction].
using((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) a block explorer site (<<view_alice_transaction>>).
[[view_alice_transaction]]
.View Alice's transaction on https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef[Blockstream Explorer]
====
----
https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef
----
====
In the following sections, we will examine this transaction in more In the following sections, we will examine this transaction in more
detail. We'll see how Alice's wallet constructed it, how it was detail. We'll see how Alice's wallet constructed it, how it was
@ -264,7 +255,7 @@ change output (and the address it pays, called a _change address_) and a
payment output. payment output.
Importantly, the change address does not have to be the Importantly, the change address does not have to be the
same address as that of the input and for privacy reasons is often a new same address as that of the input and, for privacy reasons, is often a new
address from the owner's wallet. In ideal circumstances, the two address from the owner's wallet. In ideal circumstances, the two
different uses of outputs both use never-before-seen addresses and different uses of outputs both use never-before-seen addresses and
otherwise look identical, preventing any third party from determining otherwise look identical, preventing any third party from determining
@ -273,17 +264,17 @@ illustration purposes, we've added shading to the change outputs in
<<transaction-chain>>. <<transaction-chain>>.
Not every transaction has a change output. Those that don't are ((("changeless transactions")))((("transactions", "changeless")))called Not every transaction has a change output. Those that don't are ((("changeless transactions")))((("transactions", "changeless")))called
_changeless transactions_ and they can have only a single output. _changeless transactions_, and they can have only a single output.
Changeless transactions are only a practical option if the amount being Changeless transactions are only a practical option if the amount being
spent is roughly the same as the amount available in the transaction spent is roughly the same as the amount available in the transaction
inputs minus the anticipated transaction fee. In <<transaction-chain>> inputs minus the anticipated transaction fee. In <<transaction-chain>>,
we see Bob creating Tx3 as a changeless transaction that spends the we see Bob creating Tx3 as a changeless transaction that spends the
output he ((("transactions", "change output", startref="transaction-change-output")))((("change output", startref="change-output")))((("outputs", "change output", startref="output-change")))received in Tx2. output he ((("transactions", "change output", startref="transaction-change-output")))((("change output", startref="change-output")))((("outputs", "change output", startref="output-change")))received in Tx2.
==== Coin Selection ==== Coin Selection
Different wallets((("transactions", "coin selection")))((("coin selection in transactions")))((("selecting", "coins in transactions"))) use different strategies when choosing which Different wallets((("transactions", "coin selection")))((("coin selection in transactions")))((("selecting", "coins in transactions"))) use different strategies when choosing which
inputs to se in a payment, called _coin selection_. inputs to use in a payment, called _coin selection_.
They might aggregate many small They might aggregate many small
inputs, or use one that is equal to or larger than the desired payment. inputs, or use one that is equal to or larger than the desired payment.
@ -348,9 +339,9 @@ wants to send to Bob. Most wallets keep track of all the available
outputs belonging to addresses in the wallet. Therefore, Alice's wallet outputs belonging to addresses in the wallet. Therefore, Alice's wallet
would contain a copy of the transaction output from Joe's transaction, would contain a copy of the transaction output from Joe's transaction,
which was created in exchange for cash (see <<getting_first_bitcoin>>). which was created in exchange for cash (see <<getting_first_bitcoin>>).
A bitcoin wallet application that runs on a full node actually A Bitcoin wallet application that runs on a full node actually
contains a copy of every confirmed transaction's ((("UTXOs (unspent transaction outputs)")))unspent outputs, called contains a copy of every confirmed transaction's ((("UTXOs (unspent transaction outputs)")))unspent outputs, called
_Unspent Transaction Outputs_ (UTXOs). _unspent transaction outputs_ (UTXOs).
However, because full nodes use more resources, many However, because full nodes use more resources, many
user wallets run lightweight clients that track only the user's own user wallets run lightweight clients that track only the user's own
UTXOs. UTXOs.
@ -358,7 +349,7 @@ UTXOs.
In this case, this single In this case, this single
UTXO is sufficient to pay for the podcast. Had this not been the case, UTXO is sufficient to pay for the podcast. Had this not been the case,
Alice's wallet application might have to combine several Alice's wallet application might have to combine several
smaller UTXOs, like picking coins from a purse until it could smaller UTXOs, like picking coins from a purse, until it could
find enough to pay for the podcast. In both cases, there might be a need find enough to pay for the podcast. In both cases, there might be a need
to get some change back, which we will see in the next section, as the to get some change back, which we will see in the next section, as the
wallet application creates the transaction outputs (payments). wallet application creates the transaction outputs (payments).
@ -375,7 +366,7 @@ address, only Bob's wallet can present such a signature to later spend this
output. Alice will therefore _encumber_ the output value with a demand output. Alice will therefore _encumber_ the output value with a demand
for a signature from Bob. for a signature from Bob.
This transaction will also include a second output, ((("change output")))because Alice's This transaction will also include a second output ((("change output")))because Alice's
funds contain more money than the cost of the funds contain more money than the cost of the
podcast. Alice's change podcast. Alice's change
output is created in the very same output is created in the very same
@ -386,7 +377,7 @@ then spend the change output in a subsequent transaction.
Finally, for the transaction to be processed by the network in a((("transaction fees"))) timely Finally, for the transaction to be processed by the network in a((("transaction fees"))) timely
fashion, Alice's wallet application will add a small fee. The fee is not 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 explicitly stated in the transaction; it is implied by the difference in value between
inputs and outputs. This _transaction fee_ is collected by the inputs and outputs. This transaction fee is collected by the
miner as a fee for including the transaction in a block miner as a fee for including the transaction in a block
that gets recorded on the blockchain. that gets recorded on the blockchain.
@ -501,7 +492,7 @@ Bitcoin users will accept the block with its transactions as a
valid block. If the output doesn't match the template, the miner makes valid block. If the output doesn't match the template, the miner makes
a small change to their candidate block and tries again. As of this 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 writing, the number of candidate blocks miners need to try before finding
a winning combination is about 168 billion trillions. That's also how a winning combination is about 168 billion trillion. That's also how
many times the hash function needs to be run. many times the hash function needs to be run.
However, once a winning combination has been found, anyone can verify However, once a winning combination has been found, anyone can verify
@ -628,8 +619,8 @@ look like <<block-alice2>>.
image::images/mbc3_0209.png["Alice's transaction as part of a transaction chain"] image::images/mbc3_0209.png["Alice's transaction as part of a transaction chain"]
In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value
from owner to owner. We also tracked Alice's transaction, from the from owner to owner. We also tracked Alice's transaction from the
moment it was created in her wallet, through the Bitcoin network and to moment it was created in her wallet, through the Bitcoin network, and to
the miners who recorded it on the blockchain. In the rest of this book, the miners who recorded it on the blockchain. In the rest of this book,
we will examine the specific technologies behind wallets, addresses, we will examine the specific technologies behind wallets, addresses,
signatures, transactions, the network, and finally, mining. signatures, transactions, the network, and finally, mining.

53
ch03_bitcoin-core.adoc
View File

@ -36,8 +36,8 @@ full time and several dozen more on a part-time basis. Anyone can
contribute to the code&#x2014;including you! contribute to the code&#x2014;including you!
When Bitcoin was created by Satoshi Nakamoto, the When Bitcoin was created by Satoshi Nakamoto, the
software was mostly completed before publication of the whitepaper reproduced in software was mostly completed before publication of the whitepaper (reproduced in
<<satoshi_whitepaper>>. Satoshi wanted to make sure the <<satoshi_whitepaper>>). Satoshi wanted to make sure the
implementation worked before publishing a paper about it. That first implementation, then simply implementation worked before publishing a paper about it. That first implementation, then simply
known as "Bitcoin," has been heavily modified and known as "Bitcoin," has been heavily modified and
improved. It has evolved into what is known as _Bitcoin Core_, to improved. It has evolved into what is known as _Bitcoin Core_, to
@ -83,17 +83,17 @@ source repository from GitHub. On the https://oreil.ly/hN9g1[Bitcoin Core downl
page], select the most recent version and download the compressed page], select the most recent version and download the compressed
archive of the source code. Alternatively, use the Git command line to create a archive of the source code. Alternatively, use the Git command line to create a
local copy of the source code from the local copy of the source code from the
https://oreil.ly/BdOwl[GitHub bitcoin page]. https://oreil.ly/BdOwl[GitHub Bitcoin page].
[TIP] [TIP]
==== ====
In In
many of the ((("command prompts")))((("shell command prompts")))examples in this chapter we will be using the operating many of the ((("command prompts")))((("shell command prompts")))examples in this chapter, we will be using the operating
system's command-line interface (also known as a "shell"), accessed via system's command-line interface (also known as a "shell"), accessed via
a "terminal" application. The shell will display a prompt, you type a a "terminal" application. The shell will display a prompt, you type a
command, and the shell responds with some text and a new prompt for your command, and the shell responds with some text and a new prompt for your
next command. The prompt may look different on your system, but in the next command. The prompt may look different on your system, but in the
following examples it is denoted by a +$+ symbol. In the examples, when following examples, it is denoted by a +$+ symbol. In the examples, when
you see text after a +$+ symbol, don't type the +$+ symbol but type the you see text after a +$+ symbol, don't type the +$+ symbol but type the
command immediately following it, then press Enter to execute the command immediately following it, then press Enter to execute the
command. In the examples, the lines below each command are the operating command. In the examples, the lines below each command are the operating
@ -318,7 +318,7 @@ cores if they are available. If all goes well, Bitcoin Core is now
compiled. You should run the unit test suite with +make check+ to ensure compiled. You should run the unit test suite with +make check+ to ensure
the linked libraries are not broken in obvious ways. The final step is the linked libraries are not broken in obvious ways. The final step is
to install the various executables on your system using the +make to install the various executables on your system using the +make
install+ command. You may be prompted for your user password, because install+ command. You may be prompted for your user password because
this step requires administrative privileges: this step requires administrative privileges:
---- ----
@ -487,10 +487,10 @@ inside the configuration file it refers to.
++datadir++:: Select((("datadir option (bitcoind command)"))) the directory and filesystem in which to put all the ++datadir++:: Select((("datadir option (bitcoind command)"))) the directory and filesystem in which to put all the
blockchain data. By default this is the _.bitcoin_ subdirectory of your blockchain data. By default this is the _.bitcoin_ subdirectory of your
home directory. Depending on your configuration, this can use from about 10 home directory. Depending on your configuration, this can use from about 10
gigabytes to almost 1 terabyte as of this writing, with the maximum size GB to almost 1 TB as of this writing, with the maximum size
expected to increase by several hundred gigabytes per year. expected to increase by several hundred gigabytes per year.
++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes, by ++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes by
deleting old blocks. Use this on a resource-constrained node that can't deleting old blocks. Use this on a resource-constrained node that can't
fit the full blockchain. Other parts of the system will use other disk fit the full blockchain. Other parts of the system will use other disk
space that can't currently be pruned, so you will still need at least space that can't currently be pruned, so you will still need at least
@ -500,7 +500,7 @@ the minimum amount of space mentioned in the +datadir+ option.
programmatically retrieve any transaction by its ID provided that the programmatically retrieve any transaction by its ID provided that the
block containing that transaction hasn't been pruned. block containing that transaction hasn't been pruned.
++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 MiB. Increase ++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 mebibytes (MiB). Increase
this size on high-end hardware to read and write from your disk less this size on high-end hardware to read and write from your disk less
often, or reduce the size on low-end hardware to save memory at the often, or reduce the size on low-end hardware to save memory at the
expense of using your disk more frequently. expense of using your disk more frequently.
@ -527,7 +527,7 @@ indexing, you need to
wait for it to rebuild the index. wait for it to rebuild the index.
**** ****
<<full_index_node>> shows how you might combine the preceding options, <<full_index_node>> shows how you might combine the preceding options
with a fully indexed node, running as an API backend for a bitcoin with a fully indexed node, running as an API backend for a bitcoin
application. application.
@ -582,7 +582,7 @@ $ bitcoind -printtoconsole
2023-01-28T03:43:39Z scheduler thread start 2023-01-28T03:43:39Z scheduler thread start
2023-01-28T03:43:39Z [http] creating work queue of depth 16 2023-01-28T03:43:39Z [http] creating work queue of depth 16
2023-01-28T03:43:39Z Using random cookie authentication. 2023-01-28T03:43:39Z Using random cookie authentication.
2023-01-28T03:43:39Z Generated RPC authentication cookie /lotsofspace/bitcoin/.cookie 2023-01-28T03:43:39Z Generated RPC cookie /lotsofspace/bitcoin/.cookie
2023-01-28T03:43:39Z [http] starting 4 worker threads 2023-01-28T03:43:39Z [http] starting 4 worker threads
2023-01-28T03:43:39Z Using wallet directory /lotsofspace/bitcoin/wallets 2023-01-28T03:43:39Z Using wallet directory /lotsofspace/bitcoin/wallets
2023-01-28T03:43:39Z init message: Verifying wallet(s)… 2023-01-28T03:43:39Z init message: Verifying wallet(s)…
@ -681,8 +681,8 @@ Result:
Examples: Examples:
> bitcoin-cli getblockhash 1000 > bitcoin-cli getblockhash 1000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", > curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest",
"method": "getblockhash", "method": "getblockhash",
"params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/ "params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
---- ----
At the end of the help information you will see two examples of the RPC At the end of the help information you will see two examples of the RPC
@ -774,7 +774,7 @@ on how many blocks your ((("Bitcoin Core", "command-line interface", "status inf
In <<spending_bitcoin>>, Alice ((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", id="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", id="command-transaction")))((("transactions", "exploring/decoding", id="transactions-explore-decode")))((("exploring", "transactions", id="explore-transaction")))((("decoding", "transactions", id="decode-transaction")))made a purchase from Bob's store. Her In <<spending_bitcoin>>, Alice ((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", id="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", id="command-transaction")))((("transactions", "exploring/decoding", id="transactions-explore-decode")))((("exploring", "transactions", id="explore-transaction")))((("decoding", "transactions", id="decode-transaction")))made a purchase from Bob's store. Her
transaction was recorded on the blockchain. transaction was recorded on the blockchain.
Let's use the API to retrieve and examine that transaction by passing Let's use the API to retrieve and examine that transaction by passing
the txid as a parameter: the transaction ID (txid) as a parameter:
[[alice_tx_serialized]] [[alice_tx_serialized]]
.Alice's serialized transaction .Alice's serialized transaction
@ -882,7 +882,7 @@ Bob and the change back to Alice.
We can further explore the blockchain by examining the previous We can further explore the blockchain by examining the previous
transaction referenced by its +txid+ in this transaction using the same transaction referenced by its +txid+ in this transaction using the same
commands (e.g., +getrawtransaction+). Jumping from transaction to commands (e.g., +getrawtransaction+). Jumping from transaction to
transaction we can follow a chain of transactions back as the coins are transaction, we can follow a chain of transactions back as the coins are
transmitted from one owner to the((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", startref="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", startref="command-transaction")))((("transactions", "exploring/decoding", startref="transactions-explore-decode")))((("exploring", "transactions", startref="explore-transaction")))((("decoding", "transactions", startref="decode-transaction"))) next. transmitted from one owner to the((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", startref="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", startref="command-transaction")))((("transactions", "exploring/decoding", startref="transactions-explore-decode")))((("exploring", "transactions", startref="explore-transaction")))((("decoding", "transactions", startref="decode-transaction"))) next.
==== Exploring Blocks ==== Exploring Blocks
@ -928,7 +928,7 @@ f6cd83c3ca
"difficulty": 157416.4018436489, "difficulty": 157416.4018436489,
"chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc", "chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
"nTx": 13, "nTx": 13,
"previousblockhash": "[...]000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095", "previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
"nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66", "nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
"strippedsize": 4179, "strippedsize": 4179,
"size": 4179, "size": 4179,
@ -968,8 +968,7 @@ we'll examine those ((("Bitcoin Core", "command-line interface", "exploring bloc
The The
+bitcoin-cli+ helper is ((("Bitcoin Core", "command-line interface", "API access", id="bitcoin-core-command-api")))((("command-line interface (Bitcoin Core)", "API access", id="command-api")))((("API access", id="api")))very useful for exploring the Bitcoin Core API +bitcoin-cli+ helper is ((("Bitcoin Core", "command-line interface", "API access", id="bitcoin-core-command-api")))((("command-line interface (Bitcoin Core)", "API access", id="command-api")))((("API access", id="api")))very useful for exploring the Bitcoin Core API
and testing functions. But the whole point of an application programming and testing functions. But the whole point of an API is to access functions programmatically. In this section we
interface is to access functions programmatically. In this section we
will demonstrate accessing Bitcoin Core from another program. will demonstrate accessing Bitcoin Core from another program.
Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript
@ -985,8 +984,8 @@ client to construct one of these JSON-RPC calls:
---- ----
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", $ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest",
"method": "getblockchaininfo", "method": "getblockchaininfo",
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/ "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
---- ----
This command shows that +curl+ submits an HTTP request to the local host This command shows that +curl+ submits an HTTP request to the local host
@ -1006,13 +1005,13 @@ any higher-level Bitcoin Core RPC wrappers), ((("Bitcoin Core", "authentication"
==== ====
---- ----
$ cat .bitcoin/.cookie $ cat .bitcoin/.cookie
__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
$ curl $ curl
--user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
--data-binary '{"jsonrpc": "1.0", "id":"curltest", --data-binary '{"jsonrpc": "1.0", "id":"curltest",
"method": "getblockchaininfo", "method": "getblockchaininfo",
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/ "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
{"result":{"chain":"main","blocks":799278,"headers":799278, {"result":{"chain":"main","blocks":799278,"headers":799278,
"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879", "bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879",
@ -1150,7 +1149,7 @@ https://oreil.ly/xn_rg[python-bitcoinlib]:: A ((("Python toolkits")))((("python
https://oreil.ly/wcpXP[pycoin]:: A Python bitcoin library by Richard Kiss https://oreil.ly/wcpXP[pycoin]:: A Python bitcoin library by Richard Kiss
==== Go ==== Go
https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language full-node Bitcoin client https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language, full-node Bitcoin client
==== Rust ==== Rust
https://oreil.ly/me6gf[rust-bitcoin]:: Rust ((("Rust toolkits")))((("rust-bitcoin")))bitcoin library for serialization, parsing, and API calls https://oreil.ly/me6gf[rust-bitcoin]:: Rust ((("Rust toolkits")))((("rust-bitcoin")))bitcoin library for serialization, parsing, and API calls
@ -1161,7 +1160,7 @@ https://bitcoin-s.org[bitcoin-s]:: A ((("Scala toolkits")))((("bitcoin-s")))Bitc
==== C# ==== C#
https://oreil.ly/Qfjgq[NBitcoin]:: Comprehensive((("C# toolkits")))((("NBitcoin"))) bitcoin library for the .NET framework https://oreil.ly/Qfjgq[NBitcoin]:: Comprehensive((("C# toolkits")))((("NBitcoin"))) bitcoin library for the .NET framework
Many more libraries exist in a variety of other programming languages Many more libraries exist in a variety of other programming languages,
and more are created all the time. and more are created all the time.
If you followed the instructions in this chapter, you now have Bitcoin If you followed the instructions in this chapter, you now have Bitcoin

88
ch04_keys.adoc
View File

@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
those goals, shown in <<pay-to-pure-pubkey>>. A receiver like Bob those goals, shown in <<pay-to-pure-pubkey>>. A receiver like Bob
accepts bitcoins to a public key in a transaction that is signed by the accepts bitcoins to a public key in a transaction that is signed by the
spender (like Alice). The bitcoins that Alice is spending had been spender (like Alice). The bitcoins that Alice is spending had been
previously received to one her public keys, and she uses the previously received to one of her public keys, and she uses the
corresponding private key to generate her signature. Full nodes can corresponding private key to generate her signature. Full nodes can
verify that Alice's signature commits to the output of a hash function verify that Alice's signature commits to the output of a hash function
that itself commits to Bob's public key and other transaction details. that itself commits to Bob's public key and other transaction details.
@ -93,10 +93,10 @@ over the private key is the root of user control over all funds
associated with the corresponding Bitcoin public key. The private key is associated with the corresponding Bitcoin public key. The private key is
used to create signatures that are used to spend bitcoins 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 control of funds used in a transaction. The private key must remain
secret at all times, because revealing it to third parties is equivalent 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 to giving them control over the bitcoins secured by that key. The private
key must also be backed up and protected from accidental loss, because key must also be backed up and protected from accidental loss because
if it's lost it cannot be recovered and the funds secured by it are if it's lost, it cannot be recovered and the funds secured by it are
forever lost too. forever lost too.
[TIP] [TIP]
@ -119,7 +119,7 @@ number generators to produce 256 bits of entropy.
More precisely, the private key can be any number between +0+ and +n - More precisely, the private key can be any number between +0+ and +n -
1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less 1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
than 2^256^) defined as the order of the elliptic curve used in bitcoin than 2^256^) defined as the order of the elliptic curve used in Bitcoin
(see <<elliptic_curve>>). To create such a key, we randomly pick a (see <<elliptic_curve>>). To create such a key, we randomly pick a
256-bit number and check that it is less than +n+. In programming terms, 256-bit number and check that it is less than +n+. In programming terms,
this is usually achieved by feeding a larger string of random bits, this is usually achieved by feeding a larger string of random bits,
@ -150,7 +150,7 @@ bits):
[TIP] [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 large number. It is approximately 10^77^ in decimal. For comparison, the
visible universe is estimated to((("private keys", "generating", startref="private-key-generate"))) contain 10^80^ atoms. visible universe is estimated to((("private keys", "generating", startref="private-key-generate"))) contain 10^80^ atoms.
==== ====
@ -268,7 +268,7 @@ interest to points on the curve with two integer coordinates!
In some cases (i.e., if P~1~ and P~2~ have the same x values but In some cases (i.e., if P~1~ and P~2~ have the same x values but
different y values), the tangent line will be exactly vertical, in which different y values), the tangent line will be exactly vertical, in which
case P3 = "point at infinity." case P~3~ = "point at infinity."
If P~1~ is the "point at infinity," then P~1~ + P~2~ = P~2~. Similarly, If P~1~ is the "point at infinity," then P~1~ + P~2~ = P~2~. Similarly,
if P~2~ is the point at infinity, then P~1~ + P~2~ = P~1~. This shows if P~2~ is the point at infinity, then P~1~ + P~2~ = P~1~. This shows
@ -292,7 +292,7 @@ irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
constant point called the _generator point_, and _K_ is the resulting constant point called the _generator point_, and _K_ is the resulting
public key. The reverse operation, known as "finding the discrete public key. The reverse operation, known as "finding the discrete
logarithm"—calculating _k_ if you know __K__—is as difficult as trying logarithm"—calculating _k_ if you know __K__—is as difficult as trying
all possible values of _k_, i.e., a brute-force search. Before we all possible values of _k_ (i.e., a brute-force search). Before we
demonstrate how to generate a public key from a private key, let's look demonstrate how to generate a public key from a private key, let's look
at elliptic curve cryptography in a bit more detail. at elliptic curve cryptography in a bit more detail.
@ -325,9 +325,9 @@ bitcoin:
where _k_ is the private key, _G_ is the generator point, and _K_ is the where _k_ is the private key, _G_ is the generator point, and _K_ is the
resulting public key, a point on the curve. Because the generator point resulting public key, a point on the curve. Because the generator point
is always the same for all bitcoin users, a private key _k_ multiplied is always the same for all Bitcoin users, a private key _k_ multiplied
with _G_ will always result in the same public key _K_. The relationship with _G_ will always result in the same public key _K_. The relationship
between _k_ and _K_ is fixed, but can only be calculated in one between _k_ and _K_ is fixed but can only be calculated in one
direction, from _k_ to _K_. That's why a Bitcoin public key can be direction, from _k_ to _K_. That's why a Bitcoin public key can be
shared with anyone and does not reveal the user's private key (_k_). shared with anyone and does not reveal the user's private key (_k_).
@ -339,7 +339,7 @@ one way.
==== ====
Implementing the elliptic curve multiplication, we take the private key Implementing the elliptic curve multiplication, we take the private key
_k_ generated previously and multiply it with the generator point G to _k_ generated previously and multiply it with the generator point _G_ to
find the public key _K_: find the public key _K_:
[source, python] [source, python]
@ -533,11 +533,11 @@ was the exact same key that was used to create that earlier commitment.
The SHA256 hash function is considered to be very secure and produces The SHA256 hash function is considered to be very secure and produces
256 bits (32 bytes) of output, less than half the size of original 256 bits (32 bytes) of output, less than half the size of original
Bitcoin public keys. However, there are other slightly less secure hash Bitcoin public keys. However, there are other slightly less secure hash
functions that produce smaller output, such as the ((("RIPEMD160 hash function")))RIPEMD160 hash functions that produce smaller output, such as the ((("RIPEMD-160 hash function")))RIPEMD-160 hash
function whose output is 160 bits (20 bytes). For reasons Satoshi function whose output is 160 bits (20 bytes). For reasons Satoshi
Nakamoto never stated, the original version of Bitcoin made commitments Nakamoto never stated, the original version of Bitcoin made commitments
to public keys by first hashing the key with SHA256 and then hashing to public keys by first hashing the key with SHA256 and then hashing
that output with RIPEMD160; this produced a 20-byte commitment to the that output with RIPEMD-160; this produced a 20-byte commitment to the
public key. public key.
We can look at that algorithmically. We can look at that algorithmically.
@ -754,15 +754,14 @@ When ((("public key cryptography", "compressed public keys", id="pub-key-compres
alternative encoding for public keys that used only 33 bytes and which alternative encoding for public keys that used only 33 bytes and which
was backward compatible with all Bitcoin full nodes at the time, was backward compatible with all Bitcoin full nodes at the time,
so there was no need to change the Bitcoin protocol. Those 33-byte so there was no need to change the Bitcoin protocol. Those 33-byte
public keys are known as _compressed public keys_ and the original 65 public keys are known as _compressed public keys_, and the original 65-byte keys are known as _uncompressed public keys_. Using smaller public keys
byte keys are known as _uncompressed public keys_. Using smaller public keys
results in smaller transactions, allowing more payments to be made in the same results in smaller transactions, allowing more payments to be made in the same
block. block.
As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an
elliptic curve. Because the curve expresses a mathematical function, a elliptic curve. Because the curve expresses a mathematical function, a
point on the curve represents a solution to the equation and, therefore, point on the curve represents a solution to the equation and, therefore,
if we know the _x_ coordinate we can calculate the _y_ coordinate by if we know the _x_ coordinate, we can calculate the _y_ coordinate by
solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to
store only the _x_ coordinate of the public key point, omitting the _y_ store only the _x_ coordinate of the public key point, omitting the _y_
coordinate and reducing the size of the key and the space required to coordinate and reducing the size of the key and the space required to
@ -796,8 +795,8 @@ positive or negative value. Visually, this means that the resulting _y_
coordinate can be above or below the x-axis. As you can see from the coordinate can be above or below the x-axis. As you can see from the
graph of the elliptic curve in <<ecc-curve>>, the curve is symmetric, graph of the elliptic curve in <<ecc-curve>>, the curve is symmetric,
meaning it is reflected like a mirror by the x-axis. So, while we can meaning it is reflected like a mirror by the x-axis. So, while we can
omit the _y_ coordinate we have to store the _sign_ of _y_ (positive or omit the _y_ coordinate, we have to store the _sign_ of _y_ (positive or
negative); or in other words, we have to remember if it was above or negative); in other words, we have to remember if it was above or
below the x-axis because each of those options represents a different below the x-axis because each of those options represents a different
point and a different public key. When calculating the elliptic curve in point and a different public key. When calculating the elliptic curve in
binary arithmetic on the finite field of prime order p, the _y_ binary arithmetic on the finite field of prime order p, the _y_
@ -821,9 +820,9 @@ This compressed public key corresponds to the same private key, meaning
it is generated from the same private key. However, it looks different it is generated from the same private key. However, it looks different
from the uncompressed public key. More importantly, if we convert this from the uncompressed public key. More importantly, if we convert this
compressed public key to a commitment using the HASH160 compressed public key to a commitment using the HASH160
function (+RIPEMD160(SHA256(K))+) it will produce a _different_ function (+RIPEMD160(SHA256(K))+), it will produce a _different_
commitment than the uncompressed public key, leading to a different commitment than the uncompressed public key, leading to a different
address. This can be confusing, because it means that a single private address. This can be confusing because it means that a single private
key can produce a public key expressed in two different formats key can produce a public key expressed in two different formats
(compressed and uncompressed) that produce two different Bitcoin (compressed and uncompressed) that produce two different Bitcoin
addresses. However, the private key is identical for both Bitcoin addresses. However, the private key is identical for both Bitcoin
@ -835,7 +834,7 @@ addresses.
image::images/mbc3_0408.png["pubkey_compression"] image::images/mbc3_0408.png["pubkey_compression"]
Compressed public keys are now the default in almost all Bitcoin Compressed public keys are now the default in almost all Bitcoin
software, and were made required when using certain new features added software and were required when using certain new features added
in later protocol upgrades. in later protocol upgrades.
However, some software still needs to support uncompressed public keys, However, some software still needs to support uncompressed public keys,
@ -847,7 +846,7 @@ to scan for the correct type can lead to the user not being able to
spend their full balance. To resolve this issue, when private keys are spend their full balance. To resolve this issue, when private keys are
exported from a wallet, the WIF that is used to exported from a wallet, the WIF that is used to
represent them is implemented slightly differently in newer Bitcoin represent them is implemented slightly differently in newer Bitcoin
wallets, to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key"))) wallets to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key")))
compressed public keys. compressed public keys.
[[addresses_for_p2sh]] [[addresses_for_p2sh]]
@ -962,7 +961,7 @@ the HASH160 algorithm. This is((("second preimage attacks"))) a _second preimag
However, this changes when an attacker is able to influence the original input However, this changes when an attacker is able to influence the original input
value. For example, an attacker participates in the creation of a value. For example, an attacker participates in the creation of a
multisignature script where tthey don't need to submit their public key until after they learn all of the other partys' public keys. multisignature script where they don't need to submit their public key until after they learn all of the other partys' public keys.
In that case, the strength of hash algorithm is reduced to its square In that case, the strength of hash algorithm is reduced to its square
root. For HASH160, the probability becomes 1-in-2^80^. This is a root. For HASH160, the probability becomes 1-in-2^80^. This is a
_collision attack_. _collision attack_.
@ -985,9 +984,9 @@ processes involving multiple parties, which could make the attack
profitable. profitable.
There are well-established cryptographic protocols for preventing There are well-established cryptographic protocols for preventing
collision attacks but a simple solution that doesn't require any collision attacks, but a simple solution that doesn't require any
special knowledge on the part of wallet developers is to simply use special knowledge on the part of wallet developers is to simply use
a stronger hash function. Later upgrades to Bitcoin made that possible a stronger hash function. Later upgrades to Bitcoin made that possible,
and newer Bitcoin addresses provide at least 128 bits of collision and newer Bitcoin addresses provide at least 128 bits of collision
resistance. To perform 2^128^ hash operations would take all current resistance. To perform 2^128^ hash operations would take all current
Bitcoin miners about 32 billion years. Bitcoin miners about 32 billion years.
@ -1028,7 +1027,7 @@ identified several problems((("public key cryptography", "base58check encoding")
- Its mixed-case presentation made it inconvenient to read aloud or - Its mixed-case presentation made it inconvenient to read aloud or
transcribe. Try reading one of the legacy addresses in this chapter transcribe. Try reading one of the legacy addresses in this chapter
to a friend who you have transcribe it. Notice how you have to prefix to a friend who you have transcribe it. Notice how you have to prefix
every letter with the words "uppercase" and "lowercase." Also note every letter with the words "uppercase" and "lowercase." Also, note
when you review their writing that the uppercase and lowercase when you review their writing that the uppercase and lowercase
versions of some letters can look similar in many people's versions of some letters can look similar in many people's
handwriting. handwriting.
@ -1173,20 +1172,20 @@ time in a billion.
//https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb //https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb
The version of bech32 with a single different constant is known as The version of bech32 with a single different constant is known as
Bech32 Modified (bech32m). All of the characters in bech32 and bech32m bech32 modified (bech32m). All of the characters in bech32 and bech32m
addresses for the same underlying data will be identical except for the addresses for the same underlying data will be identical except for the
last six (the checksum). That means a wallet will need to know which last six (the checksum). That means a wallet will need to know which
version is in use in order to validate the checksum, but both address version is in use in order to validate the checksum, but both address
types contain an internal version byte that makes determining that easy. types contain an internal version byte that makes determining that easy.
===== Encoding and Decoding bech32m addresses
In this((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) section, we'll look at the encoding and parsing rules for
To work with both bech32 and((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) bech32m, we'll look at the encoding and parsing rules for
bech32m Bitcoin addresses since they encompass the ability to parse bech32m Bitcoin addresses since they encompass the ability to parse
bech32 addresses and are the current recommended address format for bech32 addresses and are the current recommended address format for
Bitcoin wallets. Bitcoin wallets.
Bech32m addresses start with a Human Readable Part (HRP). There are Bech32m addresses start with a human readable part (HRP). There are
rules in BIP173 for creating your own HRPs, but for Bitcoin you only rules in BIP173 for creating your own HRPs, but for Bitcoin you only
need to know about the HRPs already chosen, shown in need to know about the HRPs already chosen, shown in
<<bech32_hrps_for_bitcoin>>. <<bech32_hrps_for_bitcoin>>.
@ -1284,19 +1283,19 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
<tbody> <tbody>
<tr> <tr>
<td><p>P2WPKH</p></td> <td><p>P2WPKH</p></td>
<td><p>OP_0 2b626ed108ad00a944bb2922a309844611d25468</p></td> <td><p><code>OP_0 2b626ed108ad00a944bb2922a309844611d25468</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>P2WSH</p></td> <td><p>P2WSH</p></td>
<td><p>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</p></td> <td><p><code>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>P2TR</p></td> <td><p>P2TR</p></td>
<td><p>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</p></td> <td><p><code>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>Future Example</p></td> <td><p>Future Example</p></td>
<td><p>OP_16 0000</p></td> <td><p><code>OP_16 0000</code></p></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
@ -1314,7 +1313,7 @@ the script, pass it into a SHA256 hash function, and use the 32-byte
digest of that function in the witness program. For P2SH, the SHA256 digest of that function in the witness program. For P2SH, the SHA256
digest was hashed again with RIPEMD-160, but that may not be secure in digest was hashed again with RIPEMD-160, but that may not be secure in
some cases; for details, see <<p2sh_collision_attacks>>. A result of some cases; for details, see <<p2sh_collision_attacks>>. A result of
using SHA256 without RIPEMD160 is that P2WSH commitments are 32 bytes using SHA256 without RIPEMD-160 is that P2WSH commitments are 32 bytes
(256 bits) instead 20 bytes (160 bits). (256 bits) instead 20 bytes (160 bits).
For the pay-to-taproot (P2TR) output, the witness program is a point on For the pay-to-taproot (P2TR) output, the witness program is a point on
@ -1328,12 +1327,12 @@ program (2 bytes) with a null value.
Now that we know the version number and the witness program, we can Now that we know the version number and the witness program, we can
convert each of them into a bech32 address. Let's use the bech32m reference convert each of them into a bech32 address. Let's use the bech32m reference
library for Python to quickly generate those addresses, and then take a library for Python to quickly generate those addresses and then take a
deeper look at what's happening: deeper look at what's happening:
---- ----
$ github="https://raw.githubusercontent.com" $ github="https://raw.githubusercontent.com"
$ wget $github//sipa/bech32/master/ref/python/segwit_addr.py $ wget $github/sipa/bech32/master/ref/python/segwit_addr.py
$ python $ python
>>> from segwit_addr import * >>> from segwit_addr import *
@ -1385,7 +1384,8 @@ decode(hrp, addr)
>>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee") >>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee")
>>> _[0], bytes(_[1]).hex() >>> _[0], bytes(_[1]).hex()
(0, '2b626ed108ad00a944bb2922a309844611d25468') (0, '2b626ed108ad00a944bb2922a309844611d25468')
>>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7") >>> _ = decode("bc",
"bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
>>> _[0], bytes(_[1]).hex() >>> _[0], bytes(_[1]).hex()
(1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311') (1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
---- ----
@ -1523,7 +1523,7 @@ can easily be converted to any other((("private keys", "formats", startref="priv
==== Compressed Private Keys ==== Compressed Private Keys
The commonly((("private keys", "compressed", id="private-key-compress")))((("compressed private keys", id="compress-private-key"))) used term "compressed private key" is a misnomer, because when a private The commonly((("private keys", "compressed", id="private-key-compress")))((("compressed private keys", id="compress-private-key"))) used term "compressed private key" is a misnomer, because when a private
key is exported as WIF-compressed it is actually one byte _longer_ than key is exported as WIF-compressed, it is actually one byte _longer_ than
an "uncompressed" private key. That is because the private key has an an "uncompressed" private key. That is because the private key has an
added one-byte suffix (shown as 01 in hex in <<table_4-4>>), which added one-byte suffix (shown as 01 in hex in <<table_4-4>>), which
signifies that the private key is from a newer wallet and should only be signifies that the private key is from a newer wallet and should only be
@ -1596,8 +1596,8 @@ addresses and those will be used in transactions. When exporting private
keys from a new wallet that implements compressed public keys, the WIF keys from a new wallet that implements compressed public keys, the WIF
is modified, with the addition of a one-byte suffix +01+ to the private is modified, with the addition of a one-byte suffix +01+ to the private
key. The resulting base58check-encoded private key is called a key. The resulting base58check-encoded private key is called a
"compressed WIF" and starts with the letter _K_ or _L_, instead of "compressed WIF" and starts with the letter _K_ or _L_ instead of
starting with "5" as is the case with WIF-encoded (uncompressed) keys starting with "5," as is the case with WIF-encoded (uncompressed) keys
from((("private keys", "compressed", startref="private-key-compress")))((("compressed private keys", startref="compress-private-key"))) older wallets. from((("private keys", "compressed", startref="private-key-compress")))((("compressed private keys", startref="compress-private-key"))) older wallets.
=== Advanced Keys and Addresses === Advanced Keys and Addresses
@ -1613,7 +1613,7 @@ addresses that contain human-readable messages. For example,
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
the letters forming the word "Love" as the first four base58 letters. the letters forming the word "Love" as the first four base58 letters.
Vanity addresses require generating and testing billions of candidate Vanity addresses require generating and testing billions of candidate
private keys, until a Bitcoin address with the desired pattern is found. private keys until a Bitcoin address with the desired pattern is found.
Although there are some optimizations in the vanity generation Although there are some optimizations in the vanity generation
algorithm, the process essentially involves picking a private key at algorithm, the process essentially involves picking a private key at
random, deriving the public key, deriving the Bitcoin address, and random, deriving the public key, deriving the Bitcoin address, and
@ -1767,7 +1767,7 @@ As you can see, Eugenia won't be creating the vanity address
computers. Each additional character increases the difficulty by a computers. Each additional character increases the difficulty by a
factor of 58. Patterns with more than seven characters are usually found factor of 58. Patterns with more than seven characters are usually found
by specialized hardware, such as custom-built desktops with multiple by specialized hardware, such as custom-built desktops with multiple
GPUs. graphics processing units (GPUs).
Vanity searches on GPU systems are many orders of magnitude Vanity searches on GPU systems are many orders of magnitude
faster than on a general-purpose CPU. faster than on a general-purpose CPU.
@ -1842,7 +1842,7 @@ image::images/mbc3_0410.png[]
Some are intended to be given as gifts and have seasonal themes, such as Some are intended to be given as gifts and have seasonal themes, such as
Christmas and New Year's. Others are designed for storage in a Christmas and New Year's. Others are designed for storage in a
bank vault or safe with the private key hidden in some way, either with bank vault or safe with the private key hidden in some way, either with
opaque scratch-off stickers, or folded and sealed with tamper-proof opaque scratch-off stickers or folded and sealed with tamper-proof
adhesive foil. Other designs feature additional copies of the key and adhesive foil. Other designs feature additional copies of the key and
address, in the form of detachable stubs similar to ticket stubs, address, in the form of detachable stubs similar to ticket stubs,
allowing you to store multiple copies to protect against fire, flood, or allowing you to store multiple copies to protect against fire, flood, or

58
ch05_wallets.adoc
View File

@ -72,7 +72,7 @@ be able to predict the new output--not even if they know the new input.
This allows us to take one random value and transform it into a This allows us to take one random value and transform it into a
practically unlimited number of seemingly random values. Even more practically unlimited number of seemingly random values. Even more
usefully, later using the same hash function with the same ((("seeds")))input useful, later using the same hash function with the same ((("seeds")))input
(called a _seed_) will produce the same seemingly random values: (called a _seed_) will produce the same seemingly random values:
---- ----
@ -160,7 +160,7 @@ that corresponds to the public child key Bob created.
In other words, it's possible to create child public keys even if you In other words, it's possible to create child public keys even if you
don't know anything about the parent private key. The value added to a don't know anything about the parent private key. The value added to a
public key is ((("key tweaks")))known as a _key tweak._ If a deterministic algorithm is public key is ((("key tweaks")))known as a _key tweak._ If a deterministic algorithm is
used for generating the key tweaks, then it's possible to for someone used for generating the key tweaks, then it's possible for someone
who doesn't know the private key to create an essentially unlimited who doesn't know the private key to create an essentially unlimited
sequence of public child keys from a single public parent key. The sequence of public child keys from a single public parent key. The
person who controls the private parent key can then use the same key person who controls the private parent key can then use the same key
@ -179,7 +179,7 @@ transactions to the less-secure frontend for broadcast to the Bitcoin
network. network.
Public child key derivation can produce a linear sequence of keys Public child key derivation can produce a linear sequence of keys
similar to the previously seen <<Type1_wallet>>, but modern wallets similar to the previously seen <<Type1_wallet>>, but modern wallet
applications use one more trick to provide a tree of keys instead a applications use one more trick to provide a tree of keys instead a
single sequence, as described in the((("wallets", "key generation", "public child key derivation", startref="wallet-keygen-public-child")))((("key generation", "public child key derivation", startref="keygen-public-child")))((("public child key derivation", startref="public-child-derive")))((("child key pair derivation", startref="child-key-pair"))) following section. single sequence, as described in the((("wallets", "key generation", "public child key derivation", startref="wallet-keygen-public-child")))((("key generation", "public child key derivation", startref="keygen-public-child")))((("public child key derivation", startref="public-child-derive")))((("child key pair derivation", startref="child-key-pair"))) following section.
@ -278,7 +278,7 @@ BIP39::
adding a checksum to it, and encoding the data into a series of 12 to adding a checksum to it, and encoding the data into a series of 12 to
24 words (which may be localized to a user's native language). The 24 words (which may be localized to a user's native language). The
words (plus an optional passphrase) are run through a _key-stretching words (plus an optional passphrase) are run through a _key-stretching
function_ and the output is used as a seed. BIP39 recovery codes have function_, and the output is used as a seed. BIP39 recovery codes have
several shortcomings, which later schemes attempt to address. several shortcomings, which later schemes attempt to address.
Electrum v2:: Electrum v2::
@ -299,7 +299,7 @@ Aezeed::
cryptographic properties of the recovery code. cryptographic properties of the recovery code.
It also includes a _wallet birthday_ It also includes a _wallet birthday_
in the recovery code, a reference to the date when the user created 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 wallet database. This allows a restoration process to find all of
the funds associated with a wallet without scanning the entire the funds associated with a wallet without scanning the entire
blockchain, which is especially useful for privacy-focused lightweight clients. blockchain, which is especially useful for privacy-focused lightweight clients.
It includes support for changing the passphrase or changing other It includes support for changing the passphrase or changing other
@ -318,7 +318,7 @@ Muun::
Although this is unwieldy compared to the BIP39, Electrum v2, and Although this is unwieldy compared to the BIP39, Electrum v2, and
Aezeed recovery codes, it provides support for new technologies and Aezeed recovery codes, it provides support for new technologies and
standards that are becoming more common in new wallets, such as standards that are becoming more common in new wallets, such as
Lightning Network support, output script descriptors, and miniscript. Lightning Network (LN) support, output script descriptors, and miniscript.
SLIP39:: SLIP39::
A successor ((("SLIP39 recovery codes")))to BIP39 with some of the same authors, SLIP39 allows A successor ((("SLIP39 recovery codes")))to BIP39 with some of the same authors, SLIP39 allows
@ -467,12 +467,12 @@ amount of every transaction listed but a blank entry for the
Wallets should provide their users with a convenient way to back up Wallets should provide their users with a convenient way to back up
label data. That seems obvious, but there are a number of label data. That seems obvious, but there are a number of
widely used wallet applications that make it easy to create and use widely used wallet applications that make it easy to create and use
recovery codes but which provide no way to back up or restore label recovery codes but that provide no way to back up or restore label
data. data.
Additionally, it may be useful for wallet applications to provide a Additionally, it may be useful for wallet applications to provide a
standardized format to export labels so that they can be used in other standardized format to export labels so that they can be used in other
applications, e.g., accounting software. A standard for that ((("labels, backing up", startref="label-backup")))format is applications (e.g., accounting software). A standard for that ((("labels, backing up", startref="label-backup")))format is
proposed in BIP329. proposed in BIP329.
Wallet applications implementing additional protocols beyond basic Wallet applications implementing additional protocols beyond basic
@ -507,7 +507,7 @@ and additional ((("wallets", "nonkey data, backing up", startref="wallet-nonkey-
==== Backing Up Key Derivation Paths ==== Backing Up Key Derivation Paths
In a ((("wallets", "key generation", "backing up derivation paths", id="wallet-keygen-backups")))((("key generation", "backing up derivation paths", id="keygen-backups")))((("backing up", "key derivation paths", id="backup-key-derive")))BIP32 tree of keys, there are approximately four billion first-level In a ((("wallets", "key generation", "backing up derivation paths", id="wallet-keygen-backups")))((("key generation", "backing up derivation paths", id="keygen-backups")))((("backing up", "key derivation paths", id="backup-key-derive")))BIP32 tree of keys, there are approximately four billion first-level
keys and each of those keys can have its own four billion children, with keys; each of those keys can have its own four billion children, with
those children each potentially having four billion children of their those children each potentially having four billion children of their
own, and so on. It's not possible for a wallet application to generate own, and so on. It's not possible for a wallet application to generate
even a small fraction of every possible key in a BIP32 tree, which means even a small fraction of every possible key in a BIP32 tree, which means
@ -611,7 +611,7 @@ included directly. Their disadvantage is that they require users to back
up additional information along with their recovery code. The up additional information along with their recovery code. The
additional information usually can't compromise a user's security, so it additional information usually can't compromise a user's security, so it
doesn't require as much protection as the recovery code, although it can doesn't require as much protection as the recovery code, although it can
reduce their privacy and so does require some protection. reduce their privacy and does require some protection.
Almost all wallet applications that use explicit paths as of this Almost all wallet applications that use explicit paths as of this
writing use the _output script descriptors_ standard (called writing use the _output script descriptors_ standard (called
@ -660,14 +660,14 @@ Developers of modern wallets can choose from a variety of different
technologies to help users create and use backups--and new solutions technologies to help users create and use backups--and new solutions
appear every year. Instead of going into detail about each of the appear every year. Instead of going into detail about each of the
options we described earlier in this chapter, we'll focus the rest of options we described earlier in this chapter, we'll focus the rest of
this chapter on the stack of technologies that we think is most widely this chapter on the stack of technologies we think is most widely
used in wallets as of early 2023: used in wallets as of early 2023:
- BIP39 recovery codes - BIP39 recovery codes
- BIP32 hierarchical deterministic (HD) key derivation - BIP32 HD key derivation
- BIP44-style implicit paths - BIP44-style implicit paths
All of these standards have been around since 2014 or earlier and All of these standards have been around since 2014 or earlier, and
you'll have no problem finding additional resources for using them. you'll have no problem finding additional resources for using them.
However, if you're feeling bold, we do encourage you to investigate more However, if you're feeling bold, we do encourage you to investigate more
modern standards that may provide additional features or safety. modern standards that may provide additional features or safety.
@ -678,7 +678,7 @@ modern standards that may provide additional features or safety.
BIP39 ((("wallets", "recovery codes", id="wallet-recovery-bip39")))((("recovery codes", id="recovery-code-bip39")))((("BIP39 recovery codes", id="bip39-recovery")))recovery codes are word BIP39 ((("wallets", "recovery codes", id="wallet-recovery-bip39")))((("recovery codes", id="recovery-code-bip39")))((("BIP39 recovery codes", id="bip39-recovery")))recovery codes are word
sequences that represent (encode) a random number used as a seed to sequences that represent (encode) a random number used as a seed to
derive a deterministic wallet. The sequence of words is sufficient to derive a deterministic wallet. The sequence of words is sufficient to
re-create the seed and from there re-create all the re-create the seed and from there, re-create all the
derived keys. A wallet application that implements deterministic wallets derived keys. A wallet application that implements deterministic wallets
with a BIP39 recovery code will show the user a sequence of 12 to 24 words when with a BIP39 recovery code will show the user a sequence of 12 to 24 words when
first creating a wallet. That sequence of words is the wallet backup and first creating a wallet. That sequence of words is the wallet backup and
@ -693,7 +693,7 @@ Recovery codes((("brainwallets"))) are often confused with
"brainwallets." They are not the same. The primary difference is that a "brainwallets." They are not the same. The primary difference is that a
brainwallet consists of words chosen by the user, whereas recovery codes brainwallet consists of words chosen by the user, whereas recovery codes
are created randomly by the wallet and presented to the user. This are created randomly by the wallet and presented to the user. This
important difference makes recovery codes much more secure, because important difference makes recovery codes much more secure because
humans are very poor sources of randomness. humans are very poor sources of randomness.
==== ====
@ -902,7 +902,7 @@ some examples of recovery codes and the seeds ((("key-stretching functions", sta
</tbody> </tbody>
</table> </table>
<table id="bip39_256_no_pass"> <table id="bip39_256_no_pass">
<caption><span class="label">Table 5-7. </span>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption> <caption>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
<tbody> <tbody>
<tr> <tr>
<td><p><strong>Entropy input (256 bits)</strong></p></td> <td><p><strong>Entropy input (256 bits)</strong></p></td>
@ -966,7 +966,7 @@ greater the entropy, the harder it will be for them to figure out part
of the code they didn't see. For example, if an attacker sees half of a of the code they didn't see. For example, if an attacker sees half of a
128-bit code (64 bits), it's plausible that they'll be able to brute 128-bit code (64 bits), it's plausible that they'll be able to brute
force the remaining 64 bits. If they see half of a 256-bit code (128 force the remaining 64 bits. If they see half of a 256-bit code (128
bits), it's not plausible that they can brute force the other half. We bits), it's not plausible they can brute force the other half. We
don't recommend relying on this defense--either keep your recovery codes don't recommend relying on this defense--either keep your recovery codes
very safe or use a method like SLIP39 that lets you distribute your very safe or use a method like SLIP39 that lets you distribute your
recovery code across multiple locations without relying on the safety of recovery code across multiple locations without relying on the safety of
@ -1026,7 +1026,7 @@ her family to recover the cryptocurrency((("wallets", "recovery codes", startref
HD wallets ((("wallets", "key generation", "HD (hierarchical deterministic)", id="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", id="keygen-hd")))((("HD (hierarchical deterministic) key generation", id="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", id="bip32")))((("seeds", "HD wallet creation", id="seed-hdwallet")))are created from a ((("root seeds")))single _root seed_, which is a HD wallets ((("wallets", "key generation", "HD (hierarchical deterministic)", id="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", id="keygen-hd")))((("HD (hierarchical deterministic) key generation", id="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", id="bip32")))((("seeds", "HD wallet creation", id="seed-hdwallet")))are created from a ((("root seeds")))single _root seed_, which is a
128-, 256-, or 512-bit random number. Most commonly, this seed is 128-, 256-, or 512-bit random number. Most commonly, this seed is
generated by or decrypted from a _recovery code_ as detailed in the previous section. generated by or decrypted from a recovery code as detailed in the previous section.
Every key in the HD wallet is deterministically derived from this root Every key in the HD wallet is deterministically derived from this root
seed, which makes it possible to re-create the entire HD wallet from seed, which makes it possible to re-create the entire HD wallet from
@ -1068,7 +1068,7 @@ that combines:
The chain code is used to introduce deterministic random data to the The chain code is used to introduce deterministic random data to the
process, so that knowing the index and a child key is not sufficient to process, so that knowing the index and a child key is not sufficient to
derive other child keys. Knowing a child key does not make it possible derive other child keys. Knowing a child key does not make it possible
to find its siblings, unless you also have the chain code. The initial to find its siblings unless you also have the chain code. The initial
chain code seed (at the root of the tree) is made from the seed, while chain code seed (at the root of the tree) is made from the seed, while
subsequent child chain codes are derived from each parent chain code. subsequent child chain codes are derived from each parent chain code.
@ -1089,7 +1089,7 @@ parent.
image::images/mbc3_0507.png["ChildPrivateDerivation"] image::images/mbc3_0507.png["ChildPrivateDerivation"]
Changing the index allows us to extend the parent and create the other Changing the index allows us to extend the parent and create the other
children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each children in the sequence (e.g., Child 0, Child 1, Child 2, etc.). Each
parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the
entire 2^32^ range available because the other half is reserved for a entire 2^32^ range available because the other half is reserved for a
special type of derivation we will talk about later in this chapter). special type of derivation we will talk about later in this chapter).
@ -1177,9 +1177,9 @@ LrtJunSDMstweyLXhRgPxdp14sk9tJPW9
As As
mentioned previously, ((("key generation", "HD (hierarchical deterministic)", "public child key derivation", id="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", id="hd-keygen-public-child")))((("public child key derivation", id="public-child")))((("child key pair derivation", "public keys", id="child-key-pair-public")))a very useful characteristic of HD wallets is the mentioned previously, ((("key generation", "HD (hierarchical deterministic)", "public child key derivation", id="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", id="hd-keygen-public-child")))((("public child key derivation", id="public-child")))((("child key pair derivation", "public keys", id="child-key-pair-public")))a very useful characteristic of HD wallets is the
ability to derive public child keys from public parent keys, _without_ ability to derive public child keys from public parent keys _without_
having the private keys. This gives us two ways to derive a child public having the private keys. This gives us two ways to derive a child public
key: either from the child private key, or directly from the parent key: either from the child private key or directly from the parent
public key. public key.
An extended public key can be used, therefore, to derive all of the An extended public key can be used, therefore, to derive all of the
@ -1189,7 +1189,7 @@ structure.
This shortcut can be used to create 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 deployments where a server or application has a copy of an extended
public key and no private keys whatsoever. That kind of deployment can public key and no private keys whatsoever. That kind of deployment can
produce an infinite number of public keys and Bitcoin addresses, but produce an infinite number of public keys and Bitcoin addresses but
cannot spend any of the money sent to those addresses. Meanwhile, on cannot spend any of the money sent to those addresses. Meanwhile, on
another, more secure server, the extended private key can derive all the another, more secure server, the extended private key can derive all the
corresponding private keys to sign transactions and spend the money. corresponding private keys to sign transactions and spend the money.
@ -1359,9 +1359,9 @@ a "gap" in the tree above the level where extended public keys are used.
In simple terms, if you want to use the convenience of an xpub to derive In simple terms, if you want to use the convenience of an xpub to derive
branches of public keys, without exposing yourself to the risk of a branches of public keys, without exposing yourself to the risk of a
leaked chain code, you should derive it from a hardened parent, rather leaked chain code, you should derive it from a hardened parent rather
than a normal parent. As a best practice, the level-1 children of the than a normal parent. As a best practice, the level-1 children of the
master keys are always derived through the hardened derivation, to master keys are always derived through the hardened derivation to
prevent compromise of the master keys. prevent compromise of the master keys.
===== Index numbers for normal and hardened derivation ===== Index numbers for normal and hardened derivation
@ -1445,7 +1445,7 @@ extended key can have 4 billion children: 2 billion normal children and
billion children, and so on. The tree can be as deep as you want, with billion children, and so on. The tree can be as deep as you want, with
an infinite number of generations. With all that flexibility, however, an infinite number of generations. With all that flexibility, however,
it becomes quite difficult to navigate this infinite tree. It is it becomes quite difficult to navigate this infinite tree. It is
especially difficult to transfer HD wallets between implementations, especially difficult to transfer HD wallets between implementations
because the possibilities for internal organization into branches and because the possibilities for internal organization into branches and
subbranches are endless. subbranches are endless.
@ -1456,7 +1456,7 @@ the "purpose" of the tree structure. Based on BIP43, an HD wallet
should use only one level-1 branch of the tree, with the index number should use only one level-1 branch of the tree, with the index number
identifying the structure and namespace of the rest of the tree by identifying the structure and namespace of the rest of the tree by
defining its purpose. For example, an HD wallet using only branch defining its purpose. For example, an HD wallet using only branch
m/i++&#x27;++/ is intended to signify a specific purpose and that m/i++&#x27;++/ is intended to signify a specific purpose, and that
purpose is identified by index number "i." purpose is identified by index number "i."
Extending that specification, ((("BIP44 HD wallet tree structure", id="bip44")))BIP44 proposes a multiaccount structure Extending that specification, ((("BIP44 HD wallet tree structure", id="bip44")))BIP44 proposes a multiaccount structure
@ -1474,10 +1474,10 @@ The first-level "purpose" is always set to +44'+. The second-level
"coin_type" specifies the type of cryptocurrency coin, allowing for "coin_type" specifies the type of cryptocurrency coin, allowing for
multicurrency HD wallets where each currency has its own subtree under multicurrency HD wallets where each currency has its own subtree under
the second level. Bitcoin is the second level. Bitcoin is
m/44'/0' and Bitcoin Testnet is m/44++&#x27;++/1++&#x27;++. m/44'/0' and Bitcoin Testnet is m/44++&#x27;++/1++'++.
The third level of the tree is "account," which allows users to The third level of the tree is "account," which allows users to
subdivide their wallets into separate logical subaccounts, for subdivide their wallets into separate logical subaccounts for
accounting or organizational purposes. For example, an HD wallet might accounting or organizational purposes. For example, an HD wallet might
contain two Bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++ contain two Bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++
and m/44++&#x27;++/0++&#x27;++/1++&#x27;++. Each account is the root of and m/44++&#x27;++/0++&#x27;++/1++&#x27;++. Each account is the root of

44
ch06_transactions.adoc
View File

@ -54,7 +54,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
Bitcoin Core's serialization format is special because it's the format Bitcoin Core's serialization format is special because it's the format
used to make commitments to transactions and to relay them across used to make commitments to transactions and to relay them across
Bitcoin's peer-to-peer (P2P) network, but otherwise programs can use Bitcoin's P2P network, but otherwise programs can use
a different format as long as they transmit all of the a different format as long as they transmit all of the
same data. However, Bitcoin Core's format is reasonably compact for the same data. However, Bitcoin Core's format is reasonably compact for the
data it transmits and simple to parse, so many other Bitcoin programs data it transmits and simple to parse, so many other Bitcoin programs
@ -62,12 +62,12 @@ use this format.
[TIP] [TIP]
==== ====
The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format of that The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format that
we're aware of is the partially signed bitcoin transaction (PSBT) format we're aware of is the partially signed bitcoin transaction (PSBT) format
documented in BIPs 174 and 370 (with extensions documented in other documented in BIPs 174 and 370 (with extensions documented in other
BIPs). PSBT allows an untrusted program to produce a transaction BIPs). PSBT allows an untrusted program to produce a transaction
template that can be verified and updated by trusted programs (such as template that can be verified and updated by trusted programs (such as
hardware signing devices) that possesses the necessary private keys or hardware signing devices) that have the necessary private keys or
other sensitive data to fill in the template. To accomplish this, PSBT other sensitive data to fill in the template. To accomplish this, PSBT
allows storing a significant amount of metadata about a transaction, allows storing a significant amount of metadata about a transaction,
making it much less compact than the standard serialization format. making it much less compact than the standard serialization format.
@ -135,7 +135,7 @@ If you implement a protocol that uses presigned transactions, ensure
that it doesn't use any features that are reserved for future upgrades. that it doesn't use any features that are reserved for future upgrades.
Bitcoin Core's default transaction relay policy does not allow the use Bitcoin Core's default transaction relay policy does not allow the use
of reserved features. You can test whether a transaction complies with of reserved features. You can test whether a transaction complies with
that policy by using the Bitcoin Core RPC +testmempoolaccept+ on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin that policy by using Bitcoin Core's +testmempoolaccept+ RPC on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
mainnet. mainnet.
**** ****
@ -143,8 +143,8 @@ As of this writing, a proposal to begin using version 3 transactions is
being widely considered. That proposal does not seek to change the being widely considered. That proposal does not seek to change the
consensus rules but only the policy that Bitcoin full nodes use to relay consensus rules but only the policy that Bitcoin full nodes use to relay
transactions. Under the proposal, version 3 transactions would be transactions. Under the proposal, version 3 transactions would be
subject to additional constraints in order to prevent certain Denial of subject to additional constraints in order to prevent certain denial of
Service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>. service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>.
=== Extended Marker and Flag === Extended Marker and Flag
@ -262,7 +262,7 @@ Each input in a transaction must contain three fields:
We'll look at each of those fields in the following sections. Some We'll look at each of those fields in the following sections. Some
inputs also include a witness stack, but this is serialized at the end of a inputs also include a witness stack, but this is serialized at the end of a
transaction and so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later. transaction so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later.
[[outpoints]] [[outpoints]]
@ -347,7 +347,7 @@ txid from the outpoint in our example transaction:
eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a
---- ----
If we try using that that txid to retrieve that transaction using If we try using that txid to retrieve that transaction using
Bitcoin Core, we get an error and must reverse its byte order: Bitcoin Core, we get an error and must reverse its byte order:
---- ----
@ -371,7 +371,7 @@ This odd behavior is probably an unintentional consequence of a
https://oreil.ly/01JH2[design https://oreil.ly/01JH2[design
decision in early Bitcoin software]. As a practical matter, it means decision in early Bitcoin software]. As a practical matter, it means
developers of Bitcoin software need to remember to reverse the order of developers of Bitcoin software need to remember to reverse the order of
bytes in transaction and block identifiers that they show to users. bytes in transaction and block identifiers they show to users.
In this book, we use the term _internal byte order_ for the data that In this book, we use the term _internal byte order_ for the data that
appears within transactions and blocks. We use _display byte order_ for appears within transactions and blocks. We use _display byte order_ for
@ -486,7 +486,7 @@ isn't a very effective protocol.
The third problem was that it was possible to replace one version of a The third problem was that it was possible to replace one version of a
transaction with a different version an unlimited number of transaction with a different version an unlimited number of
times. Each replacement would consume the bandwidth of all the relaying full nodes times. Each replacement would consume the bandwidth of all the relaying full nodes
on the network. For example, as of this writing there are about 50,000 on the network. For example, as of this writing, there are about 50,000
relaying full nodes; an attacker creating 1,000 replacement transactions relaying full nodes; an attacker creating 1,000 replacement transactions
per minute at 200 bytes each would use about 20 kilobytes of their per minute at 200 bytes each would use about 20 kilobytes of their
personal bandwidth but about 10 gigabytes of full node network bandwidth personal bandwidth but about 10 gigabytes of full node network bandwidth
@ -546,7 +546,7 @@ Since sequence is a per-input field, a transaction may contain any
number of timelocked inputs, all of which must have sufficiently aged number of timelocked inputs, all of which must have sufficiently aged
for the transaction to be valid. A disable flag allows a transaction to for the transaction to be valid. A disable flag allows a transaction to
include both inputs with a relative timelock (sequence < 2^31^) and include both inputs with a relative timelock (sequence < 2^31^) and
inputs without a relative timelock (sequence >= 2^31^). inputs without a relative timelock (sequence ≥ 2^31^).
The sequence value is specified in either blocks or seconds. The sequence value is specified in either blocks or seconds.
A type-flag A type-flag
@ -573,7 +573,7 @@ as defined by BIP68.
.BIP68 definition of sequence encoding (Source: BIP68) .BIP68 definition of sequence encoding (Source: BIP68)
image::images/mbc3_0603.png["BIP68 definition of sequence encoding"] image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
Note that any transaction which sets a relative timelock using sequence Note that any transaction that sets a relative timelock using sequence
also sends the signal for opt-in replace by fee ((("transactions", "inputs", startref="transaction-input")))((("inputs", startref="input-transaction")))((("transactions", "inputs", "sequence field", startref="transaction-input-sequence")))((("inputs", "sequence field", startref="input-transaction-sequence")))((("sequence field (transaction inputs)", startref="sequence-field")))((("relative timelocks", startref="relative-timelock")))as described in also sends the signal for opt-in replace by fee ((("transactions", "inputs", startref="transaction-input")))((("inputs", startref="input-transaction")))((("transactions", "inputs", "sequence field", startref="transaction-input-sequence")))((("inputs", "sequence field", startref="input-transaction-sequence")))((("sequence field (transaction inputs)", startref="sequence-field")))((("relative timelocks", startref="relative-timelock")))as described in
<<sequence-bip125>>. <<sequence-bip125>>.
@ -626,7 +626,7 @@ contribute any value to a transaction spending it even if the
transaction's fee rate was zero. However, many other outputs with low transaction's fee rate was zero. However, many other outputs with low
values can be uneconomical as well, even unintentionally. For example, values can be uneconomical as well, even unintentionally. For example,
at a typical fee rate on the network today, an output might add more at a typical fee rate on the network today, an output might add more
value to a transaction than it costs to spend--but, tomorrow, fee rates value to a transaction than it costs to spend--but tomorrow, fee rates
might rise and make the output uneconomical. might rise and make the output uneconomical.
The need for full nodes to keep track of all unspent transaction outputs The need for full nodes to keep track of all unspent transaction outputs
@ -685,7 +685,7 @@ satoshis aren't being ((("transactions", "outputs", "amount field", startref="tr
The ((("transactions", "outputs", "output scripts", id="transaction-output-script")))((("outputs", "output scripts", id="output-transaction-script")))((("output scripts", id="output-script2")))output amount is followed by a compactSize integer indicating the The ((("transactions", "outputs", "output scripts", id="transaction-output-script")))((("outputs", "output scripts", id="output-transaction-script")))((("output scripts", id="output-script2")))output amount is followed by a compactSize integer indicating the
length of the _output script_, the script that contains the length of the _output script_, the script that contains the
conditions which will need to be fulfilled in order to spend the conditions that will need to be fulfilled in order to spend the
bitcoins. According to Bitcoin's bitcoins. According to Bitcoin's
consensus rules, the minimum size of an output script is zero. consensus rules, the minimum size of an output script is zero.
@ -703,7 +703,7 @@ the block containing it.
An output script with zero length can be spent by an input script containing An output script with zero length can be spent by an input script containing
++OP_TRUE++. Anyone can create that input script, which means anyone ++OP_TRUE++. Anyone can create that input script, which means anyone
can spend an empty output script. There are an essentially unlimited can spend an empty output script. There are an essentially unlimited
number of scripts that anyone can spend and they are known to Bitcoin number of scripts that anyone can spend, and they are known to Bitcoin
protocol developers as _anyone can spends_. Upgrades to Bitcoin's protocol developers as _anyone can spends_. Upgrades to Bitcoin's
script language often take an existing anyone-can-spend script and add script language often take an existing anyone-can-spend script and add
new constraints to it, making it only spendable under the new new constraints to it, making it only spendable under the new
@ -719,7 +719,7 @@ transaction outputs_. This was originally implemented after the
discovery of several early bugs in Bitcoin related to the Script discovery of several early bugs in Bitcoin related to the Script
language and is retained in modern Bitcoin Core to support language and is retained in modern Bitcoin Core to support
anyone-can-spend upgrades and to encourage the best practice of placing anyone-can-spend upgrades and to encourage the best practice of placing
script conditions in P2SH redeem script, segwit v0 witness scripts, and script conditions in P2SH redeem scripts, segwit v0 witness scripts, and
segwit v1 (taproot) leaf scripts. segwit v1 (taproot) leaf scripts.
We'll look at each of the current standard transaction templates and We'll look at each of the current standard transaction templates and
@ -736,7 +736,7 @@ accept evidence from those who are reliable.
Imagine what a witness would look like for a math problem. For example, 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 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 mathematical proof that showed a value that could be summed with two to
equal four. We could even omit the need for a person and just use the equal four. We could even omit the need for a person and just use the
proposed value for _x_ as our witness. If we were told that the witness proposed value for _x_ as our witness. If we were told that the witness
was _two_, then we could fill in the equation, check that it was correct, and was _two_, then we could fill in the equation, check that it was correct, and
@ -757,7 +757,7 @@ protected by the following script:
Obviously, allowing your bitcoins to be spent by anyone who can solve a Obviously, allowing your bitcoins to be spent by anyone who can solve a
simple equation wouldn't be secure. As we'll see in <<c_signatures>>, an simple equation wouldn't be secure. As we'll see in <<c_signatures>>, an
unforgeable digital signature scheme uses an equation that can only be unforgeable digital signature scheme uses an equation that can only be
solved by someone in possession of certain data that they're able to solved by someone in possession of certain data they're able to
keep secret. They're able to reference that secret data using a public keep secret. They're able to reference that secret data using a public
identifier. That public identifier is ((("public keys")))((("digital signatures")))((("signatures", see="digital signatures")))called a _public key_ and a identifier. That public identifier is ((("public keys")))((("digital signatures")))((("signatures", see="digital signatures")))called a _public key_ and a
solution to the equation is called a _signature_. solution to the equation is called a _signature_.
@ -797,7 +797,7 @@ transactions out of order:
- If Alice and Bob sign Tx~1~ before they sign Tx~0~, then they're both - If Alice and Bob sign Tx~1~ before they sign Tx~0~, then they're both
guaranteed to be able to get a refund at any time. The protocol guaranteed to be able to get a refund at any time. The protocol
doesn't require either of them trust the other, making ((("trustless protocols")))it a _trustless doesn't require either of them to trust the other, making ((("trustless protocols")))it a _trustless
protocol_. protocol_.
A problem with this construction in the legacy transaction format is A problem with this construction in the legacy transaction format is
@ -882,7 +882,7 @@ developers worked on proposals to minimize third-party malleability,
such as BIP62. However, even if they were able to entirely eliminate such as BIP62. However, even if they were able to entirely eliminate
third-party malleability, users of contract protocols faced another problem: third-party malleability, users of contract protocols faced another problem:
if they required a signature from someone else involved in the protocol, if they required a signature from someone else involved in the protocol,
that person could generate alternative signatures and so change the txid. that person could generate alternative signatures and change the txid.
For example, Alice and Bob have deposited their money into a script For example, Alice and Bob have deposited their money into a script
requiring a signature from both of them to spend. They've also created requiring a signature from both of them to spend. They've also created
@ -1030,7 +1030,7 @@ items_. We'll explore them in detail in
each witness item is prefixed by a compactSize integer indicating its each witness item is prefixed by a compactSize integer indicating its
size. size.
Legacy inputs don't contain any witness items so their witness stack Legacy inputs don't contain any witness items, so their witness stack
consists entirely of a count of zero (0x00). consists entirely of a count of zero (0x00).
Alice's transaction contains one input and one ((("transactions", "witnesses", startref="transaction-witness")))((("witnesses", startref="witness")))((("transactions", "witnesses", "count", startref="transaction-witness-count")))((("witnesses", "count", startref="witness-count")))witness item. Alice's transaction contains one input and one ((("transactions", "witnesses", startref="transaction-witness")))((("witnesses", startref="witness")))((("transactions", "witnesses", "count", startref="transaction-witness-count")))((("witnesses", "count", startref="witness-count")))witness item.
@ -1039,7 +1039,7 @@ Alice's transaction contains one input and one ((("transactions", "witnesses", s
=== Lock Time === Lock Time
The ((("transactions", "lock time")))((("lock time")))final field in a serialized transaction is its lock time. This The ((("transactions", "lock time")))((("lock time")))final field in a serialized transaction is its lock time. This
field was part of Bitcoin's original serialization format but it was field was part of Bitcoin's original serialization format, but it was
initially only enforced by Bitcoin's policy for choosing which initially only enforced by Bitcoin's policy for choosing which
transactions to mine. Bitcoin's earliest known soft fork added a rule transactions to mine. Bitcoin's earliest known soft fork added a rule
that, starting at block height 31,000, forbid the inclusion of a that, starting at block height 31,000, forbid the inclusion of a

91
ch07_authorization-authentication.adoc
View File

@ -7,7 +7,7 @@ nodes will distinguish the authorized spenders from everyone else,
called _authentication_. Your authorization instructions and the called _authentication_. Your authorization instructions and the
spender proof of authentication will be checked by thousands of spender proof of authentication will be checked by thousands of
independent full nodes, which all need to come to the same conclusion independent full nodes, which all need to come to the same conclusion
that a spend was authorized and authentic in order for the transaction that a spend was authorized and authenticated in order for the transaction
containing it to be valid. containing it to be valid.
The original description of Bitcoin used a public key for authorization. The original description of Bitcoin used a public key for authorization.
@ -51,7 +51,7 @@ conditions for spending and how those conditions can be satisfied.
[TIP] [TIP]
==== ====
Bitcoin transaction validation((("transactions", "validating")))((("validating", "transactions"))) is not based on Bitcoin transaction validation((("transactions", "validating")))((("validating", "transactions"))) is not based on
a static pattern, but instead is achieved through the execution of a a static pattern but instead is achieved through the execution of a
scripting language. This language allows for a nearly infinite variety scripting language. This language allows for a nearly infinite variety
of conditions to be expressed. of conditions to be expressed.
==== ====
@ -75,7 +75,7 @@ validation mechanism from being used as a vulnerability.
==== Stateless Verification ==== Stateless Verification
The ((("scripts", "stateless verification")))((("stateless script verification")))((("verifying", "scripts")))Bitcoin transaction script language is The ((("scripts", "stateless verification")))((("stateless script verification")))((("verifying", "scripts")))Bitcoin transaction script language is
stateless, in that there is no state prior to execution of the script, stateless, in that there is no state prior to execution of the script
or state saved after execution of the script. All the or state saved after execution of the script. All the
information needed to execute a script is contained within the script information needed to execute a script is contained within the script
and the transaction executing the script. A and the transaction executing the script. A
@ -112,7 +112,7 @@ validation software will copy the input script, retrieve the UTXO
referenced by the input, and copy the output script from that UTXO. The referenced by the input, and copy the output script from that UTXO. The
input and output scripts are then executed together. 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 valid if the input script satisfies the output script's conditions
(see <<script_exec>>). All the inputs are validated independently, as (see <<script_exec>>). All the inputs are validated independently as
part of the overall validation of the transaction. part of the overall validation of the transaction.
Note that the preceding steps involve making copies of all data. The Note that the preceding steps involve making copies of all data. The
@ -150,8 +150,8 @@ the stack.
Conditional operators evaluate a condition, producing a boolean result Conditional operators evaluate a condition, producing a boolean result
of +TRUE+ or +FALSE+. For example, +OP_EQUAL+ pops two items from the stack of +TRUE+ or +FALSE+. For example, +OP_EQUAL+ pops two items from the stack
and pushes +TRUE+ (+TRUE+ is represented by the number 1) if they are equal and pushes +TRUE+ (+TRUE+ is represented by the number 1) if they are equal
or +FALSE+ (represented by zero) if they are not equal. Bitcoin or +FALSE+ (represented by 0) if they are not equal. Bitcoin
transaction scripts usually contain a conditional operator, so that they transaction scripts usually contain a conditional operator so that they
can produce the +TRUE+ result that signifies a valid ((("scripts", "stack", startref="script-stack")))((("stack", startref="stack")))transaction. can produce the +TRUE+ result that signifies a valid ((("scripts", "stack", startref="script-stack")))((("stack", startref="stack")))transaction.
===== A simple script ===== A simple script
@ -363,7 +363,7 @@ the input script has
two valid signatures from private keys that correspond to two of two valid signatures from private keys that correspond to two of
the three public keys set as an encumbrance. the three public keys set as an encumbrance.
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most three At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to, at most, three
listed public keys, meaning you can do anything from a 1-of-1 to a 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. 3-of-3 multisignature or any combination within that range.
You may want to check the +IsStandard()+ function to see what is currently You may want to check the +IsStandard()+ function to see what is currently
@ -400,13 +400,12 @@ point, +OP_CHECKMULTISIG+ should pop the final +t+ items, which are the
signatures, and see if they are valid. However, unfortunately, an oddity in signatures, and see if they are valid. However, unfortunately, an oddity in
the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1 the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1
total) than it should. The extra item is called((("dummy stack element"))) the _dummy stack total) than it should. The extra item is called((("dummy stack element"))) the _dummy stack
element_ and it is disregarded when checking the element_, and it is disregarded when checking the
signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself. signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself.
However, the dummy element must be present because, if it isn't present, However, the dummy element must be present because, if it isn't present
when +OP_CHECKMULTISIG+ attempts to pop on an empty stack, it will cause a when +OP_CHECKMULTISIG+ attempts to pop on an empty stack, it will cause a
stack error and script failure (marking the transaction as invalid). stack error and script failure (marking the transaction as invalid).
Because the dummy element is disregarded it can be anything, but Because the dummy element is disregarded, it can be anything. It became the custom early on to use +OP_0+, which later became a
it became the custom early on to use +OP_0+, which later became a
relay policy rule and eventually a consensus rule (with the enforcement of BIP147). relay policy rule and eventually a consensus rule (with the enforcement of BIP147).
Because popping the dummy element is part of the consensus rules, it must now be Because popping the dummy element is part of the consensus rules, it must now be
@ -448,9 +447,9 @@ indicating which provided signature corresponds to which public key,
allowing the +OP_CHECKMULTISIG+ operation to only perform exactly +t+ allowing the +OP_CHECKMULTISIG+ operation to only perform exactly +t+
signature-checking operations. It's possible that Bitcoin's original signature-checking operations. It's possible that Bitcoin's original
developer added the extra element (which we now call the dummy stack 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 element) in the original version of Bitcoin so they could add the
feature for allowing a map to be passed in a later soft fork. However, feature for allowing a map to be passed in a later soft fork. However,
that feature was never implemented and the BIP147 update to the that feature was never implemented, and the BIP147 update to the
consensus rules in 2017 makes it impossible to add that feature in the consensus rules in 2017 makes it impossible to add that feature in the
future. future.
@ -552,10 +551,10 @@ with P2SH.
</table> </table>
++++ ++++
As you can see from the tables, with P2SH the complex script that As you can see from the tables, with P2SH, the complex script that
details the conditions for spending the output (redeem script) is not 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 presented in the output script. Instead, only a hash of it is in the
output script and the redeem script itself is presented later, as part output script, and the redeem script itself is presented later as part
of the input script when the output is spent. This shifts the burden of the input script when the output is spent. This shifts the burden
in fees and complexity from the spender to the receiver of the in fees and complexity from the spender to the receiver of the
transaction. transaction.
@ -572,7 +571,7 @@ incoming payments from customers:
---- ----
This entire script can instead be represented by a 20-byte cryptographic This entire script can instead be represented by a 20-byte cryptographic
hash, by first applying the SHA256 hashing algorithm and then applying hash by first applying the SHA256 hashing algorithm and then applying
the RIPEMD-160 algorithm on the result. For example, starting with the the RIPEMD-160 algorithm on the result. For example, starting with the
hash of Mohammed's redeem script: hash of Mohammed's redeem script:
@ -625,14 +624,14 @@ base58check-encoded addresses that start with a "3."
For example, Mohammed's complex script, hashed and base58check-encoded For example, Mohammed's complex script, hashed and base58check-encoded
as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+. as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+.
Now, Mohammed can give this "address" to his customers and they can use Now, Mohammed can give this "address" to his customers, and they can use
almost any Bitcoin wallet to make a simple payment, like any other almost any Bitcoin wallet to make a simple payment like any other
Bitcoin address. The 3 prefix gives them a hint that this is a special Bitcoin address. The 3 prefix gives them a hint that this is a special
type of address, one corresponding to a script instead of a public key, type of address, one corresponding to a script instead of a public key,
but otherwise it works in exactly the same way as a payment to any other Bitcoin but otherwise it works in exactly the same way as a payment to any other Bitcoin
address. address.
P2SH addresses hide all of the complexity so that the person making a P2SH addresses hide all of the complexity so the person making a
payment does not see the script. payment does not see the script.
==== Benefits of P2SH ==== Benefits of P2SH
@ -657,7 +656,7 @@ scripts in outputs:
==== Redeem Script and Validation ==== Redeem Script and Validation
You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script, because the You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script because the
P2SH specification is not recursive. Also, while it is technically P2SH specification is not recursive. Also, while it is technically
possible to include +OP_RETURN+ (see <<op_return>>) in a redeem script, as possible to include +OP_RETURN+ (see <<op_return>>) in a redeem script, as
nothing in the rules prevents you from doing so, it is of no practical nothing in the rules prevents you from doing so, it is of no practical
@ -669,7 +668,7 @@ until you attempt to spend a P2SH output, if you create an output with the
hash of an invalid redeem script, you will not be able to spend hash of an invalid redeem script, you will not be able to spend
it. The spending transaction, which includes the redeem script, it. The spending transaction, which includes the redeem script,
will not be accepted because it is an invalid script. This creates a will not be accepted because it is an invalid script. This creates a
risk, because you can send bitcoin to a P2SH address that cannot be spent later. risk because you can send bitcoin to a P2SH address that cannot be spent later.
[WARNING] [WARNING]
==== ====
@ -742,7 +741,7 @@ Keep in mind that there is no input script that corresponds to
whole point of an +OP_RETURN+ output is that you can't spend the money locked in that whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
output, and therefore it does not need to be held in the UTXO set as output, and therefore it does not need to be held in the UTXO set as
potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs
usually have a zero amount, because any bitcoins usually have a zero amount because any bitcoins
assigned to such an output are effectively lost forever. If an +OP_RETURN+ output is assigned to such an output are effectively lost forever. If an +OP_RETURN+ output is
referenced as an input in a transaction, the script validation engine referenced as an input in a transaction, the script validation engine
will halt the execution of the validation script and mark the will halt the execution of the validation script and mark the
@ -759,7 +758,7 @@ being included in a block until a specific block height, but it does not
prevent spending the funds in another transaction earlier than that. prevent spending the funds in another transaction earlier than that.
Let's explain that with the following example. Let's explain that with the following example.
Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that: Alice signs a transaction spending one of her outputs to Bob's address and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
* Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed. * Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
* Bob may transmit the transaction after 3 months. * Bob may transmit the transaction after 3 months.
@ -777,7 +776,7 @@ In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv
timelock was introduced to Bitcoin as a soft fork upgrade. Based on a timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
specification in BIP65, a new script operator called specification in BIP65, a new script operator called
_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language. _OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
+OP_CLTV+ is a per-output timelock, rather than a per-transaction timelock +OP_CLTV+ is a per-output timelock rather than a per-transaction timelock,
as is the case with lock time. This allows for additional as is the case with lock time. This allows for additional
flexibility in the way timelocks are applied. flexibility in the way timelocks are applied.
@ -808,7 +807,7 @@ To lock it to a time, say 3 months from now, his P2SH script would
instead be: instead be:
---- ----
<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFYG <Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFY
---- ----
where +<now {plus} 3 months>+ is a block height or time value estimated where +<now {plus} 3 months>+ is a block height or time value estimated
@ -823,7 +822,7 @@ to be equal or greater to the timelock in the +OP_CHECKLOCKTIMEVERIFY+
Alice set. Bob then broadcasts the transaction on the Bitcoin network. Alice set. Bob then broadcasts the transaction on the Bitcoin network.
Bob's transaction is evaluated as follows. If the +OP_CHECKLOCKTIMEVERIFY+ Bob's transaction is evaluated as follows. If the +OP_CHECKLOCKTIMEVERIFY+
parameter Alice set is less than or equal the spending transaction's parameter Alice set is less than or equal to the spending transaction's
lock time, script execution continues (acts as if a _no lock time, script execution continues (acts as if a _no
operation_ or +OP_NOP+ opcode was executed). Otherwise, script operation_ or +OP_NOP+ opcode was executed). Otherwise, script
execution halts and the transaction is deemed invalid. execution halts and the transaction is deemed invalid.
@ -911,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
Relative timelocks are Relative timelocks are
implemented according to the specifications in implemented according to the specifications in
https://oreil.ly/ZuANb[BIP68, https://oreil.ly/ZuANb[BIP68,
Relative lock-time using consensus-enforced sequence numbers] and relative lock-time using consensus-enforced sequence numbers] and
https://oreil.ly/dLA2r[BIP112, https://oreil.ly/dLA2r[BIP112,
+OP_CHECKSEQUENCEVERIFY+]. +OP_CHECKSEQUENCEVERIFY+].
@ -947,7 +946,7 @@ of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
==== ====
Relative timelocks with +OP_CSV+ are especially useful when several Relative timelocks with +OP_CSV+ are especially useful when several
(chained) transactions are created and signed, but not propagated--that (chained) transactions are created and signed but not propagated--that
is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the
parent transaction has been propagated, mined, and aged by the time parent transaction has been propagated, mined, and aged by the time
specified in the relative timelock. One application of this use case is shown in <<state_channels>> and <<lightning_network>>. specified in the relative timelock. One application of this use case is shown in <<state_channels>> and <<lightning_network>>.
@ -962,7 +961,7 @@ One of((("scripts", "flow control", id="script-flow")))((("flow control in scrip
powerful features of Bitcoin Script is flow control, also known as powerful features of Bitcoin Script is flow control, also known as
conditional clauses. You are probably familiar with flow control in conditional clauses. You are probably familiar with flow control in
various programming languages that use the construct +IF...THEN...ELSE+. various programming languages that use the construct +IF...THEN...ELSE+.
Bitcoin conditional clauses look a bit different, but are essentially Bitcoin conditional clauses look a bit different but are essentially
the same construct. 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
@ -1082,7 +1081,7 @@ A very common use for flow control in Bitcoin Script is to construct a
script that offers multiple execution paths, each a different way script that offers multiple execution paths, each a different way
of redeeming the UTXO. of redeeming the UTXO.
Let's look at a simple example, where Let's look at a simple example where
we have two signers, Alice and Bob, and either one is able to redeem. we have two signers, Alice and Bob, and either one is able to redeem.
With multisig, this would be expressed as a 1-of-2 multisig script. For With multisig, this would be expressed as a 1-of-2 multisig script. For
the sake of demonstration, we will do the same thing with an +OP_IF+ the sake of demonstration, we will do the same thing with an +OP_IF+
@ -1146,7 +1145,7 @@ In this scenario, there are three execution paths (+subscript A+, +subscript
B+, and +subscript C+). The input script provides a path in the form of B+, and +subscript C+). The input script provides a path in the form of
a sequence of +TRUE+ or +FALSE+ values. To select path +subscript B+, for a sequence of +TRUE+ or +FALSE+ values. To select path +subscript B+, for
example, the input script must end in +OP_1 OP_0+ (+TRUE+, +FALSE+). These example, the input script must end in +OP_1 OP_0+ (+TRUE+, +FALSE+). These
values will be pushed onto the stack, so that the second value (+FALSE+) values will be pushed onto the stack so that the second value (+FALSE+)
ends up at the top of the stack. The outer +OP_IF+ clause pops the +FALSE+ ends up at the top of the stack. The outer +OP_IF+ clause pops the +FALSE+
value and executes the first +OP_ELSE+ clause. Then the +TRUE+ value moves value and executes the first +OP_ELSE+ clause. Then the +TRUE+ value moves
to the top of the stack and is evaluated by the inner (nested) +OP_IF+, to the top of the stack and is evaluated by the inner (nested) +OP_IF+,
@ -1163,7 +1162,7 @@ at each flow control((("scripts", "flow control", startref="script-flow")))((("f
In this((("scripts", "examples of", id="script-example-complex"))) section we combine many of In this((("scripts", "examples of", id="script-example-complex"))) section we combine many of
the concepts from this chapter into a single example. the concepts from this chapter into a single example.
Mohammed is company owner in Dubai who is operating an import/export Mohammed, a company owner in Dubai, operates an import/export
business; he business; he
wishes to construct a company capital account with flexible rules. The wishes to construct a company capital account with flexible rules. The
scheme he creates requires different levels of authorization depending scheme he creates requires different levels of authorization depending
@ -1239,7 +1238,7 @@ OP_0 <Saeed's Sig> <Lawer's Sig> OP_FALSE OP_TRUE
[TIP] [TIP]
==== ====
Why +OP_FALSE OP_TRUE+? Isn't that backward? +FALSE+ is pushed onto the Why +OP_FALSE OP_TRUE+? Isn't that backward? +FALSE+ is pushed onto the
stack and +TRUE+ is pushed on top of it. stack, and +TRUE+ is pushed on top of it.
+TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode. +TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode.
==== ====
@ -1480,14 +1479,14 @@ Alice and Bob can use legacy non-segwit outputs. But Bob would
likely want to use segwit to reduce transaction fees, taking advantage likely want to use segwit to reduce transaction fees, taking advantage
of the reduced cost of witness structure. of the reduced cost of witness structure.
In this case Bob's wallet can construct a P2SH address that contains a In this case, Bob's wallet can construct a P2SH address that contains a
segwit script inside it. Alice's wallet can make payments to it without segwit script inside it. Alice's wallet can make payments to it without
any knowledge of segwit. any knowledge of segwit.
Bob's wallet can then spend this payment with a segwit transaction, Bob's wallet can then spend this payment with a segwit transaction,
taking advantage of segwit and reducing transaction fees. taking advantage of segwit and reducing transaction fees.
Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a
P2SH address. The first is noted as nested P2WPKH and the second is noted P2SH address. The first is noted as nested P2WPKH, and the second is noted
as nested P2WSH. as nested P2WSH.
===== Nested pay to witness public key hash ===== Nested pay to witness public key hash
@ -1632,7 +1631,7 @@ image::images/mbc3_0705.png["A MAST with three sub-scripts"]
We can now create a compact membership proof that proves a particular We can now create a compact membership proof that proves a particular
authorization condition is a member of the merkle tree without authorization condition is a member of the merkle tree without
disclosing any details about the other members of the merkle tree. See disclosing any details about the other members of the merkle tree. See
<<diagram_mast2>>, and note that the nodes with diagonal corners can be <<diagram_mast2>>, and note that the shaded nodes can be
computed from other data provided by the user, so they don't need to be computed from other data provided by the user, so they don't need to be
specified at spend time. specified at spend time.
@ -1641,7 +1640,7 @@ specified at spend time.
image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"] image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"]
The hash digests used to create the commitments are each 32 bytes, so The hash digests used to create the commitments are each 32 bytes, so
proving a spend of <<diagram_mast2>> is authorized (using a merkle tree and the proving that a spend of <<diagram_mast2>> is authorized (using a merkle tree and the
particular conditions) and authenticated (using signatures) uses 383 particular conditions) and authenticated (using signatures) uses 383
bytes. By comparison, the same spend without a merkle tree (i.e., providing all possible authorization conditions) uses 412 bytes. bytes. By comparison, the same spend without a merkle tree (i.e., providing all possible authorization conditions) uses 412 bytes.
@ -1692,7 +1691,7 @@ discovered, which we'll see in <<taproot>>.
.MAST Versus MAST .MAST Versus MAST
**** ****
The earliest((("abstract syntax trees (AST)")))((("AST (abstract syntax trees)"))) idea for what we now know as _MAST_ in Bitcoin was The earliest((("abstract syntax trees (AST)")))((("AST (abstract syntax trees)"))) idea for what we now know as _MAST_ in Bitcoin was
_merklized abstract syntax trees_. In an absract syntax tree (AST), _merklized abstract syntax trees_. In an abstract syntax tree (AST),
every condition in a script creates a new branch, as show in <<ast>>. every condition in a script creates a new branch, as show in <<ast>>.
[[ast]] [[ast]]
@ -1701,12 +1700,12 @@ image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"]
ASTs are widely used by programs that parse and optimize code for other ASTs are widely used by programs that parse and optimize code for other
programs, such as compilers. A merklized AST would commit to every part programs, such as compilers. A merklized AST would commit to every part
of a program and so enable the features described in of a program and enable the features described in
<<mast>>, but it would require revealing at least one 32-byte digest for <<mast>>, but it would require revealing at least one 32-byte digest for
every separate part of the program, which would not be very space every separate part of the program, which would not be very space
efficient on the blockchain for most programs. efficient on the blockchain for most programs.
What most people in most cases call _MAST_ in Bitcoin today is What people in most cases call _MAST_ in Bitcoin today is
_merklized alternative script trees_, a backronym coined by developer _merklized alternative script trees_, a backronym coined by developer
Anthony Towns. An alternative script tree is a set of scripts, each Anthony Towns. An alternative script tree is a set of scripts, each
one of them complete by itself, where only one can be selected--making one of them complete by itself, where only one can be selected--making
@ -1737,22 +1736,22 @@ also serve another use.
Let's imagine Bob wants to buy something from Alice but he also wants to Let's imagine Bob wants to buy something from Alice but he also wants to
be able prove later what he paid for in case there's any dispute. Alice be able prove later what he paid for in case there's any dispute. Alice
and Bob agree on the name of the item or service being sold, e.g., and Bob agree on the name of the item or service being sold (e.g.,
"Alice's podcast episode #123," and transform that description into a "Alice's podcast episode #123"), and transform that description into a
number by hashing it and interpreting the hash digest as a number. Bob number by hashing it and interpreting the hash digest as a number. Bob
adds that number to Alice's public key and pays it. The process is adds that number to Alice's public key and pays it. The process is
called _key tweaking_ and the number is known as a _tweak_. called _key tweaking_, and the number is known as a _tweak_.
Alice can spend the funds by tweaking her private key using the same Alice can spend the funds by tweaking her private key using the same
number (tweak). number (tweak).
Later, Bob can prove to anyone what he paid Alice by revealing her Later, Bob can prove to anyone what he paid Alice by revealing her
underlying key and the description they used. Anyone can verify that underlying key and the description they used. Anyone can verify that
the public key which was paid equals the underlying key plus the the public key, which was paid, equals the underlying key plus the
hash commitment to the description. If Alice admits that key is hers, hash commitment to the description. If Alice admits that key is hers,
then she received the payment. If Alice spent the funds, this further then she received the payment. If Alice spent the funds, this further
proves she knew the description at the time she signed the spending proves she knew the description at the time she signed the spending
transaction, since she could only create a valid signature for the transaction since she could only create a valid signature for the
tweaked public key if she knew the tweak (the description). tweaked public key if she knew the tweak (the description).
If neither Alice nor Bob decided to publicly reveal the description they If neither Alice nor Bob decided to publicly reveal the description they
@ -1808,7 +1807,7 @@ using a single key and signature. The story is the same for privacy:
because each new key or signature adds data to a transaction, scripted because each new key or signature adds data to a transaction, scripted
multisignatures disclose data about how many keys and signatures are multisignatures disclose data about how many keys and signatures are
being used--which may make it easy to figure out which transactions were being used--which may make it easy to figure out which transactions were
created by which group of participants. But, because every scriptless created by which group of participants. However, because every scriptless
multisignatures looks like every other scriptless multisignatures looks like every other scriptless
multisignature and every single-signature, no privacy-reducing data is multisignature and every single-signature, no privacy-reducing data is
leaked. leaked.

31
ch08_signatures.adoc
View File

@ -92,7 +92,7 @@ signature on this transaction."
Digital signatures((("digital signatures", "SIGHASH flags", id="digital-signature-sighash")))((("SIGHASH flags", id="sighash"))) apply to messages, Digital signatures((("digital signatures", "SIGHASH flags", id="digital-signature-sighash")))((("SIGHASH flags", id="sighash"))) apply to messages,
which in the case of Bitcoin, are the transactions themselves. The which in the case of Bitcoin, are the transactions themselves. The
signature prove a _commitment_ by the signer to specific transaction signature proves a _commitment_ by the signer to specific transaction
data. In the simplest form, the signature applies to almost the entire data. In the simplest form, the signature applies to almost the entire
transaction, thereby committing to all the inputs, outputs, and other transaction, thereby committing to all the inputs, outputs, and other
transaction fields. However, a signature can commit to only a subset of transaction fields. However, a signature can commit to only a subset of
@ -103,7 +103,7 @@ Bitcoin signatures have a way of indicating which
part of a transaction's data is included in the hash signed by the part of a transaction's data is included in the hash signed by the
private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
that is appended to the signature. Every signature has either an that is appended to the signature. Every signature has either an
explicit or implicit +SIGHASH+ flag explicit or implicit +SIGHASH+ flag,
and the flag can be different from input to input. A transaction with and the flag can be different from input to input. A transaction with
three signed inputs may have three signatures with different +SIGHASH+ three signed inputs may have three signatures with different +SIGHASH+
flags, each signature signing (committing) to different parts of the flags, each signature signing (committing) to different parts of the
@ -217,7 +217,7 @@ in practice:
funds can construct a transaction with a single output. The single funds can construct a transaction with a single output. The single
output pays the "goal" amount to the fundraiser. Such a transaction is output pays the "goal" amount to the fundraiser. Such a transaction is
obviously not valid, as it has no inputs. However, others can now amend obviously not valid, as it has no inputs. However, others can now amend
it by adding an input of their own, as a donation. They sign their own it by adding an input of their own as a donation. They sign their own
input with +ALL|ANYONECANPAY+. Unless enough inputs are gathered to input with +ALL|ANYONECANPAY+. Unless enough inputs are gathered to
reach the value of the output, the transaction is invalid. Each donation reach the value of the output, the transaction is invalid. Each donation
is a "pledge," which cannot be collected by the fundraiser until the is a "pledge," which cannot be collected by the fundraiser until the
@ -227,7 +227,7 @@ someone who lends them funds), allowing them to collect the donations
even if they haven't reached the specified value. even if they haven't reached the specified value.
+NONE+ :: This construction can be used to create a "bearer check" or +NONE+ :: This construction can be used to create a "bearer check" or
"blank check" of a specific amount. It commits to all inputs, but allows "blank check" of a specific amount. It commits to all inputs but allows
the outputs to be changed. Anyone can write their own the outputs to be changed. Anyone can write their own
Bitcoin address into the output script. Bitcoin address into the output script.
By itself, this allows any miner to change By itself, this allows any miner to change
@ -394,7 +394,7 @@ generator +G=5+ to get her public key +xG=15+. She gives Bob +15+.
4. Bob derives +sG = 200 = 40 * 5+ and +exG = 165 = 11 * 15+. He then 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 verifies that +200 == 35 + 165+. Note that this is the same operation
that Alice performed but all of the values have been scaled up by +5+ that Alice performed, but all of the values have been scaled up by +5+
(the value of +G+). (the value of +G+).
Of course, this is an oversimplified example. When working with simple Of course, this is an oversimplified example. When working with simple
@ -549,8 +549,7 @@ she's ready to spend, she begins generating her signature:
==== Serialization of Schnorr Signatures ==== Serialization of Schnorr Signatures
A schnorr signature ((("digital signatures", "schnorr signature algorithm", "serialization")))((("schnorr signature algorithm", "serialization")))((("serialization", "of schnorr signature algorithm", secondary-sortas="schnorr")))consists of two values, +kG+ and +s+. The value A schnorr signature ((("digital signatures", "schnorr signature algorithm", "serialization")))((("schnorr signature algorithm", "serialization")))((("serialization", "of schnorr signature algorithm", secondary-sortas="schnorr")))consists of two values, +kG+ and +s+. The value
+kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and so +kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
However, only the _x_ coordinate is needed, so only that value is However, only the _x_ coordinate is needed, so only that value is
included. When you see +kG+ in schnorr signatures for Bitcoin, note that it's only that point's _x_ included. When you see +kG+ in schnorr signatures for Bitcoin, note that it's only that point's _x_
coordinate. coordinate.
@ -560,7 +559,7 @@ Bitcoin's secp256k1 curve, it can never be more than 32 bytes long.
Although both +kG+ and +s+ can sometimes be values that can be Although both +kG+ and +s+ can sometimes be values that can be
represented with fewer than 32 bytes, it's improbable that they'd be represented with fewer than 32 bytes, it's improbable that they'd be
much smaller than 32 bytes, and so they're serialized as two 32-byte much smaller than 32 bytes, so they're serialized as two 32-byte
values (i.e., values smaller than 32 bytes have leading zeros). values (i.e., values smaller than 32 bytes have leading zeros).
They're serialized in the order of +kG+ and then +s+, producing exactly They're serialized in the order of +kG+ and then +s+, producing exactly
64 bytes. 64 bytes.
@ -621,9 +620,9 @@ simple multisignature protocol:
Alice and Bob have proven that they know the sum of their private keys without Alice and Bob have proven that they know the sum of their private keys without
either one of them revealing their private key to the other or anyone either one of them revealing their private key to the other or anyone
else. The protocol can be extended to any number of participants; e.g., else. The protocol can be extended to any number of participants (e.g.,
a million people could prove they knew the sum of their million a million people could prove they knew the sum of their million
different keys. different keys).
The preceding protocol has several security problems. Most notable is that one The preceding protocol has several security problems. Most notable is that one
party might learn the public keys of the other parties before committing party might learn the public keys of the other parties before committing
@ -631,7 +630,7 @@ to their own public key. For example, Alice generates her public key
+yG+ honestly and shares it with Bob. Bob generates his public key +yG+ honestly and shares it with Bob. Bob generates his public key
using +zG - yG+. When their two keys are combined (+yG + zG - yG+), the using +zG - yG+. When their two keys are combined (+yG + zG - yG+), the
positive and negative +yG+ terms cancel out so the public key only represents positive and negative +yG+ terms cancel out so the public key only represents
the private key for +z+, i.e., Bob's private key. Now Bob can create a the private key for +z+ (i.e., Bob's private key). Now Bob can create a
valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a
_key cancellation attack_. _key cancellation attack_.
@ -790,9 +789,9 @@ work together to reconstruct Alice's partial private key. Now Bob has
his own partial private key plus the keys of Alice and Carol, allowing his own partial private key plus the keys of Alice and Carol, allowing
him to spend the funds himself without their involvement. This attack can him to spend the funds himself without their involvement. This attack can
be addressed if all of the participants agree to only communicate using a be addressed if all of the participants agree to only communicate using a
scheme that allows any one of them to see all of the other's messages; scheme that allows any one of them to see all of the other's messages
e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see (e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see
that message before she begins working with Bob. Other solutions, that message before she begins working with Bob). Other solutions,
possibly more robust solutions, to this problem were being researched at possibly more robust solutions, to this problem were being researched at
the time of writing. the time of writing.
@ -841,7 +840,7 @@ Less provable security::
Nonlinear:: Nonlinear::
ECDSA signatures cannot be easily combined to create scriptless ECDSA signatures cannot be easily combined to create scriptless
multisignatures or used in related advanced applications such as multisignatures or used in related advanced applications, such as
multiparty signature adaptors. There are workarounds for this multiparty signature adaptors. There are workarounds for this
problem, but they involve additional extra complexity that problem, but they involve additional extra complexity that
significantly slows down operations and which, in some cases, has significantly slows down operations and which, in some cases, has
@ -923,7 +922,7 @@ as follows:
=== The Importance of Randomness in Signatures === The Importance of Randomness in Signatures
As we((("digital signatures", "randomness, importance of", id="digital-signature-random")))((("randomness, importance in digital signatures", id="random-digital-signature"))) saw in <<schnorr_signatures>> and <<ecdsa_signatures>>, As we((("digital signatures", "randomness, importance of", id="digital-signature-random")))((("randomness, importance in digital signatures", id="random-digital-signature"))) saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
the signature generation algorithm uses a random number _k_, as the basis the signature generation algorithm uses a random number _k_ as the basis
for a private/public nonce pair. The value of _k_ is not for a private/public nonce pair. The value of _k_ is not
important, _as long as it is random_. If signatures from the same important, _as long as it is random_. If signatures from the same
private key use the private nonce _k_ with different messages private key use the private nonce _k_ with different messages

28
ch09_fees.adoc
View File

@ -17,7 +17,7 @@ blockchain to a sufficient depth before he considers the money he
received as his to spend (see <<confirmations>>). received as his to spend (see <<confirmations>>).
For Alice's transaction to be included in the For Alice's transaction to be included in the
blockchain, it must be included in a _block_ of transactions. There are blockchain, it must be included in a _block_ of transactions. There are
a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time and each a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time, and each
block only has a limited amount of space. Only the miner who creates block only has a limited amount of space. Only the miner who creates
that block gets to choose which transactions to include. Miners may that block gets to choose which transactions to include. Miners may
select transactions by any criteria they want, including refusing to select transactions by any criteria they want, including refusing to
@ -84,7 +84,7 @@ a payment typically have an interest in having it confirming quickly, so
normally allowing only spenders to choose fees can sometimes be a normally allowing only spenders to choose fees can sometimes be a
problem; we'll look at a solution to that problem in <<cpfp>>. However, problem; we'll look at a solution to that problem in <<cpfp>>. However,
in many common payment flows, the parties with the highest desire to see a in many common payment flows, the parties with the highest desire to see a
transaction confirm quickly--that is, the parties who'd be the most transaction confirm quickly--that is, the parties who would be the most
willing to pay higher fees--are the spenders. willing to pay higher fees--are the spenders.
For those reasons, both technical and practical, it is customary in For those reasons, both technical and practical, it is customary in
@ -230,11 +230,11 @@ Full RBF::
**** ****
The reason for the two different versions of RBF is that full RBF has The reason for the two different versions of RBF is that full RBF has
been controversial. Early versions of Bitcoin allowed transaction been controversial. Early versions of Bitcoin allowed transaction
replacement but this behavior was disabled for several releases. During replacement, but this behavior was disabled for several releases. During
that time, a miner or full node using the software now called Bitcoin that time, a miner or full node using the software now called Bitcoin
Core would not replace the first version of an unconfirmed transaction Core would not replace the first version of an unconfirmed transaction
they received with any different version. Some merchants came to expect they received with any different version. Some merchants came to expect
this behavior: they assumed that any valid unconfirmed transaction which this behavior: they assumed that any valid unconfirmed transaction that
paid an appropriate fee rate would eventually become a confirmed paid an appropriate fee rate would eventually become a confirmed
transaction, so they provided their goods or services shortly after transaction, so they provided their goods or services shortly after
receiving such an unconfirmed transaction. receiving such an unconfirmed transaction.
@ -292,7 +292,7 @@ having "Sending support" on
https://oreil.ly/IhMzx. https://oreil.ly/IhMzx.
As a developer, if you plan to implement RBF fee bumping, you will first As a developer, if you plan to implement RBF fee bumping, you will first
need to decided whether to perform opt-in RBF or full RBF. At the time need to decide 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 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 full RBF becomes reliable, there will likely be several years where
replacements of opt-in transactions get confirmed slightly faster than replacements of opt-in transactions get confirmed slightly faster than
@ -432,7 +432,7 @@ The solution to this problem is the ability to relay transactions as a
package, called _package relay_, allowing the receiving node to evaluate package, called _package relay_, allowing the receiving node to evaluate
the fee rate of the entire package before operating on any individual the fee rate of the entire package before operating on any individual
transaction. As of this writing, developers working on Bitcoin Core transaction. As of this writing, developers working on Bitcoin Core
have made significant progress on implementing package relay and a have made significant progress on implementing package relay, and a
limited early version of it may be available by the time this book is limited early version of it may be available by the time this book is
published. published.
@ -594,10 +594,10 @@ Fees = Sum(Inputs) – Sum(Outputs)
---- ----
This is a somewhat confusing element of transactions and an important This is a somewhat confusing element of transactions and an important
point to understand, because if you are constructing your own point to understand because if you are constructing your own
transactions you must ensure you do not inadvertently include a very transactions, you must ensure you do not inadvertently include a very
large fee by underspending the inputs. That means that you must account large fee by underspending the inputs. That means that you must account
for all inputs, if necessary by creating change, or you will end up for all inputs, if necessary, by creating change, or you will end up
giving the miners a very big tip! giving the miners a very big tip!
For example, if you spend a 20-bitcoin UTXO to make a 1-bitcoin For example, if you spend a 20-bitcoin UTXO to make a 1-bitcoin
@ -619,7 +619,7 @@ you intended.
=== Timelock Defense Against Fee Sniping === Timelock Defense Against Fee Sniping
Fee sniping ((("transaction fees", "fee sniping", id="transaction-fee-sniping")))((("fee sniping", id="fee-snipe")))((("timelocks", "fee sniping and", id="timelock-fee-snipe")))((("lock time", "fee sniping and", id="lock-time-fee-snipe")))is a theoretical Fee sniping ((("transaction fees", "fee sniping", id="transaction-fee-sniping")))((("fee sniping", id="fee-snipe")))((("timelocks", "fee sniping and", id="timelock-fee-snipe")))((("lock time", "fee sniping and", id="lock-time-fee-snipe")))is a theoretical
attack scenario, where miners attempting to rewrite past blocks "snipe" attack scenario where miners attempting to rewrite past blocks "snipe"
higher-fee transactions from future blocks to maximize their higher-fee transactions from future blocks to maximize their
profitability. profitability.
@ -635,7 +635,7 @@ They can include any transactions that were in the "old" block
Essentially they have the option to pull transactions from the "present" Essentially they have the option to pull transactions from the "present"
into the rewritten "past" when they re-create block #100,000. into the rewritten "past" when they re-create block #100,000.
Today, this attack is not very lucrative, because the block subsidy is much Today, this attack is not very lucrative because the block subsidy is much
higher than total fees per block. But at some point in the future, higher than total fees per block. But at some point in the future,
transaction fees will be the majority of the reward (or even the transaction fees will be the majority of the reward (or even the
entirety of the reward). At that time, this scenario becomes inevitable. entirety of the reward). At that time, this scenario becomes inevitable.
@ -649,15 +649,15 @@ no effect&#x2014;the transactions could only be included in block
#100,001 anyway; it's the next block. #100,001 anyway; it's the next block.
But under a reorganization attack, the miners would not be able to pull But under a reorganization attack, the miners would not be able to pull
high-fee transactions from the mempool, because all those transactions high-fee transactions from the mempool because all those transactions
would be timelocked to block #100,001. They can only remine #100,000 would be timelocked to block #100,001. They can only remine #100,000
with whatever transactions were valid at that time, essentially gaining with whatever transactions were valid at that time, essentially gaining
no new fees. no new fees.
This does not entirely prevent fee sniping, but it does make it less This does not entirely prevent fee sniping, but it does make it less
profitable in some cases and so can help preserve the stability of the profitable in some cases and can help preserve the stability of the
Bitcoin network as the block subsidy declines. We recommend all wallets Bitcoin network as the block subsidy declines. We recommend all wallets
implement anti fee sniping when it doesn't interfere with the wallet's implement anti-fee sniping when it doesn't interfere with the wallet's
other uses of the lock time field. other uses of the lock time field.
As Bitcoin continues to mature, and as the subsidy continues to decline, As Bitcoin continues to mature, and as the subsidy continues to decline,

60
ch10_network.adoc
View File

@ -222,7 +222,7 @@ receive it. For example:
A third technique is to assume all nodes receiving the data have A third technique is to assume all nodes receiving the data have
almost all of the same transactions in their mempool, so they can all almost all of the same transactions in their mempool, so they can all
accept the same compact block. That not only saves us time computing accept the same compact block. That not only saves us time computing
a compact block at each hop, but it means that all each hop can simply a compact block at each hop, but it means that each hop can simply
relay the FEC packets to the next hop even before validating them. relay the FEC packets to the next hop even before validating them.
The trade-off for each of the preceding methods is that they work well with The trade-off for each of the preceding methods is that they work well with
@ -238,7 +238,7 @@ The original
https://oreil.ly/30ZKi[Bitcoin Relay Network] was((("Bitcoin Relay Network"))) created by https://oreil.ly/30ZKi[Bitcoin Relay Network] was((("Bitcoin Relay Network"))) created by
developer Matt Corallo in 2015 to enable fast synchronization of developer Matt Corallo in 2015 to enable fast synchronization of
blocks between miners with very low latency. The network consisted of blocks between miners with very low latency. The network consisted of
several Virtual Private Servers (VPSes) hosted on several virtual private servers (VPSes) hosted on
infrastructure around the world and served to connect the majority of infrastructure around the world and served to connect the majority of
miners and mining pools. miners and mining pools.
@ -268,7 +268,7 @@ information, including:
+Version+:: The Bitcoin P2P protocol version the client "speaks" (e.g., 70002) +Version+:: The Bitcoin P2P protocol version the client "speaks" (e.g., 70002)
+nLocalServices+:: A list of local services supported by the node +nLocalServices+:: A list of local services supported by the node
+nTime+:: The current time +nTime+:: The current time
+addrYou+:: The IP address of the remote node as seen from this node +addrYou+:: The IP address of the remote node, as seen from this node
+addrMe+:: The IP address of the local node, as discovered by the local node +addrMe+:: The IP address of the local node, as discovered by the local node
+subver+:: A subversion showing the type of software running on this node (e.g., [.keep-together]#+/Satoshi:0.9.2.1/+#) +subver+:: A subversion showing the type of software running on this node (e.g., [.keep-together]#+/Satoshi:0.9.2.1/+#)
+BestHeight+:: The block height of this node's blockchain +BestHeight+:: The block height of this node's blockchain
@ -326,12 +326,12 @@ A node must connect to a few different peers in order to establish
diverse paths into the Bitcoin network. Paths are not reliable—nodes diverse paths into the Bitcoin network. Paths are not reliable—nodes
come and go—and so the node must continue to discover new nodes as it come and go—and so the node must continue to discover new nodes as it
loses old connections as well as assist other nodes when they bootstrap. loses old connections as well as assist other nodes when they bootstrap.
Only one connection is needed to bootstrap, because the first node can Only one connection is needed to bootstrap because the first node can
offer introductions to its peer nodes and those peers can offer further offer introductions to its peer nodes and those peers can offer further
introductions. It's also unnecessary and wasteful of network resources introductions. It's also unnecessary and wasteful of network resources
to connect to more than a handful of nodes. After bootstrapping, a node to connect to more than a handful of nodes. After bootstrapping, a node
will remember its most recent successful peer connections, so that if it will remember its most recent successful peer connections so if it
is rebooted it can quickly reestablish connections with its former peer is rebooted, it can quickly reestablish connections with its former peer
network. If none of the former peers respond to its connection request, network. If none of the former peers respond to its connection request,
the node can use the seed nodes to bootstrap again. the node can use the seed nodes to bootstrap again.
@ -399,14 +399,14 @@ $ bitcoin-cli getpeerinfo
To override the automatic management of peers and to specify a list of To override the automatic management of peers and to specify a list of
IP addresses, users can provide the option +-connect=<IPAddress>+ and IP addresses, users can provide the option +-connect=<IPAddress>+ and
specify one or more IP addresses. If this option is used, the node will specify one or more IP addresses. If this option is used, the node will
only connect to the selected IP addresses, instead of discovering and only connect to the selected IP addresses instead of discovering and
maintaining the peer connections automatically. maintaining the peer connections automatically.
If there is no traffic on a connection, nodes will periodically send a If there is no traffic on a connection, nodes will periodically send a
message to maintain the connection. If a node has not communicated on a message to maintain the connection. If a node has not communicated on a
connection for too long, it is assumed to be disconnected connection for too long, it is assumed to be disconnected
and a new peer will be sought. Thus, the network dynamically adjusts to and a new peer will be sought. Thus, the network dynamically adjusts to
transient nodes and network problems, and can organically grow and transient nodes and network problems and can organically grow and
shrink as needed without any ((("Bitcoin network", "nodes", "network discovery", startref="bitcoin-network-node-discovery")))((("nodes", "network discovery", startref="node-discovery")))((("network discovery", startref="network-discovery")))central control. shrink as needed without any ((("Bitcoin network", "nodes", "network discovery", startref="bitcoin-network-node-discovery")))((("nodes", "network discovery", startref="node-discovery")))((("network discovery", startref="network-discovery")))central control.
=== Full Nodes === Full Nodes
@ -449,7 +449,7 @@ node will have to download hundreds of thousands of blocks to
synchronize with the network and reestablish the full blockchain. synchronize with the network and reestablish the full blockchain.
The The
process of syncing the blockchain starts with the +version+ message, process of syncing the blockchain starts with the +version+ message
because that contains +BestHeight+, a node's current blockchain height because that contains +BestHeight+, a node's current blockchain height
(number of blocks). A node will see the +version+ messages from its (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 peers, know how many blocks they each have, and be able to compare to
@ -549,7 +549,7 @@ verify that a transaction, such as a double-spend of the same UTXO,
doesn't exist because it doesn't have a record of all transactions. This doesn't exist because it doesn't have a record of all transactions. This
vulnerability can be used in a denial-of-service attack or for a vulnerability can be used in a denial-of-service attack or for a
double-spending attack against lightweight clients. To defend against this, a lightweight double-spending attack against lightweight clients. To defend against this, a lightweight
client needs to connect randomly to several clients, to increase the client needs to connect randomly to several clients to increase the
probability that it is in contact with at least one honest node. This probability that it is in contact with at least one honest node. This
need to randomly connect means that lightweight clients also are vulnerable to need to randomly connect means that lightweight clients also are vulnerable to
network partitioning attacks or Sybil attacks, where they are connected network partitioning attacks or Sybil attacks, where they are connected
@ -603,7 +603,7 @@ A bloom filter((("Bitcoin network", "bloom filters", "operational overview", id=
to describe a desired pattern without specifying it exactly. Bloom to describe a desired pattern without specifying it exactly. Bloom
filters offer an efficient way to express a search pattern while filters offer an efficient way to express a search pattern while
protecting privacy. They are used by lightweight clients to ask their peers for protecting privacy. They are used by lightweight clients to ask their peers for
transactions matching a specific pattern, without revealing exactly transactions matching a specific pattern without revealing exactly
which addresses, keys, or transactions they are searching for. which addresses, keys, or transactions they are searching for.
In our previous analogy, a tourist without a map is asking for In our previous analogy, a tourist without a map is asking for
@ -615,7 +615,7 @@ reveals slightly less about the desired destination than asking for "23
Church St." Using this technique, a tourist could specify the desired Church St." Using this technique, a tourist could specify the desired
address in more detail such as "ending in U-R-C-H" or less detail such as address in more detail such as "ending in U-R-C-H" or less detail such as
"ending in H." By varying the precision of the search, the tourist "ending in H." By varying the precision of the search, the tourist
reveals more or less information, at the expense of getting more or less reveals more or less information at the expense of getting more or less
specific results. If they ask for a less specific pattern, they get a lot specific results. If they ask for a less specific pattern, they get a lot
more possible addresses and better privacy, but many of the results are more possible addresses and better privacy, but many of the results are
irrelevant. If they ask for a very specific pattern, they get fewer irrelevant. If they ask for a very specific pattern, they get fewer
@ -662,7 +662,7 @@ changed from +0+ to +1+.
<<bloom2>> is an example of adding a pattern "A" to the simple bloom filter shown in <<bloom1>>. <<bloom2>> is an example of adding a pattern "A" to the simple bloom filter shown in <<bloom1>>.
Adding a second pattern is as simple as repeating this process. The Adding a second pattern is as simple as repeating this process. The
pattern is hashed by each hash function in turn and the result is pattern is hashed by each hash function in turn, and the result is
recorded by setting the bits to +1+. Note that as a bloom filter is recorded by setting the bits to +1+. Note that as a bloom filter is
filled with more patterns, a hash function result might coincide with a filled with more patterns, a hash function result might coincide with a
bit that is already set to +1+, in which case the bit is not changed. In bit that is already set to +1+, in which case the bit is not changed. In
@ -726,16 +726,16 @@ transactions of interest to the lightweight client without revealing exactly whi
addresses or keys it is interested in. addresses or keys it is interested in.
A lightweight client will initialize a bloom filter A lightweight client will initialize a bloom filter
as "empty"; in that state the bloom filter will not match any patterns. as "empty"; in that state, the bloom filter will not match any patterns.
The lightweight client will then make a list of all the addresses, keys, and The lightweight client will then make a list of all the addresses, keys, and
hashes that it is interested in. It will do this by extracting the hashes that it is interested in. It will do this by extracting the
public key hash and script hash and transaction IDs from any UTXO public key hash, script hash, and transaction IDs from any UTXO
controlled by its wallet. The lightweight client then adds each of these to the controlled by its wallet. The lightweight client then adds each of these to the
bloom filter, so that the bloom filter will "match" if these patterns bloom filter so that the bloom filter will "match" if these patterns
are present in a transaction, without revealing the patterns themselves. are present in a transaction, without revealing the patterns themselves.
The lightweight client will then send a The lightweight client will then send a
+filterload+ message to the peer, containing the bloom filter to use on +filterload+ message to the peer containing the bloom filter to use on
the connection. On the peer, bloom filters are checked against each the connection. On the peer, bloom filters are checked against each
incoming transaction. The full node checks several parts of the incoming transaction. The full node checks several parts of the
transaction against the bloom filter, looking for a match including: transaction against the bloom filter, looking for a match including:
@ -826,11 +826,11 @@ weren't created by the client. They can even download each matching
block from a different peer, making it harder for full nodes to connect block from a different peer, making it harder for full nodes to connect
transactions belonging to a single client across multiple blocks. transactions belonging to a single client across multiple blocks.
This idea for server-generated filters doesn't offer perfect privacy, This idea for server-generated filters doesn't offer perfect privacy;
it still places some costs on full nodes (and it does require lightweight it still places some costs on full nodes (and it does require lightweight
clients use more bandwidth for the block download), and the filters can clients to use more bandwidth for the block download), and the filters can
only be used for confirmed transactions (not unconfirmed transactions), only be used for confirmed transactions (not unconfirmed transactions). However,
but it is much more private and reliable than BIP37 client-requested it is much more private and reliable than BIP37 client-requested
bloom filters. bloom filters.
After the description of the original idea based on bloom filters, After the description of the original idea based on bloom filters,
@ -930,7 +930,7 @@ differences:
|=== |===
If we know that we might need to store large numbers (because large If we know that we might need to store large numbers (because large
differences can happen, even if they are rare) but we'll most often need differences can happen, even if they are rare), but we'll most often need
to store small numbers, we can encode each number using a system that to store small numbers, we can encode each number using a system that
uses less space for small numbers and extra space for large numbers. uses less space for small numbers and extra space for large numbers.
On average, that system will perform better than using the same amount On average, that system will perform better than using the same amount
@ -968,14 +968,14 @@ accurate filter.
For both the primary and secondary goals to be met, a filter would need For both the primary and secondary goals to be met, a filter would need
to reference two types of information: to reference two types of information:
* The script for every output in every transaction in a block. * The script for every output in every transaction in a block
* The outpoint for every input in every transaction in a block. * The outpoint for every input in every transaction in a block
An early design for compact block filters included both of those pieces An early design for compact block filters included both of those pieces
of information, but it was realized that there was a more efficient way of information, but it was realized there was a more efficient way
to accomplish the primary goal if we sacrificed the secondary goal. In to accomplish the primary goal if we sacrificed the secondary goal. In
the new design, a block filter would still references two types of the new design, a block filter would still reference two types of
information, but they'd be more closely related: information, but they'd be more closely related:
* As before, the script for every output in every transaction in a * As before, the script for every output in every transaction in a
@ -1072,7 +1072,7 @@ finding the differences (deltas) between each entry. That compact block
filter is then distributed by peers to their clients (such as wallets). filter is then distributed by peers to their clients (such as wallets).
A client uses the deltas to reconstruct the original commitments. The A client uses the deltas to reconstruct the original commitments. The
client such as a wallet also takes all the output scripts it is client, such as a wallet, also takes all the output scripts it is
monitoring for and generates commitments in the same way as BIP158. It monitoring for and generates commitments in the same way as BIP158. It
checks whether any of its generated commitments match the commitments in checks whether any of its generated commitments match the commitments in
the filter. the filter.
@ -1085,7 +1085,7 @@ compact block filter contains the number 1234. When a client sees that
There's a 100% guarantee that an accurate filter containing 1234 will There's a 100% guarantee that an accurate filter containing 1234 will
allow a client to learn about a block containing 123456, called a _true allow a client to learn about a block containing 123456, called a _true
positive_. However, there's also chance that the block might contain positive_. However, there's also a chance that the block might contain
123400, 123401, or almost a hundred other entries that are not what the 123400, 123401, or almost a hundred other entries that are not what the
client is looking for (in this example), ((("false positives")))called a _false positive_. client is looking for (in this example), ((("false positives")))called a _false positive_.
@ -1141,7 +1141,7 @@ communications: _Tor transport_.
Tor, which Tor, which
stands for _The Onion Routing network_, is a software project and stands for _The Onion Routing network_, is a software project and
network that offers encryption and encapsulation of data through network that offers encryption and encapsulation of data through
randomized network paths that offer anonymity, untraceability and randomized network paths that offer anonymity, untraceability, and
privacy. privacy.
Bitcoin Core ((("Bitcoin Core", "Tor transport")))offers several configuration options that allow you to run Bitcoin Core ((("Bitcoin Core", "Tor transport")))offers several configuration options that allow you to run
@ -1192,7 +1192,7 @@ children). Any matching orphans are then validated. If valid, they are
removed from the orphan pool and added to the mempool, removed from the orphan pool and added to the mempool,
completing the chain that started with the parent transaction. In light completing the chain that started with the parent transaction. In light
of the newly added transaction, which is no longer an orphan, the of the newly added transaction, which is no longer an orphan, the
process is repeated recursively looking for any further descendants, process is repeated recursively looking for any further descendants
until no more descendants are found. Through this process, the arrival until no more descendants are found. Through this process, the arrival
of a parent transaction triggers a cascade reconstruction of an entire of a parent transaction triggers a cascade reconstruction of an entire
chain of interdependent transactions by reuniting the orphans with chain of interdependent transactions by reuniting the orphans with

33
ch11_blockchain.adoc
View File

@ -10,7 +10,7 @@ full nodes (and sometimes light clients) to validate.
The blockchain data structure is The blockchain data structure is
an ordered, back-linked list of blocks of transactions. The blockchain an ordered, back-linked list of blocks of transactions. The blockchain
can be stored as a flat file, or in a simple database. can be stored as a flat file or in a simple database.
Blocks are linked "back," each referring to the previous block in the Blocks are linked "back," each referring to the previous block in the
chain. The blockchain is often visualized chain. The blockchain is often visualized
as a vertical stack, with blocks layered on top of each other and the as a vertical stack, with blocks layered on top of each other and the
@ -32,8 +32,8 @@ Although a block has just one parent, it can have ((("child blocks")))multiple
children. Each of the children commits to the same parent block. children. Each of the children commits to the same parent block.
Multiple children arise during a blockchain "fork," a temporary Multiple children arise during a blockchain "fork," a temporary
situation that can occur when different blocks are discovered almost situation that can occur when different blocks are discovered almost
simultaneously by different miners (see <<forks>>). Eventually, only one simultaneously by different miners (see <<forks>>). Eventually only one
child block becomes part of the blockchain accepted by all full nodes and the "fork" is resolved. child block becomes part of the blockchain accepted by all full nodes, and the "fork" is resolved.
The "previous block hash" field is inside the block header and thereby The "previous block hash" field is inside the block header and thereby
affects the _current_ block's hash. affects the _current_ block's hash.
@ -396,7 +396,7 @@ H<sub>A</sub> = SHA256(SHA256(Transaction A))
</pre> </pre>
++++ ++++
Consecutive pairs of leaf nodes are then summarized in a parent node, by Consecutive pairs of leaf nodes are then summarized in a parent node by
concatenating the two hashes and hashing them together. For example, to concatenating the two hashes and hashing them together. For example, to
construct the parent node H~AB~, the two 32-byte hashes of the children construct the parent node H~AB~, the two 32-byte hashes of the children
are concatenated to create a 64-byte string. That string is then are concatenated to create a 64-byte string. That string is then
@ -445,12 +445,11 @@ duplicate txids, resulting in a vulnerability (CVE-2012-2459).
The reason is that if the number of hashes in the list at a given level The reason is that if the number of hashes in the list at a given level
is odd, the last one is duplicated before computing the next level (which is odd, the last one is duplicated before computing the next level (which
is unusual in Merkle trees). This results in certain sequences of is unusual in merkle trees). This results in certain sequences of
transactions leading to the same merkle root. For example, the two transactions leading to the same merkle root. For example, the two
trees in <<cve_tree>>: trees in <<cve_tree>>:
[[cve_tree]] [[cve_tree]]
[role="figuresmallerninety"]
.Two Bitcoin-style merkle tree with the same root but a different number of leaves .Two Bitcoin-style merkle tree with the same root but a different number of leaves
image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"] image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"]
@ -488,7 +487,7 @@ To prove that a specific transaction is
included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte
hashes, constituting ((("authentication path")))((("merkle path")))an _authentication path_ or _merkle path_ hashes, constituting ((("authentication path")))((("merkle path")))an _authentication path_ or _merkle path_
connecting the specific transaction to the root of the tree. This is connecting the specific transaction to the root of the tree. This is
especially important as the number of transactions increases, because especially important as the number of transactions increases because
the base-2 logarithm of the number of transactions increases much more the base-2 logarithm of the number of transactions increases much more
slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or
12 hashes (320–384 bytes), which can provide proof of a single 12 hashes (320–384 bytes), which can provide proof of a single
@ -542,7 +541,7 @@ The lightweight client can use this merkle path to connect the transaction to th
block header and verify that the transaction is included in the block. The lightweight block header and verify that the transaction is included in the block. The lightweight
client also uses the block header to link the block to the rest of the client also uses the block header to link the block to the rest of the
blockchain. The combination of these two links, between the transaction blockchain. The combination of these two links, between the transaction
and block, and between the block and blockchain, proves that the and block and between the block and blockchain, proves that the
transaction is recorded in the blockchain. All in all, the lightweight client will transaction is recorded in the blockchain. All in all, the lightweight client will
have received less than a kilobyte of data for the block header and have received less than a kilobyte of data for the block header and
merkle path, an amount of data that is more than a thousand times less merkle path, an amount of data that is more than a thousand times less
@ -643,7 +642,7 @@ used to test segregated witness features.
Testnet doesn't just use the same data structures as Bitcoin, it also Testnet doesn't just use the same data structures as Bitcoin, it also
uses almost exactly the same proof-of-work (PoW) security mechanism as uses almost exactly the same proof-of-work (PoW) security mechanism as
Bitcoin. The notable differences for testnet are that its minimum Bitcoin. The notable differences for testnet are that its minimum
difficulty is half that of Bitcoin and that it's allowed to include a difficulty is half that of Bitcoin and it's allowed to include a
block at the minimum difficulty if that block's timestamp is more than block at the minimum difficulty if that block's timestamp is more than
20 minutes after the previous block. 20 minutes after the previous block.
@ -746,10 +745,10 @@ $ bitcoin-cli -signet getblockchaininfo
Regtest, ((("blockchain", "test blockchains", "regtest", id="blockchain-test-regtest")))((("test blockchains", "regtest", id="test-block-regtest")))((("regtest", id="regtest")))which stands for Regtest, ((("blockchain", "test blockchains", "regtest", id="blockchain-test-regtest")))((("test blockchains", "regtest", id="test-block-regtest")))((("regtest", id="regtest")))which stands for
"Regression Testing," is a Bitcoin Core feature that allows you to "Regression Testing," is a Bitcoin Core feature that allows you to
create a local blockchain for testing purposes. Unlike signet and testnet3, which create a local blockchain for testing purposes. Unlike signet and testnet3, which
are a public and shared test blockchain, the regtest blockchains are are public and shared test blockchains, the regtest blockchains are
intended to be run as closed systems for local testing. You launch a intended to be run as closed systems for local testing. You launch a
regtest blockchain from scratch. You may regtest blockchain from scratch. You may
add other nodes to the network, or run it with a single node only to add other nodes to the network or run it with a single node only to
test the Bitcoin Core software. test the Bitcoin Core software.
To start ((("Bitcoin Core", "regtest")))Bitcoin Core in regtest mode, you use the +regtest+ flag: To start ((("Bitcoin Core", "regtest")))Bitcoin Core in regtest mode, you use the +regtest+ flag:
@ -807,7 +806,7 @@ $ bitcoin-cli -regtest generatetoaddress 500 \
It will only take a few seconds to mine all these blocks, which It will only take a few seconds to mine all these blocks, which
certainly makes it easy for testing. If you check your wallet balance, certainly makes it easy for testing. If you check your wallet balance,
you will see that you earned reward for the first 400 blocks (coinbase you will see that you earned a reward for the first 400 blocks (coinbase
rewards must be 100 blocks deep before you can ((("blockchain", "test blockchains", "regtest", startref="blockchain-test-regtest")))((("test blockchains", "regtest", startref="test-block-regtest")))((("regtest", startref="regtest")))spend them): rewards must be 100 blocks deep before you can ((("blockchain", "test blockchains", "regtest", startref="blockchain-test-regtest")))((("test blockchains", "regtest", startref="test-block-regtest")))((("regtest", startref="regtest")))spend them):
---- ----
@ -820,10 +819,10 @@ $ bitcoin-cli -regtest getbalance
Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test blockchains", "development usage")))various Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test blockchains", "development usage")))various
blockchains (regtest, signet, testnet3, mainnet) offer a range blockchains (regtest, signet, testnet3, mainnet) offer a range
of testing environments for bitcoin development. Use the test of testing environments for bitcoin development. Use the test
blockchains whether you are developing for Bitcoin Core, or another blockchains whether you are developing for Bitcoin Core or another
full-node consensus client; an application such as a wallet, exchange, full-node consensus client (an application such as a wallet, exchange,
ecommerce site; or even developing novel smart contracts and complex ecommerce site; or even developing novel smart contracts and complex
scripts. scripts).
You can use the test blockchains to establish a development pipeline. You can use the test blockchains to establish a development pipeline.
Test your code locally on a regtest as you develop it. Once you are Test your code locally on a regtest as you develop it. Once you are
@ -837,6 +836,6 @@ into production.
Now that we know what data the blockchain contains and how cryptographic Now that we know what data the blockchain contains and how cryptographic
commitments securely tie the various parts together, we will look at the commitments securely tie the various parts together, we will look at the
special commitment that both provides computational security and special commitment that both provide computational security and
ensures no block can be changed without invalidating all other blocks ensure no block can be changed without invalidating all other blocks
built on top of it: Bitcoin's mining function. built on top of it: Bitcoin's mining function.

128
ch12_mining.adoc
View File

@ -74,7 +74,7 @@ will have been issued. After 2140, no new bitcoin
will be issued. will be issued.
Bitcoin miners ((("transaction fees")))also earn fees from transactions. Every transaction may Bitcoin miners ((("transaction fees")))also earn fees from transactions. Every transaction may
include a transaction fee, in the form of a surplus of bitcoins 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 the transaction's inputs and outputs. The winning bitcoin miner gets to
"keep the change" on the transactions included in the winning block. "keep the change" on the transactions included in the winning block.
Today, the fees usually represent only a small percentage of a Today, the fees usually represent only a small percentage of a
@ -168,7 +168,7 @@ fixed and diminishing monetary issuance is that the currency tends to be
inherently _deflationary_. Deflation is the phenomenon of appreciation inherently _deflationary_. Deflation is the phenomenon of appreciation
of value due to a mismatch in supply and demand that drives up the value of value due to a mismatch in supply and demand that drives up the value
(and exchange rate) of a currency. The opposite of inflation, price (and exchange rate) of a currency. The opposite of inflation, price
deflation means that the money has more purchasing power over time. deflation, means that the money has more purchasing power over time.
Many economists argue that a deflationary economy is a disaster that Many economists argue that a deflationary economy is a disaster that
should be avoided at all costs. That is because in a period of rapid should be avoided at all costs. That is because in a period of rapid
@ -213,7 +213,7 @@ providing a clearinghouse service, basically verifying and clearing all
transactions. Bitcoin has no central authority, yet somehow every full transactions. Bitcoin has no central authority, yet somehow every full
node has a complete copy of a public blockchain 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 authoritative record. The blockchain is not created by a central
authority, but is assembled independently by every node in the network. authority but is assembled independently by every node in the network.
Somehow, every node in the network, acting on information transmitted Somehow, every node in the network, acting on information transmitted
across insecure network connections, can arrive at the same conclusion across insecure network connections, can arrive at the same conclusion
and assemble a copy of the same blockchain as everyone else. This and assemble a copy of the same blockchain as everyone else. This
@ -221,7 +221,7 @@ chapter examines the process by which the Bitcoin network achieves
global consensus without central authority. global consensus without central authority.
One of Satoshi Nakamoto's inventions is the decentralized One of Satoshi Nakamoto's inventions is the decentralized
mechanism for _emergent consensus_. Emergent, because consensus is not mechanism for _emergent consensus_. Emergent because consensus is not
achieved explicitly—there is no election or fixed moment when consensus achieved explicitly—there is no election or fixed moment when consensus
occurs. Instead, consensus is an emergent artifact of the asynchronous occurs. Instead, consensus is an emergent artifact of the asynchronous
interaction of thousands of independent nodes, all following simple interaction of thousands of independent nodes, all following simple
@ -237,15 +237,15 @@ processes that occur independently on nodes across the network:
- Independent aggregation of those transactions into new blocks by - Independent aggregation of those transactions into new blocks by
mining nodes, coupled with demonstrated computation through a mining nodes, coupled with demonstrated computation through a
Proof-of-Work algorithm proof-of-work algorithm
- Independent verification of the new blocks by every node and assembly - Independent verification of the new blocks by every node and assembly
into a chain into a chain
- Independent selection, by every node, of the chain with the most - Independent selection, by every node, of the chain with the most
cumulative computation demonstrated through Proof-of-Work cumulative computation demonstrated through proof of work
In the next few sections we will examine these processes and how they In the next few sections, we will examine these processes and how they
interact to create the emergent property of network-wide consensus that interact to create the emergent property of network-wide consensus that
allows any Bitcoin node to assemble its own copy of the authoritative, allows any Bitcoin node to assemble its own copy of the authoritative,
trusted, public, global ((("bitcoins", "mining", "decentralized consensus", startref="bitcoin-mining-consensus")))((("mining", "decentralized consensus", startref="mining-consensus")))((("decentralized consensus", startref="decentral-consensus")))((("emergent consensus", startref="emergent-consensus")))blockchain. trusted, public, global ((("bitcoins", "mining", "decentralized consensus", startref="bitcoin-mining-consensus")))((("mining", "decentralized consensus", startref="mining-consensus")))((("decentralized consensus", startref="decentral-consensus")))((("emergent consensus", startref="emergent-consensus")))blockchain.
@ -440,7 +440,7 @@ fees (+nFees+), and the sum is returned.
If Jing's mining node writes the coinbase transaction, what stops Jing If Jing's mining node writes the coinbase transaction, what stops Jing
from "rewarding" himself 100 or 1,000 bitcoin? The answer is that an from "rewarding" himself 100 or 1,000 bitcoin? The answer is that an
inflated reward would result in the block being deemed invalid by inflated reward would result in the block being deemed invalid by
everyone else, wasting Jing's electricity used for Proof-of-Work. Jing everyone else, wasting Jing's electricity used for PoW. Jing
only gets to spend the reward if the block is accepted by ((("rewards", startref="reward-coinbase")))((("transaction fees", "in coinbase transactions", secondary-sortas="coinbase transactions", startref="transaction-fee-coinbase")))everyone. only gets to spend the reward if the block is accepted by ((("rewards", startref="reward-coinbase")))((("transaction fees", "in coinbase transactions", secondary-sortas="coinbase transactions", startref="transaction-fee-coinbase")))everyone.
==== ====
@ -524,7 +524,7 @@ structure of the((("inputs", "coinbase versus regular transactions"))) coinbase
<tr> <tr>
<td><p>Variable</p></td> <td><p>Variable</p></td>
<td><p>Coinbase Data</p></td> <td><p>Coinbase Data</p></td>
<td><p>Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height</p></td> <td><p>Arbitrary data used for extra nonce and mining tags; in v2 blocks, must begin with block height</p></td>
</tr> </tr>
<tr> <tr>
<td><p>4 bytes</p></td> <td><p>4 bytes</p></td>
@ -554,7 +554,7 @@ be used by miners in any way they want; it is arbitrary data.
In the genesis block, for In the genesis block, for
example, Satoshi Nakamoto added the text "The Times 03/Jan/2009 example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
Chancellor on brink of second bailout for banks" in the coinbase data, Chancellor on brink of second bailout for banks" in the coinbase data,
using it as a proof of the earliest date this block chould have been using it as a proof of the earliest date this block could have been
created and to convey a message. Currently, created and to convey a message. Currently,
miners often use the coinbase data to include extra nonce values and strings miners often use the coinbase data to include extra nonce values and strings
identifying the mining pool. identifying the mining pool.
@ -604,12 +604,12 @@ as listed in <<block_header_structure_ch10>>.
<tr> <tr>
<td><p>4 bytes</p></td> <td><p>4 bytes</p></td>
<td><p>Target</p></td> <td><p>Target</p></td>
<td><p>The Proof-of-Work algorithm target for this block</p></td> <td><p>The proof-of-work algorithm target for this block</p></td>
</tr> </tr>
<tr> <tr>
<td><p>4 bytes</p></td> <td><p>4 bytes</p></td>
<td><p>Nonce</p></td> <td><p>Nonce</p></td>
<td><p>A counter used for the Proof-of-Work algorithm</p></td> <td><p>A counter used for the proof-of-work algorithm</p></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
@ -662,11 +662,11 @@ transactions into a single 32-byte value, which is the _witness root
hash_. hash_.
The witness root hash is added to an output of the coinbase transaction. The witness root hash is added to an output of the coinbase transaction.
This step may be skipped if none of the transactions in the blook are This step may be skipped if none of the transactions in the block are
required to contain a witness structure. Each transaction (including required to contain a witness structure. Each transaction (including
the coinbase transaction) is then listed using its transaction the coinbase transaction) is then listed using its transaction
identifier (_txid_) and used to build a second merkle tree, the root of identifier (_txid_) and used to build a second merkle tree, the root of
which becomes the merkle root to which the block header commits. which becomes the merkle root, to which the block header commits.
Jing's mining node will then add a 4-byte timestamp, encoded as a Unix Jing's mining node will then add a 4-byte timestamp, encoded as a Unix
"epoch" timestamp, which is based on the number of seconds elapsed from "epoch" timestamp, which is based on the number of seconds elapsed from
@ -674,7 +674,7 @@ January 1, 1970, midnight UTC/GMT.
Jing's node then fills in the nBits target, which must be set to a Jing's node then fills in the nBits target, which must be set to a
compact representation of the required compact representation of the required
Proof-of-Work to make this a valid block. The target is stored in the PoW to make this a valid block. The target is stored in the
block as a "target bits" metric, which is a mantissa-exponent encoding block as a "target bits" metric, which is a mantissa-exponent encoding
of the target. The encoding has a 1-byte exponent, followed by a 3-byte of the target. The encoding has a 1-byte exponent, followed by a 3-byte
mantissa (coefficient). In block 277,316, for example, the target bits mantissa (coefficient). In block 277,316, for example, the target bits
@ -696,7 +696,7 @@ the header before a version is found that satisfies the((("bitcoins", "mining",
Now Now
that((("candidate blocks", "mining", id="candidate-mine")))((("blocks", "candidate blocks", "mining", id="block-candidate-mine")))((("mining", "candidate blocks", id="mining-candidate")))((("bitcoins", "mining", "candidate blocks", id="bitcoin-mining-candidate"))) a candidate block has been constructed by Jing's node, it is time that((("candidate blocks", "mining", id="candidate-mine")))((("blocks", "candidate blocks", "mining", id="block-candidate-mine")))((("mining", "candidate blocks", id="mining-candidate")))((("bitcoins", "mining", "candidate blocks", id="bitcoin-mining-candidate"))) a candidate block has been constructed by Jing's node, it is time
for Jing's hardware mining rig to "mine" the block, to find a solution for Jing's hardware mining rig to "mine" the block, to find a solution
to the Proof-of-Work algorithm that makes the block valid. Throughout to the proof-of-work algorithm that makes the block valid. Throughout
this book we have studied cryptographic hash functions as used in this book we have studied cryptographic hash functions as used in
various aspects of the Bitcoin system. The hash function SHA256 is the various aspects of the Bitcoin system. The hash function SHA256 is the
function used in Bitcoin's mining process. function used in Bitcoin's mining process.
@ -762,12 +762,12 @@ f75a100821c34c84395403afd1a8135f685ca69ccf4168e61a90e50f47552f61 -
The phrase "Hello, World! 32" produces the following hash, which fits our criteria: The phrase "Hello, World! 32" produces the following hash, which fits our criteria:
+09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+. It took 32 attempts to find it. In terms of +09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+. It took 32 attempts to find it. In terms of
probabilities, if the output of the hash function is evenly distributed probabilities, if the output of the hash function is evenly distributed,
we would expect to find a result with a 0 as the hexadecimal prefix once we would expect to find a result with a 0 as the hexadecimal prefix once
every 16 hashes (one out of 16 hexadecimal digits 0 through F). In every 16 hashes (one out of 16 hexadecimal digits 0 through F). In
numerical terms, that means finding a hash value that is less than numerical terms, that means finding a hash value that is less than
+0x1000000000000000000000000000000000000000000000000000000000000000+. We +0x1000000000000000000000000000000000000000000000000000000000000000+. We
call this threshold the _target_ and the goal is to find a hash that is call this threshold the _target_, and the goal is to find a hash that is
numerically less than the target. If we decrease the target, the task of numerically less than the target. If we decrease the target, the task of
finding a hash that is less than the target becomes more and more finding a hash that is less than the target becomes more and more
difficult. difficult.
@ -787,10 +787,10 @@ From the perspective of an observer who knows that the target of the
dice game is 2, if someone has succeeded in casting a winning throw it dice game is 2, if someone has succeeded in casting a winning throw it
can be assumed that they attempted, on average, 36 throws. In other can be assumed that they attempted, on average, 36 throws. In other
words, one can estimate the amount of work it takes to succeed from the words, one can estimate the amount of work it takes to succeed from the
difficulty imposed by the target. When the algorithm is a based on a difficulty imposed by the target. When the algorithm is based on a
deterministic function such as SHA256, the input itself constitutes deterministic function such as SHA256, the input itself constitutes
_proof_ that a certain amount of _work_ was done to produce a result _proof_ that a certain amount of _work_ was done to produce a result
below the target. Hence, _Proof-of-Work_. below the target. Hence, _proof of work_.
[TIP] [TIP]
==== ====
@ -799,7 +799,7 @@ any possible outcome can be calculated in advance. Therefore, an outcome
of specified difficulty constitutes proof of a specific amount of work. of specified difficulty constitutes proof of a specific amount of work.
==== ====
In <<sha256_example_generator_output2>>, the winning "nonce" is 32 and In <<sha256_example_generator_output2>>, the winning "nonce" is 32, and
this result can be confirmed by anyone independently. Anyone can add the this result can be confirmed by anyone independently. Anyone can add the
number 32 as a suffix to the phrase "Hello, world!" and compute number 32 as a suffix to the phrase "Hello, world!" and compute
the hash, verifying that it is less than the target: the hash, verifying that it is less than the target:
@ -811,7 +811,7 @@ $ echo "Hello, world! 32" | sha256sum
Although it only takes one hash computation to verify, it took Although it only takes one hash computation to verify, it took
us 32 hash computations to find a nonce that worked. If we had a lower 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 target (higher difficulty), it would take many more hash computations to
find a suitable nonce, but only one hash computation for anyone to find a suitable nonce, but only one hash computation for anyone to
verify. Furthermore, by knowing the target, anyone can estimate the verify. Furthermore, by knowing the target, anyone can estimate the
difficulty using statistics and therefore know roughly how much work was needed difficulty using statistics and therefore know roughly how much work was needed
@ -819,13 +819,13 @@ to find such a nonce.
[TIP] [TIP]
==== ====
The Proof-of-Work must produce a hash that is _less than_ the target. A The PoW must produce a hash that is _less than_ the target. A
higher target means it is less difficult to find a hash that is below higher target means it is less difficult to find a hash that is below
the target. A lower target means it is more difficult to find a hash the target. A lower target means it is more difficult to find a hash
below the target. The target and difficulty are inversely related. below the target. The target and difficulty are inversely related.
==== ====
Bitcoin's Proof-of-Work is very similar to the challenge Bitcoin's PoW is very similar to the challenge
shown in <<sha256_example_generator_output2>>. The miner constructs a shown in <<sha256_example_generator_output2>>. The miner constructs a
candidate block filled with transactions. Next, the miner calculates the candidate block filled with transactions. Next, the miner calculates the
hash of this block's header and sees if it is smaller than the current hash of this block's header and sees if it is smaller than the current
@ -843,7 +843,7 @@ enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoi
Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("Proof-of-Work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("Proof-of-Work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target
bits" or just "bits," which in block 277,316 has the value of bits" or just "bits," which in block 277,316 has the value of
+0x1903a30c+. This notation expresses the Proof-of-Work target as a +0x1903a30c+. This notation expresses the proof-of-work target as a
coefficient/exponent format, with the first two hexadecimal digits for coefficient/exponent format, with the first two hexadecimal digits for
the exponent and the next six hex digits as the coefficient. In this the exponent and the next six hex digits as the coefficient. In this
block, therefore, the exponent is +0x19+ and the coefficient is block, therefore, the exponent is +0x19+ and the coefficient is
@ -886,7 +886,7 @@ switching back to hexadecimal:
++++ ++++
This means that a valid block for height 277,316 is one that has a block This means that a valid block for height 277,316 is one that has a block
header hash that is less than the target. In binary that number must header hash less than the target. In binary that number must
have more than 60 leading bits set to zero. With this level of have more than 60 leading bits set to zero. With this level of
difficulty, a single miner processing 1 trillion hashes per second (1 difficulty, a single miner processing 1 trillion hashes per second (1
terahash per second or 1 TH/sec) would only find a solution once every terahash per second or 1 TH/sec) would only find a solution once every
@ -897,7 +897,7 @@ terahash per second or 1 TH/sec) would only find a solution once every
As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and
therefore affects how long it takes to find a solution to the therefore affects how long it takes to find a solution to the
Proof-of-Work algorithm. This leads to the obvious questions: Why is the proof-of-work algorithm. This leads to the obvious questions: Why is the
difficulty adjustable, who adjusts it, and how? difficulty adjustable, who adjusts it, and how?
Bitcoin's blocks are generated every 10 minutes, on average. This is Bitcoin's blocks are generated every 10 minutes, on average. This is
@ -908,14 +908,14 @@ it is expected that computer power will continue to increase at a rapid
pace. Furthermore, the number of participants in mining and the pace. Furthermore, the number of participants in mining and the
computers they use will also constantly change. To keep the block computers they use will also constantly change. To keep the block
generation time at 10 minutes, the difficulty of mining must be adjusted generation time at 10 minutes, the difficulty of mining must be adjusted
to account for these changes. In fact, the Proof-of-Work target is a to account for these changes. In fact, the proof-of-work target is a
dynamic parameter that is periodically adjusted to meet a 10-minute dynamic parameter that is periodically adjusted to meet a 10-minute
block interval goal. In simple terms, the target is set so that the block interval goal. In simple terms, the target is set so that the
current mining power will result in a 10-minute block interval. current mining power will result in a 10-minute block interval.
How, then, is such an adjustment made in a completely decentralized How, then, is such an adjustment made in a completely decentralized
network? Retargeting occurs automatically and on every node network? Retargeting occurs automatically and on every node
independently. Every 2,016 blocks, all nodes retarget the Proof-of-Work. independently. Every 2,016 blocks, all nodes retarget the PoW.
The ratio between the actual time span and desired time span of 10 The ratio between the actual time span and desired time span of 10
minutes per block is calculated and a minutes per block is calculated and a
proportionate adjustment (up or down) is made to the target. In simple proportionate adjustment (up or down) is made to the target. In simple
@ -940,7 +940,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
<<retarget_code>> shows the code used in the Bitcoin Core client. <<retarget_code>> shows the code used in the Bitcoin Core client.
[[retarget_code]] [[retarget_code]]
.Retargeting the Proof-of-Work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp .Retargeting the proof of work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
==== ====
[source,cpp] [source,cpp]
---- ----
@ -997,7 +997,7 @@ electricity. High-performance mining systems are about as efficient as
possible with the current generation of silicon fabrication, converting possible with the current generation of silicon fabrication, converting
electricity into hashing computation at the highest rate possible. The electricity into hashing computation at the highest rate possible. The
primary influence on the mining market is the price of one kilowatt-hour primary influence on the mining market is the price of one kilowatt-hour
of electricity in bitcoin, because that determines the profitability of of electricity in bitcoin because that determines the profitability of
mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining
market. market.
@ -1101,7 +1101,7 @@ The independent validation also ensures that only blocks that follow the
consensus rules are incorporated in the blockchain, thus earning consensus rules are incorporated in the blockchain, thus earning
their miners the reward. Blocks that violate the rules are rejected their miners the reward. Blocks that violate the rules are rejected
and not only lose their miners the reward, but also waste the effort expended to find and not only lose their miners the reward, but also waste the effort expended to find
a Proof-of-Work solution, thus incurring upon those miners all of the costs of creating a a proof-of-work solution, thus incurring upon those miners all of the costs of creating a
block but giving them none of the rewards. block but giving them none of the rewards.
When a node receives a new block, it will validate the block by checking When a node receives a new block, it will validate the block by checking
@ -1109,20 +1109,20 @@ it against a long list of criteria that must all be met; otherwise, the
block is rejected. These criteria can be seen in the Bitcoin Core client block is rejected. These criteria can be seen in the Bitcoin Core client
in the functions +CheckBlock+ and +CheckBlockHeader+ and include: in the functions +CheckBlock+ and +CheckBlockHeader+ and include:
- The block data structure is syntactically valid - The block data structure is syntactically valid.
- The block header hash is less than the target (enforces the - The block header hash is less than the target (enforces the
Proof-of-Work) proof of work).
- The block timestamp is between the MTP and two - The block timestamp is between the MTP and two
hours in the future (allowing for time errors) hours in the future (allowing for time errors).
- The block weight is within acceptable limits - The block weight is within acceptable limits.
- The first transaction (and only the first) is a coinbase transaction - The first transaction (and only the first) is a coinbase transaction.
- All transactions within the block are valid using the transaction - All transactions within the block are valid using the transaction
checklist discussed in <<tx_verification>> checklist discussed in <<tx_verification>>.
The independent validation of each new block by every node on the The independent validation of each new block by every node on the
network ensures that the miners cannot cheat. In previous sections we network ensures that the miners cannot cheat. In previous sections we
@ -1135,7 +1135,7 @@ the entire block invalid, which would result in the block being rejected
and, therefore, that transaction would never become part of the blockchain. and, therefore, that transaction would never become part of the blockchain.
The miners have to construct a block, based on the shared rules 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 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 PoW. To do so, they expend a lot of electricity in mining, and
if they cheat, all the electricity and effort is wasted. This is why if they cheat, all the electricity and effort is wasted. This is why
independent validation is a key component of ((("bitcoins", "mining", "validating blocks", startref="bitcoin-mining-validate")))((("mining", "validating blocks", startref="mining-validate")))((("blocks", "validating", startref="block-validate")))((("validating", "blocks", startref="validate-block")))((("decentralized consensus", "validating blocks", startref="decentral-consensus-validate")))((("nodes", "validating blocks", startref="nodes-validate")))decentralized consensus. independent validation is a key component of ((("bitcoins", "mining", "validating blocks", startref="bitcoin-mining-validate")))((("mining", "validating blocks", startref="mining-validate")))((("blocks", "validating", startref="block-validate")))((("validating", "blocks", startref="validate-block")))((("decentralized consensus", "validating blocks", startref="decentral-consensus-validate")))((("nodes", "validating blocks", startref="nodes-validate")))decentralized consensus.
@ -1146,14 +1146,14 @@ independent validation is a key component of ((("bitcoins", "mining", "validatin
The final ((("bitcoins", "mining", "assembling blockchain", id="bitcoin-mining-assemble")))((("mining", "assembling blockchain", id="mining-assemble")))((("blockchain", "assembling", id="blockchain-assemble")))((("decentralized consensus", "assembling blockchain", id="decentral-consensus-assemble")))part in Bitcoin's decentralized The final ((("bitcoins", "mining", "assembling blockchain", id="bitcoin-mining-assemble")))((("mining", "assembling blockchain", id="mining-assemble")))((("blockchain", "assembling", id="blockchain-assemble")))((("decentralized consensus", "assembling blockchain", id="decentral-consensus-assemble")))part in Bitcoin's decentralized
consensus mechanism is the assembly of blocks into chains and the consensus mechanism is the assembly of blocks into chains and the
selection of the chain with the most Proof-of-Work. selection of the chain with the most proof of work.
A _best blockchain_ is whichever valid chain of blocks has A _best blockchain_ is whichever valid chain of blocks has
the most cumulative Proof-of-Work associated with it. the most cumulative PoW associated with it.
The The
best chain may also have branches with blocks that are "siblings" to 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 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 best chain. They are kept for future reference in case one of those
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 they're usually the result of an
almost simultaneous mining of different blocks at the same height. almost simultaneous mining of different blocks at the same height.
@ -1234,7 +1234,7 @@ deliver more mining power in a single box than the entire Bitcoin
network in 2010. network in 2010.
At the time of writing, it is believed that there are no more giant At the time of writing, it is believed that there are no more giant
leaps left in Bitcoin mining equipment, leaps left in Bitcoin mining equipment
because the industry has reached the forefront of((("Moore&#x27;s Law"))) Moore's Law, which because the industry has reached the forefront of((("Moore&#x27;s Law"))) Moore's Law, which
stipulates that computing density will double approximately every 18 stipulates that computing density will double approximately every 18
months. Still, the mining power of the network continues to advance at months. Still, the mining power of the network continues to advance at
@ -1268,7 +1268,7 @@ extra nonce space, allowing them to explore a much larger range of block
header values to find valid blocks. The coinbase transaction is included header values to find valid blocks. The coinbase transaction is included
in the merkle tree, which means that any change in the coinbase script in the merkle tree, which means that any change in the coinbase script
causes the merkle root to change. Eight bytes of extra nonce, plus the 4 causes the merkle root to change. Eight bytes of extra nonce, plus the 4
bytes of "standard" nonce allow miners to explore a total 2^96^ (8 bytes of "standard" nonce, allow miners to explore a total 2^96^ (8
followed by 28 zeros) possibilities _per second_ without having to followed by 28 zeros) possibilities _per second_ without having to
modify the timestamp. modify the timestamp.
@ -1318,9 +1318,9 @@ server while mining, synchronizing their efforts with the other miners.
Thus, the pool miners share the effort to mine a block and then share in Thus, the pool miners share the effort to mine a block and then share in
the rewards. the rewards.
Successful blocks pay the reward to a pool Bitcoin address, rather than Successful blocks pay the reward to a pool Bitcoin address rather than to
individual miners. The pool server will periodically make payments to individual miners. The pool server will periodically make payments to
the miners' Bitcoin addresses, once their share of the rewards has the miners' Bitcoin addresses once their share of the rewards has
reached a certain threshold. Typically, the pool server charges a reached a certain threshold. Typically, the pool server charges a
percentage fee of the rewards for providing the pool-mining service. percentage fee of the rewards for providing the pool-mining service.
@ -1340,14 +1340,14 @@ will be mining with a few tens of a kilowatt of electricity, others will
be running a data center consuming megawatts of power. How does a be running a data center consuming megawatts of power. How does a
mining pool measure the individual contributions, so as to fairly mining pool measure the individual contributions, so as to fairly
distribute the rewards, without the possibility of cheating? The answer distribute the rewards, without the possibility of cheating? The answer
is to use Bitcoin's Proof-of-Work algorithm to measure each pool miner's is to use Bitcoin's proof-of-work algorithm to measure each pool miner's
contribution, but set at a lower difficulty so that even the smallest contribution, but set at a lower difficulty so that even the smallest
pool miners win a share frequently enough to make it worthwhile to pool miners win a share frequently enough to make it worthwhile to
contribute to the pool. By setting a lower difficulty for earning contribute to the pool. By setting a lower difficulty for earning
shares, the pool measures the amount of work done by each miner. Each shares, the pool measures the amount of work done by each miner. Each
time a pool miner finds a block header hash that is less than the pool time a pool miner finds a block header hash that is less than the pool
target, they prove they have done the hashing work to find that result. target, they prove they have done the hashing work to find that result.
That header ultimately commits to the coinbase transaction and so it can That header ultimately commits to the coinbase transaction and can
be used to prove the miner used a coinbase transaction that would have be used to prove the miner used a coinbase transaction that would have
paid the block reward to the pool. Each pool miner is given a paid the block reward to the pool. Each pool miner is given a
slightly different coinbase transaction template so each of them hashes slightly different coinbase transaction template so each of them hashes
@ -1503,7 +1503,7 @@ product without paying for it.
Let's examine a practical example of a 51% attack. In the first chapter, Let's examine a practical example of a 51% attack. In the first chapter,
we looked at a transaction between Alice and Bob. Bob, the seller, is we looked at a transaction between Alice and Bob. Bob, the seller, is
willing to accept payment without waiting for willing to accept payment without waiting for
confirmation (mining in a block), because the risk of a double-spend on confirmation (mining in a block) because the risk of a double-spend on
a small item is low in comparison to the convenience of rapid a small item is low in comparison to the convenience of rapid
customer service. This is similar to the practice of coffee shops that customer service. This is similar to the practice of coffee shops that
accept credit card payments without a signature for amounts below $25, accept credit card payments without a signature for amounts below $25,
@ -1531,7 +1531,7 @@ Mallory's transaction is included in a block. Paul directs the mining
pool to remine the same block height as the block containing Mallory's pool to remine the same block height as the block containing Mallory's
transaction, replacing Mallory's payment to Carol with a transaction transaction, replacing Mallory's payment to Carol with a transaction
that double-spends the same input as Mallory's payment. The double-spend 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, 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 instead of paying it to Carol, essentially allowing Mallory to keep the
bitcoins. 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 so as to make the chain containing the double-spend transaction longer
@ -1541,7 +1541,7 @@ the new (longer) chain, the double-spent transaction replaces the
original payment to Carol. Carol is now missing the three paintings and original payment to Carol. Carol is now missing the three paintings and
also has no 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 pool participants might remain blissfully unaware of the double-spend
attempt, because they mine with automated miners and cannot monitor attempt because they mine with automated miners and cannot monitor
every transaction or block. every transaction or block.
To protect against this To protect against this
@ -1572,9 +1572,9 @@ Despite its ((("majority attacks", startref="majority-attack")))((("51% attacks"
of the hashing power. In fact, such an attack can be attempted with a 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 smaller percentage of the hashing power. The 51% threshold is simply the
level at which such an attack is almost guaranteed to succeed. A level at which such an attack is almost guaranteed to succeed. A
hashrate 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 "stronger" group is more likely to win. With less hashing power, the
probability of success is reduced, because other miners control the probability of success is reduced because other miners control the
generation of some blocks with their "honest" mining power. One way to generation of some blocks with their "honest" mining power. One way to
look at it is that the more hashing power an attacker has, the longer 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 the fork he can deliberately create, the more blocks in the recent past
@ -1596,7 +1596,7 @@ Not all attackers will be motivated by profit, however. One potential
attack scenario is where an attacker intends to disrupt the Bitcoin attack scenario is where an attacker intends to disrupt the Bitcoin
network without the possibility of profiting from such disruption. A 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 investment and covert planning but could conceivably be launched by a
well-funded, most likely state-sponsored, attacker. Alternatively, a well-funded, most likely state-sponsored, attacker. Alternatively, a
well-funded attacker could attack Bitcoin by simultaneously well-funded attacker could attack Bitcoin by simultaneously
amassing mining hardware, compromising pool operators, and attacking amassing mining hardware, compromising pool operators, and attacking
@ -1638,7 +1638,7 @@ after one or more blocks are mined.
There is another scenario in which the network may diverge into There is another scenario in which the network may diverge into
following two chains: a change in the consensus rules. This type of fork following two chains: a change in the consensus rules. This type of fork
is called a _hard fork_, because after the fork the network may not is called a _hard fork_, because after the fork, the network may not
converge onto a single chain. Instead, the two chains can evolve converge onto a single chain. Instead, the two chains can evolve
independently. Hard forks occur when part of the network is operating independently. Hard forks occur when part of the network is operating
under a different set of consensus rules than the rest of the network. under a different set of consensus rules than the rest of the network.
@ -1676,7 +1676,7 @@ containing this transaction.
Any node or miner that has not upgraded the software to validate foocoin Any node or miner that has not upgraded the software to validate foocoin
is now unable to process block 7b. From their perspective, is now unable to process block 7b. From their perspective,
both the transaction that contained a foocoin and block 7b that both the transaction that contained a foocoin and block 7b that
contained that transaction are invalid, because they are evaluating them contained that transaction are invalid because they are evaluating them
based upon the old consensus rules. These nodes will reject the based upon the old consensus rules. These nodes will reject the
transaction and the block and will not propagate them. Any miners that transaction and the block and will not propagate them. Any miners that
are using the old rules will not accept block 7b and will continue to are using the old rules will not accept block 7b and will continue to
@ -1810,7 +1810,7 @@ that do not have near-unanimous support are considered too contentious
to attempt without risking a partition of the system. to attempt without risking a partition of the system.
Already we have seen the emergence of new methodologies to address the 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, risks of hard forks. In the next section, we will look at soft forks
and the methods for signaling and activation of and the methods for signaling and activation of
consensus modifications. consensus modifications.
@ -1872,7 +1872,7 @@ to increasing the future cost of code maintenance because of design
trade-offs made in the past. Code complexity in turn increases the trade-offs made in the past. Code complexity in turn increases the
likelihood of bugs and security vulnerabilities. likelihood of bugs and security vulnerabilities.
Validation relaxation:: Unmodified clients see transactions as valid, Validation relaxation:: Unmodified clients see transactions as valid
without evaluating the modified consensus rules. In effect, the without evaluating the modified consensus rules. In effect, the
unmodified clients are not validating using the full range of consensus unmodified clients are not validating using the full range of consensus
rules, as they are blind to the new rules. This applies to NOP-based rules, as they are blind to the new rules. This applies to NOP-based
@ -1919,7 +1919,7 @@ version to "2," instead of "1." This did not immediately make version
invalid and all version "2" blocks would be required to contain the invalid and all version "2" blocks would be required to contain the
block height in the coinbase to be valid. block height in the coinbase to be valid.
BIP34 defined a two-step activation mechanism, based on a rolling BIP34 defined a two-step activation mechanism based on a rolling
window of 1,000 blocks. A miner would signal their individual window of 1,000 blocks. A miner would signal their individual
readiness for BIP34 by constructing blocks with "2" as the version readiness for BIP34 by constructing blocks with "2" as the version
number. Strictly speaking, these blocks did not yet have to comply with number. Strictly speaking, these blocks did not yet have to comply with
@ -1993,7 +1993,7 @@ a different bit, renewing the activation period.
Furthermore, after the +TIMEOUT+ has passed and a feature has been Furthermore, after the +TIMEOUT+ has passed and a feature has been
activated or rejected, the signaling bit can be reused for another activated or rejected, the signaling bit can be reused for another
feature without confusion. Therefore, up to 29 changes can be signaled feature without confusion. Therefore, up to 29 changes can be signaled
in parallel and after +TIMEOUT+ the bits can be "recycled" to propose in parallel and after +TIMEOUT+, the bits can be "recycled" to propose
new changes. new changes.
[NOTE] [NOTE]
@ -2014,7 +2014,7 @@ number.
bit:: 0 through 28, the bit in the block version that miners use to bit:: 0 through 28, the bit in the block version that miners use to
signal approval for this proposal. signal approval for this proposal.
starttime:: The time (based on median time past, or MTP) that signaling starttime:: The time (based on MTP) that signaling
starts after which the bit's value is interpreted as signaling readiness starts after which the bit's value is interpreted as signaling readiness
for the proposal. for the proposal.
@ -2030,7 +2030,7 @@ later.
BIP9 offers a proposal state diagram to illustrate the various stages BIP9 offers a proposal state diagram to illustrate the various stages
and transitions for a proposal, as shown in <<bip9states>>. and transitions for a proposal, as shown in <<bip9states>>.
Proposals start in the +DEFINED+ state, once their parameters are known Proposals start in the +DEFINED+ state once their parameters are known
(defined) in the Bitcoin software. For blocks with MTP after the start (defined) in the Bitcoin software. For blocks with MTP after the start
time, the proposal state transitions to +STARTED+. If the voting time, the proposal state transitions to +STARTED+. If the voting
threshold is exceeded within a retarget period and the timeout has not threshold is exceeded within a retarget period and the timeout has not
@ -2100,7 +2100,7 @@ Software was published that used BIP8 to attempt to activate the
taproot proposal in 2021, and there was evidence that at least a taproot proposal in 2021, and there was evidence that at least a
small number of users ran that software. Some of those users also claim small number of users ran that software. Some of those users also claim
that their willingness to use BIP8 to force miners to activate taproot that their willingness to use BIP8 to force miners to activate taproot
was the reason it did eventually activate. They claim that, if taproot was the reason it did eventually activate. They claim that if taproot
had not been activated quickly, other users would have also begun had not been activated quickly, other users would have also begun
running BIP8. Unfortunately, there's no way to prove what would have running BIP8. Unfortunately, there's no way to prove what would have
happened, and so we can't say for sure how much BIP8 contributed to the happened, and so we can't say for sure how much BIP8 contributed to the
@ -2136,7 +2136,7 @@ future attempt to activate a ((("consensus rules", "soft forks", "speedy trial a
=== Consensus Software Development === Consensus Software Development
Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve and there is much Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve, and there is much
discussion on the various mechanisms for changing the consensus rules. 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" consensus for changes. As a decentralized system, it has no "authority"

6
ch13_security.adoc
View File

@ -36,7 +36,7 @@ payment is open-ended because it contains the user's private identifier
to the identifier can "pull" funds and charge the owner again and again. to the identifier can "pull" funds and charge the owner again and again.
Thus, the payment network has to be secured end-to-end with encryption Thus, the payment network has to be secured end-to-end with encryption
and must ensure that no eavesdroppers or intermediaries can compromise and must ensure that no eavesdroppers or intermediaries can compromise
the payment traffic, in transit or when it is stored (at rest). If a bad the payment traffic in transit or when it is stored (at rest). If a bad
actor gains access to the system, he can compromise current transactions actor gains access to the system, he can compromise current transactions
_and_ payment tokens that can be used to create new transactions. Worse, _and_ payment tokens that can be used to create new transactions. Worse,
when customer data is compromised, the customers are exposed to identity when customer data is compromised, the customers are exposed to identity
@ -81,7 +81,7 @@ for their customers.
Unless you are prepared to invest heavily in operational security, Unless you are prepared to invest heavily in operational security,
multiple layers of access control, and audits (as the traditional banks multiple layers of access control, and audits (as the traditional banks
do) you should think very carefully before taking funds outside of do), you should think very carefully before taking funds outside of
Bitcoin's decentralized security context. Even if you have the funds and Bitcoin's decentralized security context. Even if you have the funds and
discipline to implement a robust security model, such a design merely discipline to implement a robust security model, such a design merely
replicates the fragile model of traditional financial networks, plagued replicates the fragile model of traditional financial networks, plagued
@ -262,7 +262,7 @@ Multisignature addresses secure funds by requiring more than one
signature to make a payment. The signing keys should be stored in a signature to make a payment. The signing keys should be stored in a
number of different locations and under the control of different people. number of different locations and under the control of different people.
In a corporate environment, for example, the keys should be generated In a corporate environment, for example, the keys should be generated
independently and held by several company executives, to ensure no independently and held by several company executives to ensure no
single person can compromise the funds. Multisignature addresses can single person can compromise the funds. Multisignature addresses can
also offer redundancy, where a single person holds several keys that are also offer redundancy, where a single person holds several keys that are
stored in different locations. stored in different locations.

88
ch14_applications.adoc
View File

@ -25,7 +25,7 @@ Immutability:: Once a transaction is recorded in the blockchain and
sufficient work has been added with subsequent blocks, the transaction's sufficient work has been added with subsequent blocks, the transaction's
data becomes practically immutable. Immutability is underwritten by energy, as data becomes practically immutable. Immutability is underwritten by energy, as
rewriting the blockchain requires the expenditure of energy to produce rewriting the blockchain requires the expenditure of energy to produce
Proof-of-Work. The energy required and therefore the degree of PoW. The energy required and therefore the degree of
immutability increases with the amount of work committed on top of the immutability increases with the amount of work committed on top of the
block containing a transaction. block containing a transaction.
@ -65,9 +65,9 @@ without invalidating the signature, thus invalidating the transaction
itself. itself.
Transaction Atomicity:: Bitcoin transactions are atomic. They are either Transaction Atomicity:: Bitcoin transactions are atomic. They are either
valid and confirmed (mined) or not. Partial transactions cannot be mined valid and confirmed (mined) or not. Partial transactions cannot be mined,
and there is no interim state for a transaction. At any point in time a and there is no interim state for a transaction. At any point in time a
transaction is either mined, or not. transaction is either mined or not.
Discrete (Indivisible) Units of Value:: Transaction outputs are discrete Discrete (Indivisible) Units of Value:: Transaction outputs are discrete
and indivisible units of value. They can either be spent or unspent, in and indivisible units of value. They can either be spent or unspent, in
@ -98,10 +98,10 @@ Recording External State:: A transaction can commit to a data value, via
+OP_RETURN+ or pay to contract, representing a state transition in an external state +OP_RETURN+ or pay to contract, representing a state transition in an external state
machine. machine.
Predictable Issuance:: Less than 21 million bitcoin will be issued, at a Predictable Issuance:: Less than 21 million bitcoin will be issued at a
predictable rate. predictable rate.
The list of building blocks is not complete and more are added with each The list of building blocks is not complete, and more are added with each
new feature introduced ((("Bitcoin", "as application platform", "primitives, list of", secondary-sortas="application platform", startref="bitcoin-app-platform-primitive")))((("application platform, Bitcoin as", "primitives, list of", startref="app-platform-primitive")))((("primitives", startref="primitive-list")))((("building blocks", startref="build-block")))into Bitcoin. new feature introduced ((("Bitcoin", "as application platform", "primitives, list of", secondary-sortas="application platform", startref="bitcoin-app-platform-primitive")))((("application platform, Bitcoin as", "primitives, list of", startref="app-platform-primitive")))((("primitives", startref="primitive-list")))((("building blocks", startref="build-block")))into Bitcoin.
=== Applications from Building Blocks === Applications from Building Blocks
@ -115,7 +115,7 @@ Proof-of-Existence (Digital Notary):: Immutability + Timestamp + Durability.
A transaction on the blockchain can commit to a value, A transaction on the blockchain can commit to a value,
proving that a piece of data existed at the time proving that a piece of data existed at the time
it was recorded (Timestamp). The commitment cannot be modified ex-post-facto it was recorded (Timestamp). The commitment cannot be modified ex-post-facto
(Immutability) and the proof will be stored permanently (Durability). (Immutability), and the proof will be stored permanently (Durability).
Kickstarter (Lighthouse):: Consistency + Atomicity + Integrity. If you Kickstarter (Lighthouse):: Consistency + Atomicity + Integrity. If you
sign one input and the output (Integrity) of a fundraiser transaction, sign one input and the output (Integrity) of a fundraiser transaction,
@ -231,14 +231,14 @@ validation. That brings ((("colored coins application", "P2C (pay to contract)"
==== Client-Side Validation ==== Client-Side Validation
Bob had ((("colored coins application", "client-side validation")))((("client-side validation")))((("validating", "with client-side validation", secondary-sortas="client-side validation")))some colored coins associated with a UTXO. He spent that UTXO Bob had ((("colored coins application", "client-side validation")))((("client-side validation")))((("validating", "with client-side validation", secondary-sortas="client-side validation")))some colored coins associated with a UTXO. He spent that UTXO
in a way that committed to a contract which indicated how the next in a way that committed to a contract that indicated how the next
receiver (or receivers) of the colored coins will prove their ownership receiver (or receivers) of the colored coins will prove their ownership
over the coins in order to further spend them. over the coins in order to further spend them.
In practice, Bob's P2C contract likely simply committed to one or more In practice, Bob's P2C contract likely simply committed to one or more
unique identifiers for the UTXOs that will be used as single-use seals unique identifiers for the UTXOs that will be used as single-use seals
for deciding when the colored coins are next spent. For example, Bob's for deciding when the colored coins are next spent. For example, Bob's
contract may have indicated that the UTXO that Alice received to her P2C contract may have indicated that the UTXO Alice received to her P2C
tweaked public key now controls half of his colored coins, with the tweaked public key now controls half of his colored coins, with the
other half of his colored coins now being assigned to a different UTXO other half of his colored coins now being assigned to a different UTXO
that may have nothing to do with the transaction between Alice and Bob. that may have nothing to do with the transaction between Alice and Bob.
@ -341,7 +341,7 @@ Translated forwarding::
Native forwarding is conceptually simpler but essentially requires a Native forwarding is conceptually simpler but essentially requires a
separate Lightning Network for every asset. Translated forwarding separate Lightning Network for every asset. Translated forwarding
allows building on the economies of scale of the Bitcoin Lightning allows building on the economies of scale of the Bitcoin Lightning
Network but it may be vulnerable to a problem called((("free American call option"))) the _free American Network, but it may be vulnerable to a problem called((("free American call option"))) the _free American
call option_, where a receiver may selectively accept or reject certain call option_, where a receiver may selectively accept or reject certain
payments depending on recent changes to the exchange rate in order to payments depending on recent changes to the exchange rate in order to
siphon money from the hop next to them. Although there's no known siphon money from the hop next to them. Although there's no known
@ -361,7 +361,7 @@ working on BIPs that may be available after this book goes((("Bitcoin", "as appl
=== Payment Channels and State Channels === Payment Channels and State Channels
_Payment channels_ are ((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", id="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", id="app-platform-payment")))((("payment channels", id="payment-channel")))a trustless mechanism for exchanging Bitcoin _Payment channels_ are ((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", id="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", id="app-platform-payment")))((("payment channels", id="payment-channel")))a trustless mechanism for exchanging Bitcoin
transactions between two parties, outside of the Bitcoin blockchain. transactions between two parties outside of the Bitcoin blockchain.
These transactions, which would be valid if settled on the Bitcoin These transactions, which would be valid if settled on the Bitcoin
blockchain, are held offchain instead, waiting for blockchain, are held offchain instead, waiting for
eventual batch settlement. Because the transactions are not settled, eventual batch settlement. Because the transactions are not settled,
@ -370,15 +370,15 @@ extremely high transaction throughput, low latency, and
fine granularity. fine granularity.
Actually, the term _channel_ is a metaphor. State channels are virtual Actually, the term _channel_ is a metaphor. State channels are virtual
constructs represented by the exchange of state between two parties, constructs represented by the exchange of state between two parties
outside of the blockchain. There are no "channels" per se and the outside of the blockchain. There are no "channels" per se, and the
underlying data transport mechanism is not the channel. We use the term underlying data transport mechanism is not the channel. We use the term
channel to represent the relationship and shared state between two _channel_ to represent the relationship and shared state between two
parties, outside of the blockchain. parties outside of the blockchain.
To further explain this To further explain this
concept, think of a TCP stream. From the perspective of higher-level concept, think of a TCP stream. From the perspective of higher-level
protocols it is a "socket" connecting two applications across the protocols, it is a "socket" connecting two applications across the
internet. But if you look at the network traffic, a TCP stream is just a internet. But if you look at the network traffic, a TCP stream is just a
virtual channel over IP packets. Each endpoint of the TCP stream virtual channel over IP packets. Each endpoint of the TCP stream
sequences and assembles IP packets to create the illusion of a stream of sequences and assembles IP packets to create the illusion of a stream of
@ -404,7 +404,7 @@ the state being altered is the balance of a virtual currency.
==== State Channels&#x2014;Basic Concepts and Terminology ==== State Channels&#x2014;Basic Concepts and Terminology
A state channel((("payment channels", "state channels", id="payment-channel-state")))((("state channels", id="state-channel-terminology")))((("transactions", "state channels", id="transaction-state"))) is A state channel((("payment channels", "state channels", id="payment-channel-state")))((("state channels", id="state-channel-terminology")))((("transactions", "state channels", id="transaction-state"))) is
established between two parties, through a transaction that locks a established between two parties through a transaction that locks a
shared state on the blockchain. This is called ((("funding transactions")))the _funding transaction_. shared state on the blockchain. This is called ((("funding transactions")))the _funding transaction_.
This single transaction must be transmitted to This single transaction must be transmitted to
the network and mined to establish the channel. In the example of a the network and mined to establish the channel. In the example of a
@ -438,7 +438,7 @@ In the entire lifetime of the channel, only two transactions need to be
submitted for mining on the blockchain: the funding and settlement submitted for mining on the blockchain: the funding and settlement
transactions. In between these two states, the two parties can exchange transactions. In between these two states, the two parties can exchange
any number of commitment transactions that are never seen by anyone any number of commitment transactions that are never seen by anyone
else, nor submitted to the blockchain. else or submitted to the blockchain.
<<payment_channel>> illustrates a payment channel between Bob and Alice, <<payment_channel>> illustrates a payment channel between Bob and Alice,
showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions. showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions.
@ -453,7 +453,7 @@ To
explain ((("payment channels", "example of", id="payment-channel-example")))state channels, we start with a very simple example. We explain ((("payment channels", "example of", id="payment-channel-example")))state channels, we start with a very simple example. We
demonstrate a one-way channel, meaning that value is flowing in one demonstrate a one-way channel, meaning that value is flowing in one
direction only. We will also start with the naive assumption that no one direction only. We will also start with the naive assumption that no one
is trying to cheat, to keep things simple. Once we have the basic is trying to cheat to keep things simple. Once we have the basic
channel idea explained, we will then look at what it takes to make it channel idea explained, we will then look at what it takes to make it
trustless so that neither party _can_ cheat, even if they are trying to. trustless so that neither party _can_ cheat, even if they are trying to.
@ -525,7 +525,7 @@ second commitment transaction, together with another second of video.
In this way, Emma's software continues to send commitment transactions In this way, Emma's software continues to send commitment transactions
to Fabian's server in exchange for streaming video. The balance of the to Fabian's server in exchange for streaming video. The balance of the
channel gradually accumulates in favor of Fabian, as Emma consumes more channel gradually accumulates in favor of Fabian as Emma consumes more
seconds of video. Let's say Emma watches 600 seconds (10 minutes) of seconds of video. Let's say Emma watches 600 seconds (10 minutes) of
video, creating and signing 600 commitment transactions. The last video, creating and signing 600 commitment transactions. The last
commitment transaction (#600) will have two outputs, splitting the commitment transaction (#600) will have two outputs, splitting the
@ -564,7 +564,7 @@ to fix those:
- While the channel is running, Emma can take any of the commitment - While the channel is running, Emma can take any of the commitment
transactions Fabian has countersigned and transmit one to the transactions Fabian has countersigned and transmit one to the
blockchain. Why pay for 600 seconds of video, if she can transmit blockchain. Why pay for 600 seconds of video if she can transmit
commitment transaction #1 and only pay for 1 second of video? The commitment transaction #1 and only pay for 1 second of video? The
channel fails because Emma can cheat by broadcasting a prior channel fails because Emma can cheat by broadcasting a prior
commitment that is in her favor. commitment that is in her favor.
@ -578,11 +578,11 @@ transaction at the same time. She signs the funding transaction but
doesn't transmit it to anyone. Emma transmits only the refund doesn't transmit it to anyone. Emma transmits only the refund
transaction to Fabian and obtains his signature. transaction to Fabian and obtains his signature.
The refund transaction acts as the first commitment transaction and its The refund transaction acts as the first commitment transaction, and its
timelock establishes the upper bound for the channel's life. In this timelock establishes the upper bound for the channel's life. In this
case, Emma could set the lock time to 30 days or 4,320 blocks into the case, Emma could set the lock time to 30 days or 4,320 blocks into the
future. All subsequent commitment transactions must have a shorter future. All subsequent commitment transactions must have a shorter
timelock, so that they can be redeemed before the refund transaction. timelock so they can be redeemed before the refund transaction.
Now that Emma has a fully signed refund transaction, she can confidently Now that Emma has a fully signed refund transaction, she can confidently
transmit the signed funding transaction knowing that she can eventually, transmit the signed funding transaction knowing that she can eventually,
@ -591,7 +591,7 @@ disappears.
Every commitment transaction the parties exchange during the life of the Every commitment transaction the parties exchange during the life of the
channel will be timelocked into the future. But the delay will be channel will be timelocked into the future. But the delay will be
slightly shorter for each commitment so the most recent commitment can slightly shorter for each commitment, so the most recent commitment can
be redeemed before the prior commitment it invalidates. Because of the be redeemed before the prior commitment it invalidates. Because of the
lock time, neither party can successfully propagate any of the lock time, neither party can successfully propagate any of the
commitment transactions until their timelock expires. If all goes well, commitment transactions until their timelock expires. If all goes well,
@ -637,14 +637,14 @@ construct more flexible, useful, and sophisticated state channels.
Timelocks are not the only way to invalidate prior commitment Timelocks are not the only way to invalidate prior commitment
transactions. In the next sections we will see how a revocation key can transactions. In the next sections we will see how a revocation key can
be used to achieve the same result. Timelocks are effective but they be used to achieve the same result. Timelocks are effective, but they
have two distinct disadvantages. By establishing a maximum timelock when have two distinct disadvantages. By establishing a maximum timelock when
the channel is first opened, they limit the lifetime of the channel. the channel is first opened, they limit the lifetime of the channel.
Worse, they force channel implementations to strike a balance between Worse, they force channel implementations to strike a balance between
allowing long-lived channels and forcing one of the participants to wait allowing long-lived channels and forcing one of the participants to wait
a very long time for a refund in case of premature closure. For example, a very long time for a refund in case of premature closure. For example,
if you allow the channel to remain open for 30 days, by setting the if you allow the channel to remain open for 30 days by setting the
refund timelock to 30 days, if one of the parties disappears immediately refund timelock to 30 days, if one of the parties disappears immediately,
the other party must wait 30 days for a refund. The more distant the the other party must wait 30 days for a refund. The more distant the
endpoint, the more distant the refund. endpoint, the more distant the refund.
@ -689,10 +689,10 @@ transaction and builds a settlement transaction that is identical in
every way except that it omits the timelock. Both parties can sign this every way except that it omits the timelock. Both parties can sign this
settlement transaction knowing there is no way to cheat and get a more settlement transaction knowing there is no way to cheat and get a more
favorable balance. By cooperatively signing and transmitting the favorable balance. By cooperatively signing and transmitting the
settlement transaction they can close the channel and redeem their settlement transaction, they can close the channel and redeem their
balance immediately. Worst case, one of the parties can be petty, refuse balance immediately. Worst case, one of the parties can be petty, refuse
to cooperate, and force the other party to do a unilateral close with to cooperate, and force the other party to do a unilateral close with
the most recent commitment transaction. But if they do that, they have the most recent commitment transaction. If they do that, they have
to wait for their funds ((("payment channels", "trustless channels", startref="payment-channel-trustless")))((("trustless channels", startref="trustless-channel")))((("timelocks", "trustless channels", startref="timelock-trustless")))((("commitment transactions", "trustless channels", startref="commit-trustless")))too. to wait for their funds ((("payment channels", "trustless channels", startref="payment-channel-trustless")))((("trustless channels", startref="trustless-channel")))((("timelocks", "trustless channels", startref="timelock-trustless")))((("commitment transactions", "trustless channels", startref="commit-trustless")))too.
==== Asymmetric Revocable Commitments ==== Asymmetric Revocable Commitments
@ -825,7 +825,7 @@ redemption script for that output allows one party to redeem it after
key, penalizing transmission of a revoked commitment. key, penalizing transmission of a revoked commitment.
So when Hitesh creates a commitment transaction for Irene to sign, he So when Hitesh creates a commitment transaction for Irene to sign, he
makes the second output payable to himself after 1,000 blocks, or to the makes the second output payable to himself after 1,000 blocks or to the
revocation public key (of which he only knows half the secret). Hitesh revocation public key (of which he only knows half the secret). Hitesh
constructs this transaction. He will only reveal his half of the constructs this transaction. He will only reveal his half of the
revocation secret to Irene when he is ready to move to a new channel revocation secret to Irene when he is ready to move to a new channel
@ -850,8 +850,8 @@ ENDIF
CHECKSIG CHECKSIG
---- ----
Irene can confidently sign this transaction, since if transmitted it Irene can confidently sign this transaction since if transmitted, it
will immediately pay her what she is owed. Hitesh holds the transaction, will immediately pay her what she is owed. Hitesh holds the transaction
but knows that if he transmits it in a unilateral channel closing, he but knows that if he transmits it in a unilateral channel closing, he
will have to wait 1,000 blocks to get paid. will have to wait 1,000 blocks to get paid.
@ -872,7 +872,7 @@ The revocation protocol is bilateral, meaning that in each round, as the
channel state is advanced, the two parties exchange new commitments, channel state is advanced, the two parties exchange new commitments,
exchange revocation secrets for the previous commitments, and sign each exchange revocation secrets for the previous commitments, and sign each
other's new commitment transactions. After 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 make the prior state impossible to use by giving each other the
necessary revocation secrets to punish any cheating. necessary revocation secrets to punish any cheating.
Let's look at an example of how it works. One of Irene's customers wants Let's look at an example of how it works. One of Irene's customers wants
@ -883,7 +883,7 @@ reflect the new balance. They will commit to a new state (state number
bitcoins to Irene. To advance the state of the channel, they will each bitcoins to Irene. To advance the state of the channel, they will each
create new commitment transactions reflecting the new channel balance. create new commitment transactions reflecting the new channel balance.
As before, these commitment transactions are asymmetric so that the As before, these commitment transactions are asymmetric so the
commitment transaction each party holds forces them to wait if they commitment transaction each party holds forces them to wait if they
redeem it. Crucially, before signing new commitment transactions, they redeem it. Crucially, before signing new commitment transactions, they
must first exchange revocation keys to invalidate any outdated commitments. must first exchange revocation keys to invalidate any outdated commitments.
@ -891,7 +891,7 @@ In this particular case, Hitesh's interests are aligned with the real
state of the channel and therefore he has no reason to broadcast a prior state of the channel and therefore he has no reason to broadcast a prior
state. However, for Irene, state number 1 leaves her with a higher state. However, for Irene, state number 1 leaves her with a higher
balance than state 2. When Irene gives Hitesh the revocation key for her balance than state 2. When Irene gives Hitesh the revocation key for her
prior commitment transaction (state number 1) she is effectively prior commitment transaction (state number 1), she is effectively
revoking her ability to profit from regressing the channel to a prior revoking her ability to profit from regressing the channel to a prior
state because with the revocation key, Hitesh can redeem both outputs of state because with the revocation key, Hitesh can redeem both outputs of
the prior commitment transaction without delay. Meaning if Irene the prior commitment transaction without delay. Meaning if Irene
@ -919,7 +919,7 @@ channel.
Payment channels ((("payment channels", "HTLC (Hash Time Lock Contract)", id="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", id="htlc")))can be further Payment channels ((("payment channels", "HTLC (Hash Time Lock Contract)", id="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", id="htlc")))can be further
extended with a special type of smart contract that allows the extended with a special type of smart contract that allows the
participants to commit funds to a redeemable secret, with an expiration participants to commit funds to a redeemable secret, with an expiration
time. This feature is called a _Hash Time Lock Contract_, or _HTLC_, and time. This feature is called a _hash time lock contract_, or _HTLC_, and
is used in both bidirectional and routed payment channels. is used in both bidirectional and routed payment channels.
Let's first explain the "hash" part of the HTLC. To create an HTLC, the Let's first explain the "hash" part of the HTLC. To create an HTLC, the
@ -957,8 +957,8 @@ ENDIF
Anyone who knows the secret +R+, which when hashed equals to +H+, can Anyone who knows the secret +R+, which when hashed equals to +H+, can
redeem this output by exercising the first clause of the +IF+ flow. redeem this output by exercising the first clause of the +IF+ flow.
If the secret is not revealed and the HTLC claimed, after a certain If the secret is not revealed and the HTLC claimed after a certain
number of blocks the payer can claim a refund using the second clause in number of blocks, the payer can claim a refund using the second clause in
the +IF+ flow. the +IF+ flow.
This is a basic implementation of an HTLC. This type of HTLC can be This is a basic implementation of an HTLC. This type of HTLC can be
@ -1008,7 +1008,7 @@ Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
Eric by a payment channel. Creating a payment channel requires a funding Eric by a payment channel. Creating a payment channel requires a funding
transaction, which must be committed to the Bitcoin blockchain. Alice transaction, which must be committed to the Bitcoin blockchain. Alice
does not want to open a new payment channel and commit more of her does not want to open a new payment channel and commit more of her
funds. Is there a way to pay Eric, indirectly? funds. Is there a way to pay Eric indirectly?
<<ln_payment_process>> shows the step-by-step process of routing a <<ln_payment_process>> shows the step-by-step process of routing a
payment from Alice to Eric, through a series of HTLC commitments on the payment from Alice to Eric, through a series of HTLC commitments on the
@ -1113,17 +1113,17 @@ construct a _path_ through the network by connecting payment channels
with sufficient capacity. Nodes advertise routing information, including with sufficient capacity. Nodes advertise routing information, including
what channels they have open, how much capacity each channel has, and what channels they have open, how much capacity each channel has, and
what fees they charge to route payments. The routing information can be what fees they charge to route payments. The routing information can be
shared in a variety of ways and different pathfinding protocols have shared in a variety of ways, and different pathfinding protocols have
emerged as Lightning Network technology has advanced. emerged as Lightning Network technology has advanced.
Current implementations of Current implementations of
route discovery use a P2P model where nodes propagate channel route discovery use a P2P model where nodes propagate channel
announcements to their peers, in a "flooding" model, similar to how announcements to their peers in a "flooding" model, similar to how
Bitcoin propagates transactions. Bitcoin propagates transactions.
In our previous example, Alice's node uses one of these route discovery In our previous example, Alice's node uses one of these route discovery
mechanisms to find one or more paths connecting her node to Eric's node. mechanisms to find one or more paths connecting her node to Eric's node.
Once Alice's node has constructed a path, she will initialize that path Once Alice's node has constructed a path, she will initialize that path
through the network, by propagating a series of encrypted and nested through the network by propagating a series of encrypted and nested
instructions to connect each of the adjacent payment channels. instructions to connect each of the adjacent payment channels.
Importantly, this path is only known to Alice's node. All other Importantly, this path is only known to Alice's node. All other
@ -1132,10 +1132,10 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol
does not know that Bob is actually relaying a payment from Alice. She 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. 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 This is a critical feature of the Lightning Network because it ensures
privacy of payments and makes it difficult to apply surveillance, privacy of payments and makes it difficult to apply surveillance,
censorship, or blacklists. But how does Alice establish this payment censorship, or blacklists. But how does Alice establish this payment
path, without revealing anything to the intermediary nodes? path without revealing anything to the intermediary nodes?
The Lightning Network implements an onion-routed protocol based on a The Lightning Network implements an onion-routed protocol based on a
scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol
@ -1148,7 +1148,7 @@ through the Lightning Network such that:
- Other than the previous and next hops, they cannot learn about any - Other than the previous and next hops, they cannot learn about any
other nodes that are part of the path. other nodes that are part of the path.
- They cannot identify the length of the payment path, or their own - They cannot identify the length of the payment path or their own
position in that path. position in that path.
- Each part of the path is encrypted in such a way that a network-level - Each part of the path is encrypted in such a way that a network-level

6
copyright.html
View File

@ -3,7 +3,7 @@
<p class="author">by <span class="firstname">Andreas </span> <span class="othername mi">M. </span> <span class="surname">Antonopoulos</span> and <span class="firstname">David </span> <span class="othername mi">A. </span> <span class="surname">Harding</span></p> <p class="author">by <span class="firstname">Andreas </span> <span class="othername mi">M. </span> <span class="surname">Antonopoulos</span> and <span class="firstname">David </span> <span class="othername mi">A. </span> <span class="surname">Harding</span></p>
<p class="copyright">Copyright © 2023 David Harding. All rights reserved.</p> <p class="copyright">Copyright © 2024 David Harding. All rights reserved.</p>
<p class="printlocation">Printed in the United States of America.</p> <p class="printlocation">Printed in the United States of America.</p>
@ -16,8 +16,8 @@
<li><span class="staffrole">Development Editor: </span>Angela Rufino</li> <li><span class="staffrole">Development Editor: </span>Angela Rufino</li>
<li><span class="staffrole">Production Editor:</span> Clare Laylock</li> <li><span class="staffrole">Production Editor:</span> Clare Laylock</li>
<li><span class="staffrole">Copyeditor:</span> Kim Cofer</li> <li><span class="staffrole">Copyeditor:</span> Kim Cofer</li>
<li><span class="staffrole">Proofreader:</span></li> <li><span class="staffrole">Proofreader:</span> Heather Walley</li>
<li><span class="staffrole">Indexer:</span></li> <li><span class="staffrole">Indexer:</span> nSight, Inc.</li>
<li><span class="staffrole">Interior Designer:</span> David Futato</li> <li><span class="staffrole">Interior Designer:</span> David Futato</li>
<li><span class="staffrole">Cover Designer:</span> Randy Comer</li> <li><span class="staffrole">Cover Designer:</span> Randy Comer</li>
<li><span class="staffrole">Illustrator:</span> Kate Dullea</li> <li><span class="staffrole">Illustrator:</span> Kate Dullea</li>

2
meta/github_contrib.adoc
View File

@ -142,7 +142,7 @@
<li>ratijas</li> <li>ratijas</li>
<li>rating89us</li> <li>rating89us</li>
<li>Raul Siles (raulsiles)</li> <li>Raul Siles (raulsiles)</li>
<li>Reproducibility Matters (TheCharlatan)</li> <li><p class="left-align">Reproducibility Matters <span class="keep-together">(TheCharlatan)</span></p></li>
<li>Reuben Thomas (rrthomas)</li> <li>Reuben Thomas (rrthomas)</li>
<li>Robert Furse (Rfurse)</li> <li>Robert Furse (Rfurse)</li>
<li>Roberto Mannai (robermann)</li> <li>Roberto Mannai (robermann)</li>

2
meta/third_edition_changes.asciidoc
View File

@ -12,7 +12,7 @@ development in 2023 have been added.
Old Chapters 6 and 7:: Old Chapters 6 and 7::
Text from previous versions of Chapter 6, "Transactions," and Chapter 7, Text from previous versions of Chapter 6, "Transactions," and Chapter 7,
"Advanced Transactions," has been rearranged and expanded across four "Advanced Transactions," has been rearranged and expanded across four
new chapters: pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>] (the structure of txes), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>] , pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and new chapters: pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>] (the structure of txes), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>], pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and
pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>]. pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>].
<<c_transactions>>:: <<c_transactions>>::

26
preface.asciidoc
View File

@ -61,7 +61,7 @@ All the code snippets use real values and calculations where possible, so that y
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing 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. 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 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.
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.” We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_, 3rd ed., by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-098-15009-9.”
Some editions of this book are offered under an open source license, such as https://oreil.ly/RzUHE[CC-BY-NC], in which case the terms of that license apply. Some editions of this book are offered under an open source license, such as https://oreil.ly/RzUHE[CC-BY-NC], in which case the terms of that license apply.
@ -75,11 +75,11 @@ include::meta/third_edition_changes.asciidoc[]
The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc. The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here. However, note that the private keys used to construct addresses are either printed in this book or have been "burned." That means if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
[WARNING] [WARNING]
==== ====
DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever. DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader or lost forever.
==== ====
=== O'Reilly Online Learning === O'Reilly Online Learning
@ -126,25 +126,25 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
=== Contacting the Authors === Contacting the Authors
You can contact Andreas M. Antonopoulos on his personal site: You can contact Andreas M. Antonopoulos on his personal site:
link:$$https://antonopoulos.com/$$[] [.keep-together]#link:$$https://antonopoulos.com$$[].#
Follow Andreas on Facebook: Follow Andreas on Facebook:
link:$$https://facebook.com/AndreasMAntonopoulos$$[] link:$$https://facebook.com/AndreasMAntonopoulos$$[].
Follow Andreas on Twitter: Follow Andreas on Twitter:
link:$$https://twitter.com/aantonop$$[] link:$$https://twitter.com/aantonop$$[].
Follow Andreas on LinkedIn: Follow Andreas on LinkedIn:
link:$$https://linkedin.com/company/aantonop$$[] link:$$https://linkedin.com/company/aantonop$$[].
Many thanks to all of Andreas's patrons who support his work through monthly donations. You can follow his Patreon page here: Many thanks to all of Andreas's patrons who support his work through monthly donations. You can follow his Patreon page here:
link:$$https://patreon.com/aantonop$$[] link:$$https://patreon.com/aantonop$$[].
Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations are available on: Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on:
link:$$https://bitcoinbook.info/$$[] link:$$https://bitcoinbook.info$$[].
You can contact David A. Harding on his personal site: You can contact David A. Harding on his personal site:
link:$$https://dtrt.org/$$[] link:$$https://dtrt.org$$[].
=== Acknowledgments for the First and Second Editions === Acknowledgments for the First and Second Editions
@ -156,11 +156,11 @@ It is impossible to make a distinction between the Bitcoin technology and the Bi
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. 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.
Thanks also to those who supported me when I submitted my book proposal to O'Reilly, by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal. Thanks also to those who supported me when I submitted my book proposal to O'Reilly by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal.
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. 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 <<github_contrib>>. 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. 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 <<github_contrib>>. 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.