diff --git a/ch02_overview.adoc b/ch02_overview.adoc index 5a266091..20805414 100644 --- a/ch02_overview.adoc +++ b/ch02_overview.adoc @@ -470,7 +470,7 @@ electricity to solve a computational problem. A successful miner will collect ((("rewards")))a _reward_ in the form of new bitcoins and transaction fees. However, the reward will only be collected if the miner has only included valid transactions, with the Bitcoin protocol's rules for -_consensus_ dermining what is valid. This delicate balance provides +_consensus_ determining what is valid. This delicate balance provides security for Bitcoin without a central authority. Mining is designed to be a decentralized lottery. Each miner can create @@ -480,7 +480,7 @@ The miner inputs their candidate into a specially designed algorithm that scrambles((("hash functions"))) (or "hashes") the data, producing output that looks nothing like the input data. This _hash_ function will always produce the same output for the same input--but nobody can predict what the output will -look like for a new input, even if it is only slighly different from a +look like for a new input, even if it is only slightly different from a previous input. If the output of the hash function matches a template determined by the Bitcoin protocol, the miner wins the lottery and Bitcoin users will accept the block with its transactions as a diff --git a/ch04_keys.adoc b/ch04_keys.adoc index ba62940f..1a5423d3 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -1085,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet .Bech32 typo detection ==== Address: - bc1p9nh05ha8wrljf7ru236awpass:[n]4t2x0d5ctkkywmpass:[v]9sclnm4t0av2vgs4k3au7 + bc1p9nh05ha8wrljf7ru236awpass:[n]4t2x0d5ctkkywmpass:[v]9sclnm4t0av2vgs4k3au7 Detected errors shown in bold and underlined. Generated using the https://oreil.ly/paWIx[bech32 address decoder demo]. diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index 9f8c7318..843f3aab 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -643,7 +643,7 @@ A few example descriptors are shown in <>.

sh(multi(2,022f…​2a01,03ac…​ccbe))

-

P2SH multisignature requring two signatures corresponding to these two keys

+

P2SH multisignature requiring two signatures corresponding to these two keys

pkh([d34db33f/44'/0'/0']xpub6ERA…​RcEL/1/*)

diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index d2ec2c49..62d6cb40 100644 --- a/ch08_signatures.adoc +++ b/ch08_signatures.adoc @@ -436,12 +436,12 @@ Bob waits to receive Alice's public nonce the equation that Bob will use for verification, _sG_ == _kG_ + _exG_; specifically, they can change both _sG_ and _kG_. Think about a simplified form of that expression: _x_ = _y_ + _a_. If you can change both - _x_ and _y_, you can cancel out _a_ using _x_++'++ = (_x_ - _a_) + _a_. Any + _x_ and _y_, you can cancel out _a_ using _x_++'++ = (_x_ – _a_) + _a_. Any value you choose for _x_ will now satisfy the equation. For the actual equation the impersonator simply chooses a random number for _s_, generates _sG_, and then uses EC subtraction to select a _kG_ that equals _kG_ = - _sG_ - _exG_. They give Bob their calculated _kG_ and later their random - _sG_, and Bob thinks that's valid because _sG_ == (_sG_ - _exG_) + _exG_. + _sG_ – _exG_. They give Bob their calculated _kG_ and later their random + _sG_, and Bob thinks that's valid because _sG_ == (_sG_ – _exG_) + _exG_. This explains why the order of operations in the protocol is essential: Bob must only give Alice the challenge scalar after Alice has committed to her public nonce. @@ -482,7 +482,7 @@ and hashes it herself. We no longer need interaction from Bob. She can simply publish her public nonce _kG_ and the scalar _s_, and each of the thousands of full nodes (past and future) can hash _kG_ to produce _e_, use that to produce _exG_, and then verify _sG_ == _kG_ + _exG_. Written -explicitly, the verification equation becomes _sG_ == _kG_ + hash(_kG_) × _xG_. +explicitly, the verification equation becomes _sG_ == _kG_ + _hash_(_kG_) × _xG_. We need one other thing to finish converting the interactive schnorr identity protocol into a digital signature protocol useful for @@ -491,8 +491,8 @@ key; we also want to give her the ability to commit to a message. Specifically, we want her to commit to the data related to the Bitcoin transaction she wants to send. With the Fiat-Shamir transform in place, we already have a commitment, so we can simply have it additionally commit to the -message. Instead of hash(_kG_), we now also commit to the message -_m_ using hash(_kG_ || _m_), where || stands for concatenation. +message. Instead of _hash_(_kG_), we now also commit to the message +_m_ using _hash_(_kG_ || _m_), where || stands for concatenation. We've now defined a version of the schnorr signature protocol, but there's one more thing we need to do to address a Bitcoin-specific @@ -508,7 +508,7 @@ also support several protocols people wanted to build on top of schnorr signatures, Bitcoin's version of schnorr signatures, called _BIP340 schnorr signatures for secp256k1_, also commits to the public key being used in addition to the public nonce and the message. That makes the -full commitment hash(_kG_ || _xG_ || _m_). +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. @@ -531,7 +531,7 @@ she's ready to spend, she begins generating her signature: nonce _kG_. 2. She chooses her message _m_ (e.g., transaction data) and generates the - challenge scalar _e_ = hash(_kG_ || _xG_ || _m_). + challenge scalar _e_ = _hash_(_kG_ || _xG_ || _m_). 3. She produces the scalar _s_ = _k_ + _ex_. The two values _kG_ and _s_ are her signature. She gives this signature to everyone who wants to @@ -541,7 +541,7 @@ she's ready to spend, she begins generating her signature: transaction to full nodes. 4. The verifiers (e.g., full nodes) use _s_ to derive _sG_ and then - verify that _sG_ == _kG_ + hash(_kG_ || _xG_ || _m_) × _xG_. If the equation is + verify that _sG_ == _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_. If the equation is valid, Alice proved that she knows her private key _x_ (without revealing it) and committed to the message _m_ (containing the transaction data). @@ -609,14 +609,14 @@ simple multisignature protocol: public nonce _kG_ = _aG_ + _bG_. 2. They agree on the message to sign, _m_ (e.g., a transaction), and - each generates a copy of the challenge scalar: _e_ = hash(_kG_ || _xG_ || _m_). + each generates a copy of the challenge scalar: _e_ = _hash_(_kG_ || _xG_ || _m_). 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_. 4. The verifiers check their public key and signature using the normal - equation: _sG_ == _kG_ + hash(_kG_ || _xG_ || _m_) × _xG_. + equation: _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 @@ -628,7 +628,7 @@ The preceding protocol has several security problems. Most notable is that one party might learn the public keys of the other parties before committing 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 +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 valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc index 1918c677..1ff38a7c 100644 --- a/ch11_blockchain.adoc +++ b/ch11_blockchain.adoc @@ -350,7 +350,6 @@ chain, making the blockchain longer with a new height of 277,315. references in((("blockchain", "linking blocks", startref="blockchain-link")))((("blocks", "linking in blockchain", startref="block-link")))((("linking blocks in blockchain", startref="link-block"))) the +previousblockhash+ field. [[chain_of_blocks]] -[role="smallerfourtyfive"] .Blocks linked in a chain by each referencing the previous block header hash image::images/mbc3_1101.png[] diff --git a/ch12_mining.adoc b/ch12_mining.adoc index f107b2e8..d8a59747 100644 --- a/ch12_mining.adoc +++ b/ch12_mining.adoc @@ -289,7 +289,7 @@ criteria: - For each input, if the referenced output transaction is a coinbase output, it must have at least +COINBASE_MATURITY+ (100) confirmations. - Any absolute or relative lock time must also be satisified. Nodes may + Any absolute or relative lock time must also be satisfied. Nodes may relay transactions a block before they mature since they will be mature if included in the next block. @@ -630,7 +630,7 @@ nonce field. [TIP] ==== The protocol upgrades defined in BIPs 34, 66, and 65 occurred in that -order, with BIP66 (strict DER) occuring before BIP65 +order, with BIP66 (strict DER) occurring before BIP65 (+OP_CHECKTIMELOCKVERIFY+), so Bitcoin developers often list them in that order rather than sorted numerically. ==== @@ -866,7 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get: ++++ ++++ @@ -941,7 +941,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] ---- diff --git a/ch14_applications.adoc b/ch14_applications.adoc index 31168ba9..673a36e4 100644 --- a/ch14_applications.adoc +++ b/ch14_applications.adoc @@ -500,7 +500,7 @@ paid to the multisignature 2-of-2 address controlled jointly between Emma and Fabian. It may have additional outputs for change back to Emma's wallet. -After the funding transaction is confirmed to a sufficent depth, Emma can start streaming +After the funding transaction is confirmed to a sufficient depth, Emma can start streaming video. Emma's software creates and signs a commitment transaction that changes the channel balance to credit 0.01 millibit to Fabian's address and refund 35.99 millibits back to Emma. The transaction signed by Emma