diff --git a/appb_errata.adoc b/appb_errata.adoc
index 2e03dbbe..d262ac87 100644
--- a/appb_errata.adoc
+++ b/appb_errata.adoc
@@ -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"
-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
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
@@ -37,7 +37,7 @@ occurred in July 2010, long after Bitcoin’s initial release:
+ if (pindexNew->bnChainWork > bnBestChainWork)
----
* *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
instead of saying "CPU power" it is perhaps more correct to say
"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
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
-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
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,
perhaps driving them into following the attacking miner’s policy. So
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
than about 30% of the network."
@@ -94,11 +94,11 @@ ____
this system where digital signatures are not used directly but rather a
"deterministic expression" is used instead. Just as a signature that
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
to spend a coin is known as an "encumbrance." Almost all encumbrances
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
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
@@ -185,7 +185,7 @@ the past.
____
"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
@@ -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.
+
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.
=== Calculations
diff --git a/appc_bips.adoc b/appc_bips.adoc
index 6ff5d3c0..54ebed2f 100644
--- a/appc_bips.adoc
+++ b/appc_bips.adoc
@@ -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:
_Standard_ BIP:: Describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
-_Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
-_Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
+_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. 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].
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:
-- 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).
- 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).
@@ -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)
- 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).
-- 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).
- 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.
diff --git a/author_bio.html b/author_bio.html
index 9bdf68df..d29adb57 100644
--- a/author_bio.html
+++ b/author_bio.html
@@ -5,7 +5,7 @@
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.
-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.
+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.
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.
diff --git a/ch01_intro.adoc b/ch01_intro.adoc
index 03b410ea..05b66f45 100644
--- a/ch01_intro.adoc
+++ b/ch01_intro.adoc
@@ -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:
-1. Can I trust that the money is authentic and not counterfeit?
-2. Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
-3. Can I be sure that no one else can claim this money belongs to them and not me?
+* Can I trust that the money is authentic and not counterfeit?
+* Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
+* 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.
@@ -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
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
alias of Satoshi Nakamoto (see <>). Nakamoto
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
-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
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
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
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
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.
@@ -242,9 +242,7 @@ ultimately controls your funds on your behalf. Key management software falls int
important categories based on control: _wallets_, where you
control the keys, and the funds and accounts with custodians where some
third-party controls the keys. To emphasize this point, I (Andreas)
-coined the phrase:
-
-_Your keys, your coins. Not your keys, not your coins_.
+coined the phrase: _Your keys, your coins. Not your keys, not your coins_.
Combining these categorizations, many Bitcoin wallets fall into a few
groups, with the three most common being desktop full node
@@ -275,8 +273,8 @@ to restore her wallet.
[[recovery_code_intro]]
==== 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
-code_ for their user
+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
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
that are generated by the wallet. See <> 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 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"]
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.
====
-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]]
==== 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:
-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://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")))
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
Send to transmit the transaction. Joe's mobile Bitcoin wallet constructs
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
authorized a transfer of value to Alice's new address. As the
transaction is transmitted via the peer-to-peer protocol, it quickly
diff --git a/ch02_overview.adoc b/ch02_overview.adoc
index d3f382b7..bf24698f 100644
--- a/ch02_overview.adoc
+++ b/ch02_overview.adoc
@@ -26,7 +26,7 @@ interactions between several users by sending
funds from one wallet to another. While tracking a transaction through
the Bitcoin network to the blockchain, we will use a _blockchain
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
relationships and flows between them.
@@ -67,7 +67,7 @@ Alice, ((("transactions", "spending bitcoins", id="transaction-spend")))((("bitc
acquired her first bitcoins. In <>, Alice met with
her friend Joe to exchange some cash for bitcoins. Since then, Alice has
bought additional bitcoins. Now Alice will make
-her first 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
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.
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
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.
====
-You can examine Alice's transaction to Bob's Store on the blockchain
-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's transaction on https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef[Blockstream Explorer]
-====
-----
-https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef
-----
-====
+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].
In the following sections, we will examine this transaction in more
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.
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
different uses of outputs both use never-before-seen addresses and
otherwise look identical, preventing any third party from determining
@@ -273,17 +264,17 @@ illustration purposes, we've added shading to the change outputs in
<>.
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
spent is roughly the same as the amount available in the transaction
-inputs minus the anticipated transaction fee. In <>
+inputs minus the anticipated transaction fee. In <>,
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.
==== Coin Selection
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
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
would contain a copy of the transaction output from Joe's transaction,
which was created in exchange for cash (see <>).
-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
-_Unspent Transaction Outputs_ (UTXOs).
+_unspent transaction outputs_ (UTXOs).
However, because full nodes use more resources, many
user wallets run lightweight clients that track only the user's own
UTXOs.
@@ -358,7 +349,7 @@ UTXOs.
In this case, this single
UTXO is sufficient to pay for the podcast. Had this not been the case,
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
to get some change back, which we will see in the next section, as the
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
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
podcast. Alice's change
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
fashion, Alice's wallet application will add a small fee. The fee is not
explicitly stated in the transaction; it is implied by the difference in value between
-inputs and outputs. This _transaction fee_ is collected by the
+inputs and outputs. This transaction fee is collected by the
miner as a fee for including the transaction in a block
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
a small change to their candidate block and tries again. As of this
writing, the number of candidate blocks miners need to try before finding
-a winning combination is about 168 billion trillions. That's also how
+a winning combination is about 168 billion trillion. That's also how
many times the hash function needs to be run.
However, once a winning combination has been found, anyone can verify
@@ -628,8 +619,8 @@ look like <>.
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
-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
+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
the miners who recorded it on the blockchain. In the rest of this book,
we will examine the specific technologies behind wallets, addresses,
signatures, transactions, the network, and finally, mining.
diff --git a/ch03_bitcoin-core.adoc b/ch03_bitcoin-core.adoc
index 3c45f7bc..2676ffc7 100644
--- a/ch03_bitcoin-core.adoc
+++ b/ch03_bitcoin-core.adoc
@@ -36,8 +36,8 @@ full time and several dozen more on a part-time basis. Anyone can
contribute to the code—including you!
When Bitcoin was created by Satoshi Nakamoto, the
-software was mostly completed before publication of the whitepaper reproduced in
-<>. Satoshi wanted to make sure the
+software was mostly completed before publication of the whitepaper (reproduced in
+<>). Satoshi wanted to make sure the
implementation worked before publishing a paper about it. That first implementation, then simply
known as "Bitcoin," has been heavily modified and
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
archive of the source code. Alternatively, use the Git command line to create a
local copy of the source code from the
-https://oreil.ly/BdOwl[GitHub bitcoin page].
+https://oreil.ly/BdOwl[GitHub Bitcoin page].
[TIP]
====
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
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
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
command immediately following it, then press Enter to execute the
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
the linked libraries are not broken in obvious ways. The final step is
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:
----
@@ -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
blockchain data. By default this is the _.bitcoin_ subdirectory of your
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.
-++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
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
@@ -500,7 +500,7 @@ the minimum amount of space mentioned in the +datadir+ option.
programmatically retrieve any transaction by its ID provided that the
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
often, or reduce the size on low-end hardware to save memory at the
expense of using your disk more frequently.
@@ -527,7 +527,7 @@ indexing, you need to
wait for it to rebuild the index.
****
-<> shows how you might combine the preceding options,
+<> shows how you might combine the preceding options
with a fully indexed node, running as an API backend for a bitcoin
application.
@@ -582,7 +582,7 @@ $ bitcoind -printtoconsole
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 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 Using wallet directory /lotsofspace/bitcoin/wallets
2023-01-28T03:43:39Z init message: Verifying wallet(s)…
@@ -681,8 +681,8 @@ Result:
Examples:
> bitcoin-cli getblockhash 1000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest",
-"method": "getblockhash",
-"params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+ "method": "getblockhash",
+ "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
@@ -774,7 +774,7 @@ on how many blocks your ((("Bitcoin Core", "command-line interface", "status inf
In <>, 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.
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's serialized transaction
@@ -882,7 +882,7 @@ Bob and the change back to Alice.
We can further explore the blockchain by examining the previous
transaction referenced by its +txid+ in this transaction using the same
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.
==== Exploring Blocks
@@ -928,7 +928,7 @@ f6cd83c3ca
"difficulty": 157416.4018436489,
"chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
"nTx": 13,
- "previousblockhash": "[...]000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
+ "previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
"nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
"strippedsize": 4179,
"size": 4179,
@@ -968,8 +968,7 @@ we'll examine those ((("Bitcoin Core", "command-line interface", "exploring bloc
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
-and testing functions. But the whole point of an application programming
-interface is to access functions programmatically. In this section we
+and testing functions. But the whole point of an API is to access functions programmatically. In this section we
will demonstrate accessing Bitcoin Core from another program.
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",
-"method": "getblockchaininfo",
-"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+ "method": "getblockchaininfo",
+ "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
@@ -1006,13 +1005,13 @@ any higher-level Bitcoin Core RPC wrappers), ((("Bitcoin Core", "authentication"
====
----
$ cat .bitcoin/.cookie
-__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
+ __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
$ curl
---user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
---data-binary '{"jsonrpc": "1.0", "id":"curltest",
-"method": "getblockchaininfo",
-"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
+ --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
+ --data-binary '{"jsonrpc": "1.0", "id":"curltest",
+ "method": "getblockchaininfo",
+ "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
{"result":{"chain":"main","blocks":799278,"headers":799278,
"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879",
@@ -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
==== 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
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#
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.
If you followed the instructions in this chapter, you now have Bitcoin
diff --git a/ch04_keys.adoc b/ch04_keys.adoc
index 4d36bdab..9c8aca4c 100644
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
those goals, shown in <>. A receiver like Bob
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
-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
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.
@@ -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
used to create signatures that are used to spend bitcoins by proving
control of funds used in a transaction. The private key must remain
-secret at all times, because revealing it to third parties is equivalent
+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
-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
+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
forever lost too.
[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 -
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 <>). To create such a key, we randomly pick a
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,
@@ -150,7 +150,7 @@ bits):
[TIP]
====
-The size of Bitcoin's private key space, (2^256^) is an unfathomably
+The size of Bitcoin's private key space (2^256^) is an unfathomably
large number. It is approximately 10^77^ in decimal. For comparison, the
visible universe is estimated to((("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
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~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
public key. The reverse operation, known as "finding the discrete
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
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
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
-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
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
-_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_:
[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
256 bits (32 bytes) of output, less than half the size of original
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
Nakamoto never stated, the original version of Bitcoin made commitments
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.
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
was backward compatible with all Bitcoin full nodes at the time,
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
-byte keys are known as _uncompressed public keys_. Using smaller public keys
+public keys are known as _compressed public keys_, and the original 65-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
block.
As we saw in the section <>, a public key is a point (x,y) on an
elliptic curve. Because the curve expresses a mathematical function, a
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
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
@@ -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
graph of the elliptic curve in <>, the curve is symmetric,
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
-negative); or in other words, we have to remember if it was above or
+omit the _y_ coordinate, we have to store the _sign_ of _y_ (positive 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
point and a different public key. When calculating the elliptic curve in
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
from the uncompressed public key. More importantly, if we convert this
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
-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
(compressed and uncompressed) that produce two different Bitcoin
addresses. However, the private key is identical for both Bitcoin
@@ -835,7 +834,7 @@ addresses.
image::images/mbc3_0408.png["pubkey_compression"]
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.
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
exported from a wallet, the WIF that is used to
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.
[[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
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
root. For HASH160, the probability becomes 1-in-2^80^. This is a
_collision attack_.
@@ -985,9 +984,9 @@ processes involving multiple parties, which could make the attack
profitable.
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
-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
resistance. To perform 2^128^ hash operations would take all current
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
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
- 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
versions of some letters can look similar in many people's
handwriting.
@@ -1173,20 +1172,20 @@ time in a billion.
//https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb
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
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
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
bech32 addresses and are the current recommended address format for
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
need to know about the HRPs already chosen, shown in
<>.
@@ -1284,19 +1283,19 @@ scripts are listed in <>.
P2WPKH |
-OP_0 2b626ed108ad00a944bb2922a309844611d25468 |
+OP_0 2b626ed108ad00a944bb2922a309844611d25468
|
P2WSH |
-OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f |
+OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f
|
P2TR |
-OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311 |
+OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311
|
Future Example |
-OP_16 0000 |
+OP_16 0000
|
@@ -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 was hashed again with RIPEMD-160, but that may not be secure in
some cases; for details, see <>. 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).
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
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:
----
$ 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
>>> from segwit_addr import *
@@ -1385,7 +1384,8 @@ decode(hrp, addr)
>>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee")
>>> _[0], bytes(_[1]).hex()
(0, '2b626ed108ad00a944bb2922a309844611d25468')
->>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
+>>> _ = decode("bc",
+ "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
>>> _[0], bytes(_[1]).hex()
(1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
----
@@ -1523,7 +1523,7 @@ can easily be converted to any other((("private keys", "formats", startref="priv
==== 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
-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
added one-byte suffix (shown as 01 in hex in <>), which
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
is modified, with the addition of a one-byte suffix +01+ to the private
key. The resulting base58check-encoded private key is called a
-"compressed WIF" and starts with the letter _K_ or _L_, instead of
-starting with "5" as is the case with WIF-encoded (uncompressed) keys
+"compressed WIF" and starts with the letter _K_ or _L_ instead of
+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.
=== Advanced Keys and Addresses
@@ -1613,7 +1613,7 @@ addresses that contain human-readable messages. For example,
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
the letters forming the word "Love" as the first four base58 letters.
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
algorithm, the process essentially involves picking a private key at
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
factor of 58. Patterns with more than seven characters are usually found
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
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
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
-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
address, in the form of detachable stubs similar to ticket stubs,
allowing you to store multiple copies to protect against fire, flood, or
diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc
index 5e6d61c0..5e8cc653 100644
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@@ -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
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:
----
@@ -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
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
-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
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
@@ -179,7 +179,7 @@ transactions to the less-secure frontend for broadcast to the Bitcoin
network.
Public child key derivation can produce a linear sequence of keys
-similar to the previously seen <>, but modern wallets
+similar to the previously seen <>, but modern wallet
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.
@@ -278,7 +278,7 @@ BIP39::
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
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.
Electrum v2::
@@ -299,7 +299,7 @@ Aezeed::
cryptographic properties of the recovery code.
It also includes a _wallet birthday_
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
blockchain, which is especially useful for privacy-focused lightweight clients.
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
Aezeed recovery codes, it provides support for new technologies and
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::
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
label data. That seems obvious, but there are a number of
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.
Additionally, it may be useful for wallet applications to provide a
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.
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
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
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
@@ -611,7 +611,7 @@ included directly. Their disadvantage is that they require users to back
up additional information along with their recovery code. The
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
-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
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
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
-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:
- BIP39 recovery codes
-- BIP32 hierarchical deterministic (HD) key derivation
+- BIP32 HD key derivation
- 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.
However, if you're feeling bold, we do encourage you to investigate more
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
sequences that represent (encode) a random number used as a seed to
derive a deterministic wallet. The sequence of words is sufficient to
-re-create the seed and from there re-create all the
+re-create the seed and from there, re-create all the
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
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
brainwallet consists of words chosen by the user, whereas recovery codes
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.
====
@@ -902,7 +902,7 @@ some examples of recovery codes and the seeds ((("key-stretching functions", sta
-Table 5-7. 256-bit entropy BIP39 recovery code, no passphrase, resulting seed
+256-bit entropy BIP39 recovery code, no passphrase, resulting seed
Entropy input (256 bits) |
@@ -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
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
-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
very safe or use a method like SLIP39 that lets you distribute your
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
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
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
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
-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
subsequent child chain codes are derived from each parent chain code.
@@ -1089,7 +1089,7 @@ parent.
image::images/mbc3_0507.png["ChildPrivateDerivation"]
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
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).
@@ -1177,9 +1177,9 @@ LrtJunSDMstweyLXhRgPxdp14sk9tJPW9
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
-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
-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.
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
deployments where a server or application has a copy of an extended
public key and no private keys whatsoever. That kind of deployment can
-produce an infinite number of public keys and Bitcoin addresses, but
+produce an infinite number of public keys and Bitcoin addresses but
cannot spend any of the money sent to those addresses. Meanwhile, on
another, more secure server, the extended private key can derive all the
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
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
-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.
===== 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
an infinite number of generations. With all that flexibility, however,
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
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
identifying the structure and namespace of the rest of the tree by
defining its purpose. For example, an HD wallet using only branch
-m/i++'++/ is intended to signify a specific purpose and that
+m/i++'++/ is intended to signify a specific purpose, and that
purpose is identified by index number "i."
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
multicurrency HD wallets where each currency has its own subtree under
the second level. Bitcoin is
-m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++.
+m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++.
The third level of the tree is "account," which allows users to
-subdivide their wallets into separate logical subaccounts, for
+subdivide their wallets into separate logical subaccounts for
accounting or organizational purposes. For example, an HD wallet might
contain two Bitcoin "accounts": m/44++'++/0++'++/0++'++
and m/44++'++/0++'++/1++'++. Each account is the root of
diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc
index 790fee0a..5bfa05f4 100644
--- a/ch06_transactions.adoc
+++ b/ch06_transactions.adoc
@@ -54,7 +54,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
Bitcoin Core's serialization format is special because it's the format
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
same data. However, Bitcoin Core's format is reasonably compact for the
data it transmits and simple to parse, so many other Bitcoin programs
@@ -62,12 +62,12 @@ use this format.
[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
documented in BIPs 174 and 370 (with extensions documented in other
BIPs). PSBT allows an untrusted program to produce a transaction
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
allows storing a significant amount of metadata about a transaction,
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.
Bitcoin Core's default transaction relay policy does not allow the use
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.
****
@@ -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
consensus rules but only the policy that Bitcoin full nodes use to relay
transactions. Under the proposal, version 3 transactions would be
-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 <>.
+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 <>.
=== 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
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]]
@@ -347,7 +347,7 @@ txid from the outpoint in our example transaction:
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:
----
@@ -371,7 +371,7 @@ This odd behavior is probably an unintentional consequence of a
https://oreil.ly/01JH2[design
decision in early Bitcoin software]. As a practical matter, it means
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
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
transaction with a different version an unlimited number of
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
per minute at 200 bytes each would use about 20 kilobytes of their
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
for the transaction to be valid. A disable flag allows a transaction to
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.
A type-flag
@@ -573,7 +573,7 @@ as defined by BIP68.
.BIP68 definition of sequence encoding (Source: BIP68)
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
<>.
@@ -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
values can be uneconomical as well, even unintentionally. For example,
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.
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
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
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
++OP_TRUE++. Anyone can create that input script, which means anyone
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
script language often take an existing anyone-can-spend script and add
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
language and is retained in modern Bitcoin Core to support
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.
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,
if the important problem was _x + 2 == 4_ and someone claimed they
witnessed the solution, what would we ask them? We'd want a
-mathematical proof that showed a value which could be summed with two to
+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
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
@@ -757,7 +757,7 @@ protected by the following script:
Obviously, allowing your bitcoins to be spent by anyone who can solve a
simple equation wouldn't be secure. As we'll see in <>, an
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
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_.
@@ -797,7 +797,7 @@ transactions out of order:
- 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
- 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_.
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
third-party malleability, users of contract protocols faced another problem:
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
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
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).
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
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
transactions to mine. Bitcoin's earliest known soft fork added a rule
that, starting at block height 31,000, forbid the inclusion of a
diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc
index 6d66d0d9..074170ed 100644
--- a/ch07_authorization-authentication.adoc
+++ b/ch07_authorization-authentication.adoc
@@ -7,7 +7,7 @@ nodes will distinguish the authorized spenders from everyone else,
called _authentication_. Your authorization instructions and the
spender proof of authentication will be checked by thousands of
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.
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]
====
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
of conditions to be expressed.
====
@@ -75,7 +75,7 @@ validation mechanism from being used as a vulnerability.
==== Stateless Verification
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
information needed to execute a script is contained within the script
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
input and output scripts are then executed together. The input is
valid if the input script satisfies the output script's conditions
-(see <>). All the inputs are validated independently, as
+(see <>). All the inputs are validated independently as
part of the overall validation of the transaction.
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
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
-or +FALSE+ (represented by zero) if they are not equal. Bitcoin
-transaction scripts usually contain a conditional operator, so that they
+or +FALSE+ (represented by 0) if they are not equal. Bitcoin
+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.
===== A simple script
@@ -363,7 +363,7 @@ the input script has
two valid signatures from private keys that correspond to two of
the three public keys set as an encumbrance.
-At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 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
3-of-3 multisignature or any combination within that range.
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
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
-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.
-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
stack error and script failure (marking the transaction as invalid).
-Because the dummy element is disregarded it can be anything, but
-it became the custom early on to use +OP_0+, which later became a
+Because the dummy element is disregarded, it can be anything. 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).
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+
signature-checking operations. It's possible that Bitcoin's original
developer added the extra element (which we now call the dummy stack
-element) in the original version of Bitcoin so that they could add the
+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,
-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
future.
@@ -552,10 +551,10 @@ with P2SH.
++++
-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
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
in fees and complexity from the spender to the receiver of the
transaction.
@@ -572,7 +571,7 @@ incoming payments from customers:
----
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
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
as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+.
-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
+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
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,
but otherwise it works in exactly the same way as a payment to any other Bitcoin
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.
==== Benefits of P2SH
@@ -657,7 +656,7 @@ scripts in outputs:
==== 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
possible to include +OP_RETURN+ (see <>) in a redeem script, as
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
it. The spending transaction, which includes the redeem script,
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]
====
@@ -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
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
-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
referenced as an input in a transaction, the script validation engine
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.
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 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
specification in BIP65, a new script operator called
_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
-+OP_CLTV+ is a per-output timelock, rather than a per-transaction timelock
++OP_CLTV+ is a per-output timelock rather than a per-transaction timelock,
as is the case with lock time. This allows for additional
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:
----
- OP_CHECKSIGVERIFY OP_CHECKLOCKTIMEVERIFYG
+ OP_CHECKSIGVERIFY OP_CHECKLOCKTIMEVERIFY
----
where ++ 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.
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
operation_ or +OP_NOP+ opcode was executed). Otherwise, script
execution halts and the transaction is deemed invalid.
@@ -911,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
Relative timelocks are
implemented according to the specifications in
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,
+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
-(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
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 <> and <>.
@@ -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
conditional clauses. You are probably familiar with flow control in
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.
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
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.
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+
@@ -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
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
-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+
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+,
@@ -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
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
wishes to construct a company capital account with flexible rules. The
scheme he creates requires different levels of authorization depending
@@ -1239,7 +1238,7 @@ OP_0 OP_FALSE OP_TRUE
[TIP]
====
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.
====
@@ -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
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
any knowledge of segwit.
Bob's wallet can then spend this payment with a segwit transaction,
taking advantage of segwit and reducing transaction fees.
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.
===== 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
authorization condition is a member of the merkle tree without
disclosing any details about the other members of the merkle tree. See
-<>, and note that the nodes with diagonal corners can be
+<>, and note that the shaded nodes can be
computed from other data provided by the user, so they don't need to be
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"]
The hash digests used to create the commitments are each 32 bytes, so
-proving a spend of <> is authorized (using a merkle tree and the
+proving that a spend of <> is authorized (using a merkle tree and the
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.
@@ -1692,7 +1691,7 @@ discovered, which we'll see in <>.
.MAST Versus MAST
****
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]]
@@ -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
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
<>, but it would require revealing at least one 32-byte digest for
every separate part of the program, which would not be very space
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
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
@@ -1737,22 +1736,22 @@ also serve another use.
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
-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
+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
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
-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
number (tweak).
Later, Bob can prove to anyone what he paid Alice by revealing her
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,
then she received the payment. If Alice spent the funds, this further
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).
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
multisignatures disclose data about how many keys and signatures are
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
multisignature and every single-signature, no privacy-reducing data is
leaked.
diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc
index 204d4ac0..1131f273 100644
--- a/ch08_signatures.adoc
+++ b/ch08_signatures.adoc
@@ -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,
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
transaction, thereby committing to all the inputs, outputs, and other
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
private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
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
three signed inputs may have three signatures with different +SIGHASH+
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
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
-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
reach the value of the output, the transaction is invalid. Each donation
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.
+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
Bitcoin address into the output script.
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
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+).
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
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
-would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
++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)+.
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_
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
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).
They're serialized in the order of +kG+ and then +s+, producing exactly
64 bytes.
@@ -621,9 +620,9 @@ simple multisignature protocol:
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
-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
-different keys.
+different keys).
The preceding protocol has several security problems. Most notable is that one
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
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
-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
_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
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
-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
-that message before she begins working with Bob. Other solutions,
+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
+that message before she begins working with Bob). Other solutions,
possibly more robust solutions, to this problem were being researched at
the time of writing.
@@ -841,7 +840,7 @@ Less provable security::
Nonlinear::
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
problem, but they involve additional extra complexity that
significantly slows down operations and which, in some cases, has
@@ -923,7 +922,7 @@ as follows:
=== 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 <> and <>,
-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
important, _as long as it is random_. If signatures from the same
private key use the private nonce _k_ with different messages
diff --git a/ch09_fees.adoc b/ch09_fees.adoc
index 9c952bd0..80e62b48 100644
--- a/ch09_fees.adoc
+++ b/ch09_fees.adoc
@@ -17,7 +17,7 @@ blockchain to a sufficient depth before he considers the money he
received as his to spend (see <>).
For Alice's transaction to be included in the
blockchain, it must be included in a _block_ of transactions. There are
-a limited number of((("blocks", "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
that block gets to choose which transactions to include. Miners may
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
problem; we'll look at a solution to that problem in <>. However,
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.
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
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
Core would not replace the first version of an unconfirmed transaction
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
transaction, so they provided their goods or services shortly after
receiving such an unconfirmed transaction.
@@ -292,7 +292,7 @@ having "Sending support" on
https://oreil.ly/IhMzx.
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
full RBF becomes reliable, there will likely be several years where
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
the fee rate of the entire package before operating on any individual
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
published.
@@ -594,10 +594,10 @@ Fees = Sum(Inputs) – Sum(Outputs)
----
This is a somewhat confusing element of transactions and an important
-point to understand, because if you are constructing your own
-transactions you must ensure you do not inadvertently include a very
+point to understand because if you are constructing your own
+transactions, you must ensure you do not inadvertently include a very
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!
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
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
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"
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,
transaction fees will be the majority of the reward (or even the
entirety of the reward). At that time, this scenario becomes inevitable.
@@ -649,15 +649,15 @@ no effect—the transactions could only be included in block
#100,001 anyway; it's the next block.
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
with whatever transactions were valid at that time, essentially gaining
no new fees.
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
-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.
As Bitcoin continues to mature, and as the subsidy continues to decline,
diff --git a/ch10_network.adoc b/ch10_network.adoc
index 163e61f7..b4ded298 100644
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@@ -222,7 +222,7 @@ receive it. For example:
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
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.
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
developer Matt Corallo in 2015 to enable fast synchronization 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
miners and mining pools.
@@ -268,7 +268,7 @@ information, including:
+Version+:: The Bitcoin P2P protocol version the client "speaks" (e.g., 70002)
+nLocalServices+:: A list of local services supported by the node
+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
+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
@@ -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
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.
-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
introductions. It's also unnecessary and wasteful of network resources
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
-is rebooted it can quickly reestablish connections with its former peer
+will remember its most recent successful peer connections so if it
+is rebooted, it can quickly reestablish connections with its former peer
network. If none of the former peers respond to its connection request,
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
IP addresses, users can provide the option +-connect=+ and
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.
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
connection for too long, it is assumed to be disconnected
and a new peer will be sought. Thus, the network dynamically adjusts to
-transient nodes and network problems, and can organically grow and
+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.
=== 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.
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
(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
@@ -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
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
-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
need to randomly connect means that lightweight clients also are vulnerable to
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
filters offer an efficient way to express a search pattern while
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.
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
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
-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
more possible addresses and better privacy, but many of the results are
irrelevant. If they ask for a very specific pattern, they get fewer
@@ -662,7 +662,7 @@ changed from +0+ to +1+.
<> is an example of adding a pattern "A" to the simple bloom filter shown in <>.
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
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
@@ -726,16 +726,16 @@ transactions of interest to the lightweight client without revealing exactly whi
addresses or keys it is interested in.
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
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
-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.
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
incoming transaction. The full node checks several parts of the
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
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
-clients use more bandwidth for the block download), and the filters can
-only be used for confirmed transactions (not unconfirmed transactions),
-but it is much more private and reliable than BIP37 client-requested
+clients to use more bandwidth for the block download), and the filters can
+only be used for confirmed transactions (not unconfirmed transactions). However,
+it is much more private and reliable than BIP37 client-requested
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
-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
uses less space for small numbers and extra space for large numbers.
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
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
-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
-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:
* 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).
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
checks whether any of its generated commitments match the commitments in
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
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
client is looking for (in this example), ((("false positives")))called a _false positive_.
@@ -1141,7 +1141,7 @@ communications: _Tor transport_.
Tor, which
stands for _The Onion Routing network_, is a software project and
network that offers encryption and encapsulation of data through
-randomized network paths that offer anonymity, untraceability and
+randomized network paths that offer anonymity, untraceability, and
privacy.
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,
completing the chain that started with the parent transaction. In light
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
of a parent transaction triggers a cascade reconstruction of an entire
chain of interdependent transactions by reuniting the orphans with
diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc
index 65be39b5..1da43f46 100644
--- a/ch11_blockchain.adoc
+++ b/ch11_blockchain.adoc
@@ -10,7 +10,7 @@ full nodes (and sometimes light clients) to validate.
The blockchain data structure is
an ordered, back-linked list of blocks of transactions. The blockchain
-can be stored as a flat file, or in a simple database.
+can be stored as a flat file or in a simple database.
Blocks are linked "back," each referring to the previous block in the
chain. The blockchain is often visualized
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.
Multiple children arise during a blockchain "fork," a temporary
situation that can occur when different blocks are discovered almost
-simultaneously by different miners (see <>). Eventually, only one
-child block becomes part of the blockchain accepted by all full nodes and the "fork" is resolved.
+simultaneously by different miners (see <>). Eventually only one
+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
affects the _current_ block's hash.
@@ -396,7 +396,7 @@ HA = SHA256(SHA256(Transaction A))
++++
-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
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
@@ -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
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
trees in <>:
[[cve_tree]]
-[role="figuresmallerninety"]
.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"]
@@ -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
hashes, constituting ((("authentication path")))((("merkle path")))an _authentication path_ or _merkle path_
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
slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or
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
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
-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
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
@@ -643,7 +642,7 @@ used to test segregated witness features.
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
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
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
"Regression Testing," is a Bitcoin Core feature that allows you to
create a local blockchain for testing purposes. Unlike signet and testnet3, which
-are a public and shared test blockchain, the regtest blockchains are
+are public and shared test blockchains, the regtest blockchains are
intended to be run as closed systems for local testing. You launch a
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.
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
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):
----
@@ -820,10 +819,10 @@ $ bitcoin-cli -regtest getbalance
Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test blockchains", "development usage")))various
blockchains (regtest, signet, testnet3, mainnet) offer a range
of testing environments for bitcoin development. Use the test
-blockchains whether you are developing for Bitcoin Core, or another
-full-node consensus client; an application such as a wallet, exchange,
+blockchains whether you are developing for Bitcoin Core or another
+full-node consensus client (an application such as a wallet, exchange,
ecommerce site; or even developing novel smart contracts and complex
-scripts.
+scripts).
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
@@ -837,6 +836,6 @@ into production.
Now that we know what data the blockchain contains and how cryptographic
commitments securely tie the various parts together, we will look at the
-special commitment that both provides computational security and
-ensures no block can be changed without invalidating all other blocks
+special commitment that both provide computational security and
+ensure no block can be changed without invalidating all other blocks
built on top of it: Bitcoin's mining function.
diff --git a/ch12_mining.adoc b/ch12_mining.adoc
index 7ab81043..3e0e5e89 100644
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@@ -74,7 +74,7 @@ will have been issued. After 2140, no new bitcoin
will be issued.
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
"keep the change" on the transactions included in the winning block.
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
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
-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
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
node has a complete copy of a public blockchain that it can trust as the
authoritative record. The blockchain is not created by a central
-authority, but is assembled independently by every node in the network.
+authority but is assembled independently by every node in the network.
Somehow, every node in the network, acting on information transmitted
across insecure network connections, can arrive at the same conclusion
and assemble a copy of the same blockchain as everyone else. This
@@ -221,7 +221,7 @@ chapter examines the process by which the Bitcoin network achieves
global consensus without central authority.
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
occurs. Instead, consensus is an emergent artifact of the asynchronous
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
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
into a chain
- 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
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.
@@ -440,7 +440,7 @@ fees (+nFees+), and the sum is returned.
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
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.
====
@@ -524,7 +524,7 @@ structure of the((("inputs", "coinbase versus regular transactions"))) coinbase
Variable |
Coinbase Data |
-Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height |
+Arbitrary data used for extra nonce and mining tags; in v2 blocks, must begin with block height |
4 bytes |
@@ -554,7 +554,7 @@ be used by miners in any way they want; it is arbitrary data.
In the genesis block, for
example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
Chancellor on brink of second bailout for banks" in the coinbase data,
-using it as a proof of the earliest date this block chould have been
+using it as a proof of the earliest date this block could have been
created and to convey a message. Currently,
miners often use the coinbase data to include extra nonce values and strings
identifying the mining pool.
@@ -604,12 +604,12 @@ as listed in <>.
4 bytes |
Target |
-The Proof-of-Work algorithm target for this block |
+The proof-of-work algorithm target for this block |
4 bytes |
Nonce |
-A counter used for the Proof-of-Work algorithm |
+A counter used for the proof-of-work algorithm |
@@ -662,11 +662,11 @@ transactions into a single 32-byte value, which is the _witness root
hash_.
The witness root hash is added to an output of the coinbase transaction.
-This step may be skipped 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
the coinbase transaction) is then listed using its transaction
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
"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
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
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
@@ -696,7 +696,7 @@ the header before a version is found that satisfies the((("bitcoins", "mining",
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
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
various aspects of the Bitcoin system. The hash function SHA256 is the
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:
+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
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
+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
finding a hash that is less than the target becomes more and more
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
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
-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
_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]
====
@@ -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.
====
-In <>, the winning "nonce" is 32 and
+In <>, the winning "nonce" is 32, and
this result can be confirmed by anyone independently. Anyone can add the
number 32 as a suffix to the phrase "Hello, world!" and compute
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
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
verify. Furthermore, by knowing the target, anyone can estimate the
difficulty using statistics and therefore know roughly how much work was needed
@@ -819,13 +819,13 @@ to find such a nonce.
[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
the target. A lower target means it is more difficult to find a hash
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 <>. The miner constructs a
candidate block filled with transactions. Next, the miner calculates the
hash of this block's header and sees if it is smaller than the current
@@ -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
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
the exponent and the next six hex digits as the coefficient. In this
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
-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
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
@@ -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
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?
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
computers they use will also constantly change. To keep the block
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
block interval goal. In simple terms, the target is set so that the
current mining power will result in a 10-minute block interval.
How, then, is such an adjustment made in a completely decentralized
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
minutes per block is calculated and a
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%.
<> shows the code used in the Bitcoin Core client.
[[retarget_code]]
-.Retargeting the Proof-of-Work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
+.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.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
electricity into hashing computation at the highest rate possible. The
primary influence on the mining market is the price of one kilowatt-hour
-of electricity in bitcoin, because that determines the profitability of
+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
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
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
-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.
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
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
- Proof-of-Work)
+ proof of work).
- 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
- checklist discussed in <>
+ checklist discussed in <>.
The independent validation of each new block by every node on the
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.
The miners have to construct a block, based on the shared rules
that all nodes follow, and mine it with a correct solution to the
-Proof-of-Work. To do so, they expend a lot of electricity in mining, and
+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
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
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
-the most cumulative Proof-of-Work associated with it.
+the most cumulative PoW associated with it.
The
best chain may also have branches with blocks that are "siblings" to
the blocks on the best chain. These blocks are valid but not part of the
-best chain. They are kept for future reference, in case one of those
+best chain. They are kept for future reference in case one of those
secondary chains later becomes primary. When sibling blocks occur,
they're usually the result of an
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.
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's Law"))) Moore's Law, which
stipulates that computing density will double approximately every 18
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
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
-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
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
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
-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
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
mining pool measure the individual contributions, so as to fairly
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
pool miners win a share frequently enough to make it worthwhile to
contribute to the pool. By setting a lower difficulty for earning
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
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
paid the block reward to the pool. Each pool miner is given a
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,
we looked at a transaction between Alice and Bob. Bob, the seller, is
willing to accept payment without waiting for
-confirmation (mining in a block), because the risk of a double-spend on
+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
customer service. This is similar to the practice of coffee shops that
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
transaction, replacing Mallory's payment to Carol with a transaction
that double-spends the same input as Mallory's payment. The double-spend
-transaction consumes the same UTXO and pays it back to Mallory's wallet,
+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
bitcoins. Paul then directs the mining pool to mine an additional block,
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
also has no payment. Throughout all this activity, Paul's mining
pool participants might remain blissfully unaware of the double-spend
-attempt, because they mine with automated miners and cannot monitor
+attempt because they mine with automated miners and cannot monitor
every transaction or block.
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
smaller percentage of the hashing power. The 51% threshold is simply the
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
-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
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
@@ -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
network without the possibility of profiting from such disruption. A
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 attacker could attack Bitcoin by simultaneously
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
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
independently. Hard forks occur when part of the network is operating
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
is now unable to process block 7b. From their perspective,
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
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
@@ -1810,7 +1810,7 @@ that do not have near-unanimous support are considered too contentious
to attempt without risking a partition of the system.
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
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
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
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
@@ -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
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
readiness for BIP34 by constructing blocks with "2" as the version
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
activated or rejected, the signaling bit can be reused for another
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.
[NOTE]
@@ -2014,7 +2014,7 @@ number.
bit:: 0 through 28, the bit in the block version that miners use to
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
for the proposal.
@@ -2030,7 +2030,7 @@ later.
BIP9 offers a proposal state diagram to illustrate the various stages
and transitions for a proposal, as shown in <>.
-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
time, the proposal state transitions to +STARTED+. If the voting
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
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
-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
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
@@ -2136,7 +2136,7 @@ future attempt to activate a ((("consensus rules", "soft forks", "speedy trial a
=== 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.
By its very nature, Bitcoin sets a very high bar on coordination and
consensus for changes. As a decentralized system, it has no "authority"
diff --git a/ch13_security.adoc b/ch13_security.adoc
index 8ebfe9f2..b8b10ad8 100644
--- a/ch13_security.adoc
+++ b/ch13_security.adoc
@@ -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.
Thus, the payment network has to be secured end-to-end with encryption
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
_and_ payment tokens that can be used to create new transactions. Worse,
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,
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
discipline to implement a robust security model, such a design merely
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
number of different locations and under the control of different people.
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
also offer redundancy, where a single person holds several keys that are
stored in different locations.
diff --git a/ch14_applications.adoc b/ch14_applications.adoc
index 2f982849..74703926 100644
--- a/ch14_applications.adoc
+++ b/ch14_applications.adoc
@@ -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
data becomes practically immutable. Immutability is underwritten by energy, as
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
block containing a transaction.
@@ -65,9 +65,9 @@ without invalidating the signature, thus invalidating the transaction
itself.
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
-transaction is either mined, or not.
+transaction is either mined or not.
Discrete (Indivisible) Units of Value:: Transaction outputs are discrete
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
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.
-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.
=== 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,
proving that a piece of data existed at the time
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
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
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
over the coins in order to further spend them.
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
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
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.
@@ -341,7 +341,7 @@ Translated forwarding::
Native forwarding is conceptually simpler but essentially requires a
separate Lightning Network for every asset. Translated forwarding
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
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
@@ -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_ 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
blockchain, are held offchain instead, waiting for
eventual batch settlement. Because the transactions are not settled,
@@ -370,15 +370,15 @@ extremely high transaction throughput, low latency, and
fine granularity.
Actually, the term _channel_ is a metaphor. State channels are virtual
-constructs represented by the exchange of state between two parties,
-outside of the blockchain. There are no "channels" per se and the
+constructs represented by the exchange of state between two parties
+outside of the blockchain. There are no "channels" per se, and the
underlying data transport mechanism is not the channel. We use the term
-channel to represent the relationship and shared state between two
-parties, outside of the blockchain.
+_channel_ to represent the relationship and shared state between two
+parties outside of the blockchain.
To further explain this
concept, think of a TCP stream. From the perspective of higher-level
-protocols it is a "socket" connecting two applications across the
+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
virtual channel over IP packets. Each endpoint of the TCP stream
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—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
-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_.
This single transaction must be transmitted to
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
transactions. In between these two states, the two parties can exchange
any number of commitment transactions that are never seen by anyone
-else, nor submitted to the blockchain.
+else or submitted to the blockchain.
<> 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.
@@ -453,7 +453,7 @@ To
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
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
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
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
video, creating and signing 600 commitment transactions. The last
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
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
channel fails because Emma can cheat by broadcasting a prior
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
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
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
-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
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
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
lock time, neither party can successfully propagate any of the
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
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
the channel is first opened, they limit the lifetime of the channel.
Worse, they force channel implementations to strike a balance between
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,
-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
+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,
the other party must wait 30 days for a refund. The more distant the
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
settlement transaction knowing there is no way to cheat and get a more
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
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.
==== 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.
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
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
@@ -850,8 +850,8 @@ ENDIF
CHECKSIG
----
-Irene can confidently sign this transaction, since if transmitted it
-will immediately pay her what she is owed. Hitesh holds the transaction,
+Irene can confidently sign this transaction since if transmitted, it
+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
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,
exchange revocation secrets for the previous commitments, and sign each
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.
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
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
redeem it. Crucially, before signing new commitment transactions, they
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. However, for Irene, state number 1 leaves her with a higher
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
state because with the revocation key, Hitesh can redeem both outputs of
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
extended with a special type of smart contract that allows the
participants to commit funds to a redeemable secret, with an expiration
-time. This feature is called a _Hash Time Lock Contract_, or _HTLC_, and
+time. This feature is called a _hash time lock contract_, or _HTLC_, and
is used in both bidirectional and routed payment channels.
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
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
-number of blocks the payer can claim a refund using the second clause in
+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
the +IF+ flow.
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
transaction, which must be committed to the Bitcoin blockchain. Alice
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?
<> shows the step-by-step process of routing a
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
what channels they have open, how much capacity each channel has, and
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.
Current implementations of
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.
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.
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.
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
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,
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
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 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.
- Each part of the path is encrypted in such a way that a network-level
diff --git a/copyright.html b/copyright.html
index af25fa6b..39dc6ec9 100644
--- a/copyright.html
+++ b/copyright.html
@@ -3,7 +3,7 @@
by Andreas M. Antonopoulos and David A. Harding
-Copyright © 2023 David Harding. All rights reserved.
+Copyright © 2024 David Harding. All rights reserved.
Printed in the United States of America.
@@ -16,8 +16,8 @@
Development Editor: Angela Rufino
Production Editor: Clare Laylock
Copyeditor: Kim Cofer
- Proofreader:
- Indexer:
+ Proofreader: Heather Walley
+ Indexer: nSight, Inc.
Interior Designer: David Futato
Cover Designer: Randy Comer
Illustrator: Kate Dullea
diff --git a/meta/github_contrib.adoc b/meta/github_contrib.adoc
index 6449cf32..6bb33810 100644
--- a/meta/github_contrib.adoc
+++ b/meta/github_contrib.adoc
@@ -142,7 +142,7 @@
ratijas
rating89us
Raul Siles (raulsiles)
-Reproducibility Matters (TheCharlatan)
+Reproducibility Matters (TheCharlatan)
Reuben Thomas (rrthomas)
Robert Furse (Rfurse)
Roberto Mannai (robermann)
diff --git a/meta/third_edition_changes.asciidoc b/meta/third_edition_changes.asciidoc
index 21421b5f..3cbf773a 100644
--- a/meta/third_edition_changes.asciidoc
+++ b/meta/third_edition_changes.asciidoc
@@ -12,7 +12,7 @@ development in 2023 have been added.
Old Chapters 6 and 7::
Text from previous versions of Chapter 6, "Transactions," and Chapter 7,
"Advanced Transactions," has been rearranged and expanded across four
- new chapters: pass:[#c_transactions] (the structure of txes), pass:[#c_authorization_authentication] , pass:[#c_signatures], and
+ new chapters: pass:[#c_transactions] (the structure of txes), pass:[#c_authorization_authentication], pass:[#c_signatures], and
pass:[#tx_fees].
<>::
diff --git a/preface.asciidoc b/preface.asciidoc
index d140761b..8acf575d 100644
--- a/preface.asciidoc
+++ b/preface.asciidoc
@@ -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.
-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.
@@ -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.
-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]
====
-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
@@ -126,25 +126,25 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
=== Contacting the Authors
You can contact Andreas M. Antonopoulos on his personal site:
-link:$$https://antonopoulos.com/$$[]
+[.keep-together]#link:$$https://antonopoulos.com$$[].#
Follow Andreas on Facebook:
-link:$$https://facebook.com/AndreasMAntonopoulos$$[]
+link:$$https://facebook.com/AndreasMAntonopoulos$$[].
Follow Andreas on Twitter:
-link:$$https://twitter.com/aantonop$$[]
+link:$$https://twitter.com/aantonop$$[].
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:
-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:
-link:$$https://bitcoinbook.info/$$[]
+Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on:
+link:$$https://bitcoinbook.info$$[].
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
@@ -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.
-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.
-The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
+The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
During the development of the book, I made early drafts available on GitHub and invited public comments. More than a hundred comments, suggestions, corrections, and contributions were submitted in response. Those contributions are explicitly acknowledged, with my thanks, in <>. Most of all, my sincere thanks to my volunteer GitHub editors Ming T. Nguyen (1st edition) and Will Binns (2nd edition), who worked tirelessly to curate, manage, and resolve pull requests, issue reports, and perform bug fixes on GitHub.