>), but it will still download the
+blocks, but it will still download the
entire dataset.
====
@@ -423,6 +423,7 @@ If you're reading this book and interested in strong security, superior
privacy, or developing Bitcoin software, you should be running your ((("Bitcoin Core", "nodes", "running", startref="bitcoin-core-nodes-running")))((("nodes", "running", startref="nodes-running")))((("running nodes", startref="running-nodes")))own
node.
+[[bitcoincorenode_config]]
=== Configuring the Bitcoin Core Node
Bitcoin Core will((("Bitcoin Core", "nodes", "configuring", id="bitcoin-core-nodes-configure")))((("nodes", "configuring", id="nodes-configure")))((("configuring", "nodes", id="configure-nodes"))) look for a
@@ -813,11 +814,11 @@ returned by +getrawtransaction+ and paste it as a parameter to
++++
-$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0↵
-0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512↵
-03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000↵
-00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f↵
-4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6↵
+$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0\
+0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512\
+03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000\
+00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f\
+4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6\
dab0d2fa2b42a45182fc83e817130100000000
++++
@@ -909,7 +910,7 @@ the parameter:
++++
-$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f↵
+$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f\
f6cd83c3ca
++++
@@ -973,10 +974,9 @@ The
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
-Object Notation, and it is a very convenient way to present data that
-both humans and programs can easily read. RPC stands for Remote
-Procedure Call, which means that we are calling procedures (functions)
+Bitcoin Core's API is a JSON-RPC interface. JSON is a very convenient way to present data that
+both humans and programs can easily read. RPC stands for remote
+procedure call, which means that we are calling procedures (functions)
that are remote (on the Bitcoin Core node) via a network protocol. In
this case, the network protocol is HTTP.
@@ -1168,7 +1168,7 @@ and more are created all the time.
If you followed the instructions in this chapter, you now have Bitcoin
Core running and have begun exploring the network and blockchain using
your own full node. From now on you can independently use software you
-control, on a computer you control, to verify any bitcoins you receive
+control—on a computer you control—to verify that any bitcoins you receive
follow every rule in the Bitcoin system without having to trust any
outside authority. In the coming chapters, we'll learn more about the
rules of the system and how your node and your wallet use them to secure
diff --git a/ch04_keys.adoc b/ch04_keys.adoc
index 7dd312d7..5ded89ad 100644
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@@ -384,7 +384,7 @@ geometric operation on the curve.
[TIP]
====
Many Bitcoin implementations use
-the https://oreil.ly/wD60m[libsecp256k1 crytographic
+the https://oreil.ly/wD60m[libsecp256k1 cryptographic
library] to do the elliptic curve((("public keys", "generating", startref="public-key-generate")))((("elliptic curve multiplication", startref="elliptic-multiply"))) math.
====
@@ -620,7 +620,7 @@ output, causing them to be lost forever. In the next section, we'll
look at compact encoding and reliable ((("public key cryptography", "hash functions and", startref="pub-key-hash")))((("hash functions", "Bitcoin payments and", startref="hash-payment")))((("payments", "with hash functions", secondary-sortas="hash functions", startref="payment-hash")))((("P2PKH (pay to public key hash)", startref="p2pkh-legacy")))((("addresses", "P2PKH (pay to public key hash)", startref="address-p2pkh-legacy")))((("commitments", startref="commitment")))checksums.
[[base58]]
-=== Base58Check Encoding
+=== Base58check Encoding
In order((("public key cryptography", "base58check encoding", id="pub-key-base58")))((("base58check encoding", id="base58-ch4")))((("encoding", "base58check", id="encode-base58"))) to represent long numbers in a compact way,
using fewer symbols, many computer systems use mixed-alphanumeric
@@ -690,7 +690,7 @@ encoding process.
[[base58check_encoding]]
.Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data.
-image::images/mbc3_0406.png["Base58CheckEncoding"]
+image::images/mbc3_0406.png["Base58checkEncoding"]
++++
@@ -786,7 +786,7 @@ coordinate and reducing the size of the key and the space required to
store it by 256 bits. An almost 50% reduction in size in every
transaction adds up to a lot of data saved over time!
-Here's the public key generated by the private key we created in
+Here is the public key generated by the private key we created in
<>:
----
@@ -800,8 +800,8 @@ y+:
++++
-K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A↵
-07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
+K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A\
+ 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
++++
@@ -1082,7 +1082,7 @@ The "32" stands for the number of characters in the bech32 alphabet
- Bech32 uses only numbers and a single case of letters (preferably
rendered in lowercase). Despite its alphabet being almost half the
- size of the base58check alphabet, a bech32 address for a P2WPKH script
+ size of the base58check alphabet, a bech32 address for a pay to witness public key hash (P2WPKH) script
is only slightly longer than a legacy address for an equivalent P2PKH
script.
@@ -1331,7 +1331,7 @@ function. The resultant 32-byte digest is then passed into a RIPEMD-160
hash function. The digest of that function (the commitment) is placed
in the witness program.
-For the P2WSH output, we don't use the P2SH algorithm. Instead we take
+For the pay to witness script hash (P2WSH) output, we don't use the P2SH algorithm. Instead we take
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
@@ -1408,7 +1408,7 @@ decode(hrp, addr)
>>> _[0], bytes(_[1]).hex()
(0, '2b626ed108ad00a944bb2922a309844611d25468')
>>> _ = decode("bc",
- "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
+ "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
>>> _[0], bytes(_[1]).hex()
(1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
----
diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc
index ca594f74..ac172254 100644
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@@ -508,7 +508,7 @@ and automatically create complete backups of their wallet database
encrypted by one of the keys derived from their seed. Bitcoin keys must
be unguessable and modern encryption algorithms are considered very
secure, so nobody should be able to open the encrypted backup except
-someone who can generate the seed, making it safe to store the backup on
+someone who can generate the seed. This makes it safe to store the backup on
untrusted computers such as cloud hosting services or even random
network peers.
@@ -807,7 +807,7 @@ data and the length of recovery code in((("wallets", "recovery codes", "generati
The ((("wallets", "recovery codes", "seed generation", id="wallet-recovery-bip39-seed")))((("recovery codes", "seed generation", id="recovery-code-bip39-seed")))((("BIP39 recovery codes", "seed generation", primary-sortas="BIP039", id="bip39-recovery-seed")))((("entropy", "seed generation", id="entropy-seed-generate")))((("seeds", "generating", id="seed-generate")))((("key-stretching functions", id="key-stretch")))recovery code
represents entropy with a length of 128 to 256 bits. The entropy is then
used to derive a longer (512-bit) seed through the use of the
-key-stretching function PBKDF2. The seed produced is then used to build
+https://oreil.ly/6lwbd[key-stretching function PBKDF2]. The seed produced is then used to build
a deterministic wallet and derive its keys.
The key-stretching function takes two
@@ -1061,14 +1061,14 @@ wallet is shown in <>.
image::images/mbc3_0506.png["HDWalletFromRootSeed"]
The root seed is input into the HMAC-SHA512 algorithm and the resulting
-hash is used to create a _master private key_ (m) and a _master chain
-code_ (c).
+hash is used to create a _master private key_ (_m_) and a _master chain
+code_ (_c_).
-The master private key (m) then generates a corresponding master public
-key (M) using the normal elliptic curve multiplication process m × _G_
+The master private key (_m_) then generates a corresponding master public
+key (_M_) using the normal elliptic curve multiplication process _m_ × _G_
that we saw in <>.
-The chain code (c) is used to introduce entropy in the function that
+The master chain code (_c_) is used to introduce entropy in the function that
creates child keys from parent keys, as we will see in the next section.
===== Private child key derivation
@@ -1385,8 +1385,8 @@ The index number ((("index numbers for hardened derivation")))used in the deriva
easily distinguish between keys created through the normal derivation
function versus keys derived through hardened derivation, this index
number is split into two ranges. Index numbers between 0 and
-2^31^–1 (0x0 to 0x7FFFFFFF) are used _only_ for normal
-derivation. Index numbers between 2^31^ and 2^32^–1 (0x80000000
+2^31^ – 1 (0x0 to 0x7FFFFFFF) are used _only_ for normal
+derivation. Index numbers between 2^31^ and 2^32^ – 1 (0x80000000
to 0xFFFFFFFF) are used _only_ for hardened derivation. Therefore, if
the index number is less than 2^31^, the child is normal, whereas if the
index number is equal or above 2^31^, the child is hardened.
diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc
index 1daf9fb4..5b601f84 100644
--- a/ch07_authorization-authentication.adoc
+++ b/ch07_authorization-authentication.adoc
@@ -193,7 +193,7 @@ The validation software combines the scripts:
2 3 OP_ADD 5 OP_EQUAL
----
-As we saw in <>, when
+As we see in <>, when
this script is executed, the result is +OP_TRUE+, making the transaction
valid. Not only have we shown a valid transaction output script, but
the resulting UTXO could be spent by anyone with the arithmetic skills
@@ -242,7 +242,7 @@ a vulnerability known as the +1 OP_RETURN+ bug. In the current
implementation, the scripts are executed separately with the stack
transferred between the two executions.
-First, the input script executed using the stack execution
+First, the input script is executed using the stack execution
engine. If the input script is executed without errors and has
no operations left over, the stack is copied and the
output script is executed. If the result of executing the output script
@@ -376,7 +376,7 @@ scripts wrapped in another structure like P2SH, P2WSH, or P2TR.
P2SH multisignature scripts are limited by both policy and consensus to
15 keys, allowing for up to a 15-of-15 multisignature. We will learn about
P2SH in <>. All other scripts are consensus limited to 20 keys
-per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
+per +OP_CHECKMULTISIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
script may include multiple of those opcodes.
[role="less_space pagebreak-before"]
@@ -417,7 +417,7 @@ replicated forever. Therefore a script should look
like this:
----
-OP_0 2 3 OP_CHECKMULTISIG
+OP_0 2 3 OP_CHECKMULTISIG
----
Thus the input script actually used in multisig is not:
@@ -780,7 +780,7 @@ It is important to understand the limitations of transaction lock time. The only
In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv")))((("timelocks", "verifying", id="timelock-op-cltv")))((("lock time", "verifying", id="lock-time-op-cltv")))((("OP_CLTV script operator", id="op-cltv")))((("verifying", "lock time", id="verify-lock-time")))((("scripts", "timelocks", "verifying", id="script-timelock-verify")))December 2015, a new form of
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_CHECKLOCKTIMEVERIFY+ (+OP_CLTV+) was added to the scripting language.
+OP_CLTV+ is a per-output timelock rather than a per-transaction timelock,
as is the case with lock time. This allows for additional
flexibility in the way timelocks are applied.
@@ -1184,7 +1184,7 @@ account directly after he gains access to the capital account's
transaction records.
<> is the redeem script that Mohammed designs to achieve this (line
-number prefixed as XX).
+number have been prefixed).
[[variable_timelock_multisig]]
.Variable multi-signature with timelock
@@ -1467,7 +1467,7 @@ backward-compatible upgrade, where _old and new clients can coexist_.
Wallet developers independently upgraded wallet software to add
segwit capabilities.
Legacy P2PKH and
-P2SH continue to work for nonupgraded wallets. That leaves two
+P2SH continue to work for [.keep-together]#nonupgraded# wallets. That leaves two
important scenarios, which are addressed in the next section:
- Ability of a spender's wallet that is not segwit-aware to make a
@@ -1962,7 +1962,7 @@ called _tapscript_. The major differences include:
[role="less_space pagebreak-before"]
Scripted multisignature changes::
- The old +OP_CHECKMULTSIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
+ The old +OP_CHECKMULTISIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
removed. Those opcodes don't combine well with one of the other
changes in the taproot soft fork, the ability to use schnorr signatures
with batch validation (see <>). A new +OP_CHECKSIGADD+ opcode is provided
diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc
index 3ba40ba9..7a248f1c 100644
--- a/ch08_signatures.adoc
+++ b/ch08_signatures.adoc
@@ -416,7 +416,7 @@ The nonce (k)::
In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't
know and can't guess and gives him the scaled form of that number,
_kG_. At that point, Bob also already has her public key (_xG_),
- which is the scaled form of _x_), her private key. That means when Bob is working on
+ which is the scaled form of _x_, her private key. That means when Bob is working on
the final equation (_sG_ = _kG_ + _exG_), there are two independent
variables that Bob doesn't know (_x_ and _k_). It's possible to use
simple algebra to solve an equation with one unknown variable but not
@@ -520,10 +520,10 @@ full commitment _hash_(_kG_ || _xG_ || _m_).
Now that we've described each part of the BIP340 schnorr signature
algorithm and explained what it does for us, we can define the protocol.
Multiplication of integers are performed _modulus p_, indicating that the
-result of the operation divided by the number _p_ (as defined in the
+result of the operation is divided by the number _p_ (as defined in the
secp256k1 standard) and the remainder is used. The number _p_ is very
large, but if it was 3 and the result of an operation was 5, the actual
-number we would use is 2 (i.e., 5 divided by 3 is 2).
+number we would use is 2 (i.e., 5 divided by 3 has a remainder of 2).
Setup: Alice chooses a large random number (_x_) as her private key
(either directly or by using a protocol like BIP32 to deterministically
@@ -620,10 +620,10 @@ simple multisignature protocol:
3. Alice produces the scalar _q_ = _a_ + _ey_. Bob produces the scalar
_r_ = _b_ + _ez_. They add the scalars together to produce
- _s_ = _q_ + _r_. Their signature is the two values _kG_ and _s_.
+ _s_ = _q_ + _r_. Their signature is the two values _kG_ [.keep-together]#and _s_.#
4. The verifiers check their public key and signature using the normal
- equation: _sG_ == _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
+ equation: [.keep-together]#_sG_ ==# _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
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
diff --git a/ch09_fees.adoc b/ch09_fees.adoc
index 5195c1c9..9f3417f5 100644
--- a/ch09_fees.adoc
+++ b/ch09_fees.adoc
@@ -6,11 +6,11 @@
The digital signature we saw Alice create in #c_signatures only
proves that she knows her private key and that she committed to a
transaction that pays Bob. She can create another signature that
-instead commits to a transaction paying Carol--a transaction that spends
+instead commits to a transaction paying Carol—a transaction that spends
the same output (bitcoins) that she used to pay Bob. Those two
transactions are now conflicting transactions because only one
transaction spending a particular output can be included in the valid
-blockchain with the most proof of work--the blockchain that full nodes
+blockchain with the most proof of work—the blockchain that full nodes
use to determine which keys control which bitcoins.
++++
@@ -39,7 +39,7 @@ previous transaction and is also an exception to several other rules
that apply to other transactions. Coinbase transactions don't pay
transaction fees, don't need to be fee bumped, aren't subject to
transaction pinning, and are largely uninteresting to the following
-discussion about fees--so we're going to ignore them in this chapter.
+discussion about fees—so we're going to ignore them in this chapter.
++++
@@ -133,7 +133,7 @@ fee rates.
Be careful ((("absurd fees")))((("excessive fees")))((("transaction fees", "overpaying")))((("overpaying transaction fees")))accepting input for fee rates. If a user copies and pastes a
fee rate printed in one denominator into a field using a different
denominator, they could overpay fees by 1,000 times. If they instead
-switch the denominator, they could theoretically overpay by 100,000,000
+switch the numerator, they could theoretically overpay by 100,000,000
times. Wallets should make it hard for the user to pay an excessive
fee rate and may want to prompt the user to confirm any fee rate that was
not generated by the wallet itself using a trusted data source.
@@ -639,7 +639,7 @@ you intended.
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"
higher-fee transactions from future blocks to maximize their
-profitability.
+[.keep-together]#profitability.#
For example, let's say the highest block in existence is block
#100,000. If instead of attempting to mine block #100,001 to extend the
diff --git a/ch10_network.adoc b/ch10_network.adoc
index b3ee0e6c..c55da3b9 100644
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@@ -523,7 +523,7 @@ both tourists can verify the existence of a street by visiting it, the
tourist without a map doesn't know what lies down any of the side
streets and doesn't know what other streets exist. Positioned in front
of 23 Church Street, the tourist without a map cannot know if there are
-a dozen other "23 Church Street" addresses in the city and whether this
+a dozen other [.keep-together]#"23 Church# Street" addresses in the city and whether this
is the right one. The mapless tourist's best chance is to ask enough
people and hope some of them are not trying to mug him.
@@ -720,7 +720,7 @@ pattern is definitely((("Bitcoin network", "bloom filters", "operational overvie
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
image::images/mbc3_1010.png[]
-=== How Lightweight Clients Use Bloom Filters
+==== How Lightweight Clients Use Bloom Filters
Bloom filters ((("Bitcoin network", "bloom filters", "lightweight clients and", id="bitcoin-network-bloom-lightweight")))((("bloom filters", "lightweight clients and", id="bloom-lightweight")))((("lightweight clients", "bloom filters and", id="lightweight-bloom")))are used to filter the transactions (and blocks containing
them) that a lightweight client receives from its peers, selecting only
@@ -1170,8 +1170,6 @@ As a way to increase the privacy and security of the Bitcoin P2P
network, there is a solution that provides encryption of the
communications: _Tor transport_.
-==== Tor Transport
-
Tor, which
stands for _The Onion Routing network_, is a software project and
network that offers encryption and encapsulation of data through
diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc
index a5a04dca..33dc2e1c 100644
--- a/ch11_blockchain.adoc
+++ b/ch11_blockchain.adoc
@@ -6,7 +6,7 @@ It's what allows every full node to independently determine what keys and
scripts control which bitcoins. In this chapter, we'll look at the
structure of the blockchain and see how it uses cryptographic
commitments and other clever tricks to make every part of it easy for
-full nodes (and sometimes light clients) to validate.
+full nodes (and sometimes lightweight clients) to validate.
The blockchain data structure is
an ordered, back-linked list of blocks of transactions. The blockchain
@@ -382,7 +382,7 @@ Bitcoin's merkle trees is SHA256 applied twice, also known as
double-SHA256.
When N data elements are hashed and summarized in a merkle tree, you can
-check to see if any one data element is included in the tree with at
+check to see if any one data element is included in the tree with
about +log~2~(N)+ calculations, making this a very efficient data
structure.
@@ -812,7 +812,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 a reward for the first 400 blocks (coinbase
+you will see that you earned the rewards 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):
----
@@ -826,7 +826,7 @@ Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test bl
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,
+full-node consensus client; an application such as a wallet, exchange,
ecommerce site; or even developing novel smart contracts and complex
scripts).
diff --git a/ch12_mining.adoc b/ch12_mining.adoc
index dc881fd6..3ac395ca 100644
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@@ -167,8 +167,7 @@ The most ((("deflation", id="deflation")))((("inflation", id="inflation")))impor
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.
+(and exchange rate) of a currency. Price deflation is the opposite of inflation; it 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
@@ -947,7 +946,7 @@ New Target = Old Target * (20,160 minutes / Actual Time of Last 2015 Blocks)
[NOTE]
====
While the target calibration happens every 2,016 blocks, because of an
-off-by-one error in the original Bitcoin software it is based on the
+off-by-one error in the original Bitcoin software, it is based on the
total time of the previous 2,015 blocks (not 2,016 as it should be),
resulting in a retargeting bias toward higher difficulty by 0.05%.
====
@@ -1397,8 +1396,7 @@ eight-or-less wasn't winning, it was a fair way to measure dice throws
for the players, and it occasionally produces a less-than-four throw.
Similarly, a mining pool will set a (higher and easier) pool target that
-will ensure that an individual pool miner can find block header hashes
-that are less than the pool target often, earning shares. Every now and
+will ensure that an individual pool miner frequently earns shares by finding block header hashes that are less than the pool target. Every now and
then, one of these attempts will produce a block header hash that is
less than the Bitcoin network target, making it a valid block and the
whole pool wins.
@@ -2015,7 +2013,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. After +TIMEOUT+, the bits can be "recycled" to propose
new changes.
[NOTE]
diff --git a/ch14_applications.adoc b/ch14_applications.adoc
index 79a1e9b3..ca34bcff 100644
--- a/ch14_applications.adoc
+++ b/ch14_applications.adoc
@@ -145,7 +145,7 @@ intrinsic to the blockchain.
Colored coins are used to track digital
assets as well as physical assets held by third parties and traded
-through colored coins certificates of ownership. Digital asset colored
+through certificates of ownership associated with colored coins. Digital asset colored
coins can represent intangible assets such as a stock certificate,
license, virtual property (game items), or most any form of licensed
intellectual property (trademarks, copyrights, etc.). Tangible asset
@@ -340,7 +340,7 @@ Translated forwarding::
support forwarding bitcoin [.keep-together]#payments.#
Native forwarding is conceptually simpler but essentially requires a
-separate LN for every asset. Translated forwarding
+separate Lightning-type network for every asset. Translated forwarding
allows building on the economies of scale of the Bitcoin LN, 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
@@ -1038,7 +1038,7 @@ efficient route.
Alice's node then constructs an HTLC, payable to the hash +H+, with a
10-block refund timeout (current block + 10), for an amount of 1.003
-bitcoins (see <> step 2). The extra 0.003 will be
+bitcoins (see <>, step 2). The extra 0.003 will be
used to compensate the intermediate nodes for their participation in
this payment route. Alice offers this HTLC to Bob, deducting 1.003
bitcoins from her channel balance with Bob and committing it to the HTLC.
@@ -1068,7 +1068,7 @@ Carol now has a commitment that if she gets +R+ within the next nine
blocks, she can claim 1.002 bitcoins locked by Bob. Now she can make an
HTLC commitment on her channel with Diana. She commits an HTLC of 1.001
bitcoins to hash +H+, for eight blocks, which Diana can redeem if she has
-secret +R+ (see <> step 4). From Carol's
+secret +R+ (see <>, step 4). From Carol's
perspective, if this works she is 0.001 bitcoins better off and if it
doesn't she loses nothing. Her HTLC to Diana is only viable if +R+ is
revealed, at which point she can claim the HTLC from Bob. The channel
@@ -1076,27 +1076,27 @@ balance between Carol and Diana is now: 2 to Diana, 0.999 to Carol,
1.001 committed by Carol to the HTLC.
Finally, Diana can offer an HTLC to Eric, committing 1 bitcoin for seven
-blocks to hash +H+ (see <> step 5). The channel
+blocks to hash +H+ (see <>, step 5). The channel
balance between Diana and Eric is now: 2 to Eric, 1 to Diana, 1
committed by Diana to the HTLC.
However, at this hop in the route, Eric _has_ secret +R+. He can
therefore claim the HTLC offered by Diana. He sends +R+ to Diana and
claims the 1 bitcoin, adding it to his channel balance (see
-<> step 6). The channel balance is now: 1 to Diana,
+<>, step 6). The channel balance is now: 1 to Diana,
3 to Eric.
Now, Diana has secret +R+. Therefore, she can now claim the HTLC from
Carol. Diana transmits +R+ to Carol and adds the 1.001 bitcoins to her
-channel balance (see <> step 7). Now the channel
+channel balance (see <>, step 7). Now the channel
balance between Carol and Diana is: 0.999 to Carol, 3.001 to Diana.
Diana has "earned" 0.001 for participating in this payment route.
Flowing back through the route, the secret +R+ allows each participant
to claim the outstanding HTLCs. Carol claims 1.002 from Bob, setting the
balance on their channel to: 0.998 to Bob, 3.002 to Carol (see
-<> step 8). Finally, Bob claims the HTLC from Alice
-(see <> step 9). Their channel balance is updated
+<>, step 8). Finally, Bob claims the HTLC from Alice
+(see <>, step 9). Their channel balance is updated
as: 0.997 to Alice, 3.003 to Bob.
Alice has paid Eric 1 bitcoin without opening a channel to Eric. None of
diff --git a/colo.html b/colo.html
index 29d1344b..c6e679ca 100644
--- a/colo.html
+++ b/colo.html
@@ -10,5 +10,5 @@
Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.
-The cover image is from Insects Abroad. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.
+The cover illustration is by Karen Montgomery, based on an image from Insects Abroad. The cover fonts are Gilroy Semibold and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.
diff --git a/meta/third_edition_changes.asciidoc b/meta/third_edition_changes.asciidoc
index 3cbf773a..92f33dde 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 transactions), pass:[#c_authorization_authentication], pass:[#c_signatures], and
pass:[#tx_fees].
<>::
diff --git a/preface.asciidoc b/preface.asciidoc
index ad28609b..101c99f0 100644
--- a/preface.asciidoc
+++ b/preface.asciidoc
@@ -169,7 +169,7 @@ During the development of the book, I made early drafts available on GitHub and
Once the book was drafted, it went through several rounds of technical review. Thanks to Cricket Liu and Lorne Lantz for their thorough review, comments, and support.
-Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing the Bitcore appendix; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
+Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing information about Bitcore; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
I owe my love of words and books to my mother, Theresa, who raised me in a house with books lining every wall. My mother also bought me my first computer in 1982, despite being a self-described technophobe. My father, Menelaos, a civil engineer who just published his first book at 80 years old, was the one who taught me logical and analytical thinking and a love of science and engineering.