spellcheck

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

ch04_keys.adoc

@@ -1085,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet
 .Bech32 typo detection
 ====
 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
 https://oreil.ly/paWIx[bech32 address decoder demo].

ch05_wallets.adoc

@@ -643,7 +643,7 @@ A few example descriptors are shown in <<sample_descriptors>>.
 </tr>
 <tr>
 <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>
 <td><p><code>pkh([d34db33f/44'/0'/0']xpub6ERA…​RcEL/1/*)</code></p></td>

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

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[]
 

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:
 
 ++++
 <ul class="simplelist">
-  <li>target = 0x03a30c × 2<sup>0x08 × (0x19 - 0x03)</sup></li>
+  <li>target = 0x03a30c × 2<sup>0x08 × (0x19 – 0x03)</sup></li>
 </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]]
-.Retargeting the proof of work[.plain]#—++CalculateNextWorkRequired()++# in pow.cpp
+.Retargeting the proof of work: [.plain]#++CalculateNextWorkRequired()++# in pow.cpp
 ====
 [source,cpp]
 ----

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