arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-22 16:18:11 +00:00
Code Issues Releases Wiki Activity

spellcheck

Browse Source
This commit is contained in:
Clare Laylock 2023-10-25 14:59:03 -04:00
parent 78ec958c82
commit 5e54b3ecf1
7 changed files with 21 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ch02_overview.adoc
View File

@ -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. 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 However, the reward will only be collected if the miner has only
included valid transactions, with the Bitcoin protocol's rules for 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. security for Bitcoin without a central authority.
Mining is designed to be a decentralized lottery. Each miner can create 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 scrambles((("hash functions"))) (or "hashes") the data, producing output that looks nothing
like the input data. This _hash_ function will always produce the same 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 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 previous input. If the output of the hash function matches a template
determined by the Bitcoin protocol, the miner wins the lottery and determined by the Bitcoin protocol, the miner wins the lottery and
Bitcoin users will accept the block with its transactions as a Bitcoin users will accept the block with its transactions as a

2
ch04_keys.adoc
View File

@ -1085,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet
.Bech32 typo detection .Bech32 typo detection
==== ====
Address: Address:
bc1p9nh05ha8wrljf7ru236awpass:[<u><em>n</em></u>]4t2x0d5ctkkywmpass:[<u><em>v</em></u>]9sclnm4t0av2vgs4k3au7 bc1p9nh05ha8wrljf7ru236awpass:[<u><strong>n</strong></u>]4t2x0d5ctkkywmpass:[<u><strong>v</strong></u>]9sclnm4t0av2vgs4k3au7
Detected errors shown in bold and underlined. Generated using the Detected errors shown in bold and underlined. Generated using the
https://oreil.ly/paWIx[bech32 address decoder demo]. https://oreil.ly/paWIx[bech32 address decoder demo].

2
ch05_wallets.adoc
View File

@ -643,7 +643,7 @@ A few example descriptors are shown in <<sample_descriptors>>.
</tr> </tr>
<tr> <tr>
<td><p><code>sh(multi(2,022f…​2a01,03ac…​ccbe))</code></p></td> <td><p><code>sh(multi(2,022f…​2a01,03ac…​ccbe))</code></p></td>
<td><p>P2SH multisignature requring two signatures corresponding to these two keys</p></td> <td><p>P2SH multisignature requiring two signatures corresponding to these two keys</p></td>
</tr> </tr>
<tr> <tr>
<td><p><code>pkh([d34db33f/44'/0'/0']xpub6ERA…​RcEL/1/*)</code></p></td> <td><p><code>pkh([d34db33f/44'/0'/0']xpub6ERA…​RcEL/1/*)</code></p></td>

24
ch08_signatures.adoc
View File

@ -436,12 +436,12 @@ Bob waits to receive Alice's public nonce
the equation that Bob will use for verification, _sG_ == _kG_ + _exG_; the equation that Bob will use for verification, _sG_ == _kG_ + _exG_;
specifically, they can change both _sG_ and _kG_. Think about a specifically, they can change both _sG_ and _kG_. Think about a
simplified form of that expression: _x_ = _y_ + _a_. If you can change both 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 value you choose for _x_ will now satisfy the equation. For the
actual equation the impersonator simply chooses a random number for _s_, generates 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_, 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_ – _exG_. They give Bob their calculated _kG_ and later their random
_sG_, and Bob thinks that's valid because _sG_ == (_sG_ - _exG_) + _exG_. _sG_, and Bob thinks that's valid because _sG_ == (_sG_ – _exG_) + _exG_.
This explains why the order of operations in the protocol is This explains why the order of operations in the protocol is
essential: Bob must only give Alice the challenge scalar after Alice essential: Bob must only give Alice the challenge scalar after Alice
has committed to her public nonce. 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 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_, 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 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 We need one other thing to finish converting the interactive schnorr
identity protocol into a digital signature protocol useful for 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 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 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 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 message. Instead of _hash_(_kG_), we now also commit to the message
_m_ using hash(_kG_ || _m_), where || stands for concatenation. _m_ using _hash_(_kG_ || _m_), where || stands for concatenation.
We've now defined a version of the schnorr signature protocol, but 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 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 signatures, Bitcoin's version of schnorr signatures, called _BIP340
schnorr signatures for secp256k1_, also commits to the public key being schnorr signatures for secp256k1_, also commits to the public key being
used in addition to the public nonce and the message. That makes the 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 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. 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_. nonce _kG_.
2. She chooses her message _m_ (e.g., transaction data) and generates the 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_ 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 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. transaction to full nodes.
4. The verifiers (e.g., full nodes) use _s_ to derive _sG_ and then 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 valid, Alice proved that she knows her private key _x_ (without
revealing it) and committed to the message _m_ (containing the revealing it) and committed to the message _m_ (containing the
transaction data). transaction data).
@ -609,14 +609,14 @@ simple multisignature protocol:
public nonce _kG_ = _aG_ + _bG_. public nonce _kG_ = _aG_ + _bG_.
2. They agree on the message to sign, _m_ (e.g., a transaction), and 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 3. Alice produces the scalar _q_ = _a_ + _ey_. Bob produces the scalar
_r_ = _b_ + _ez_. They add the scalars together to produce _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_ and _s_.
4. The verifiers check their public key and signature using the normal 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 Alice and Bob have proven that they know the sum of their private keys without
either one of them revealing their private key to the other or anyone either one of them revealing their private key to the other or anyone
@ -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 party might learn the public keys of the other parties before committing
to their own public key. For example, Alice generates her public key to their own public key. For example, Alice generates her public key
_yG_ honestly and shares it with Bob. Bob generates his public key _yG_ honestly and shares it with Bob. Bob generates his public key
using _zG_ - _yG_. When their two keys are combined (_yG_ + _zG_ - _yG_), the using _zG_ – _yG_. When their two keys are combined (_yG_ + _zG_ – _yG_), the
positive and negative _yG_ terms cancel out so the public key only represents positive and negative _yG_ terms cancel out so the public key only represents
the private key for _z_ (i.e., Bob's private key). Now Bob can create a the private key for _z_ (i.e., Bob's private key). Now Bob can create a
valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a

1
ch11_blockchain.adoc
View File

@ -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. 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]] [[chain_of_blocks]]
[role="smallerfourtyfive"]
.Blocks linked in a chain by each referencing the previous block header hash .Blocks linked in a chain by each referencing the previous block header hash
image::images/mbc3_1101.png[] image::images/mbc3_1101.png[]

8
ch12_mining.adoc
View File

@ -289,7 +289,7 @@ criteria:
- For each input, if the referenced output transaction is a coinbase - For each input, if the referenced output transaction is a coinbase
output, it must have at least +COINBASE_MATURITY+ (100) confirmations. 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 relay transactions a block before they mature since they will be
mature if included in the next block. mature if included in the next block.
@ -630,7 +630,7 @@ nonce field.
[TIP] [TIP]
==== ====
The protocol upgrades defined in BIPs 34, 66, and 65 occurred in that 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 (+OP_CHECKTIMELOCKVERIFY+), so Bitcoin developers often list them in
that order rather than sorted numerically. that order rather than sorted numerically.
==== ====
@ -866,7 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get:
++++ ++++
<ul class="simplelist"> <ul class="simplelist">
<li>target = 0x03a30c × 2<sup>0x08 × (0x19 - 0x03)</sup></li> <li>target = 0x03a30c × 2<sup>0x08 × (0x19 – 0x03)</sup></li>
</ul> </ul>
++++ ++++
@ -941,7 +941,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
<<retarget_code>> shows the code used in the Bitcoin Core client. <<retarget_code>> shows the code used in the Bitcoin Core client.
[[retarget_code]] [[retarget_code]]
.Retargeting the proof of work[.plain]#—++CalculateNextWorkRequired()++# in pow.cpp .Retargeting the proof of work: [.plain]#++CalculateNextWorkRequired()++# in pow.cpp
==== ====
[source,cpp] [source,cpp]
---- ----

2
ch14_applications.adoc
View File

@ -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 and Fabian. It may have additional outputs for change back to
Emma's wallet. 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 video. Emma's software creates and signs a commitment transaction that
changes the channel balance to credit 0.01 millibit to Fabian's address 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 and refund 35.99 millibits back to Emma. The transaction signed by Emma