ce check

appc_bips.adoc

@@ -65,7 +65,7 @@ BIPs that are implemented by Bitcoin Core:
 -    BIP325: Signet test network is supported as of v0.21.0 (PR 18267).
 -    BIP339: Relay of transactions by wtxid is supported as of v0.21.0 (PR 18044).
 -    BIP340 341 342: Validation rules for Taproot (including Schnorr signatures and Tapscript leaves) are implemented as of v0.21.0 (PR 19953), with mainnet activation as of v0.21.1 (PR 21377, PR 21686).
--    BIP350: Addresses for native v1+ segregated Witness outputs use Bech32m instead of Bech32 as of v22.0 (PR 20861).
+-    BIP350: Addresses for native v1+ segregated Witness outputs use bech32m instead of bech32 as of v22.0 (PR 20861).
 -    BIP371: Taproot fields for PSBT as of v24.0 (PR 22558).
 -    BIP380 381 382 383 384 385: Output Script Descriptors, and most of Script Expressions are implemented as of v0.17.0 (PR 13697).
 -    BIP386: tr() Output Script Descriptors are implemented as of v22.0 (PR 22051).

ch02_overview.adoc

@@ -510,7 +510,7 @@ valid block something that requires an incredible amount of work to
 create but only a trivial amount of work to verify.  The simple
 verification process is able to probabalistically prove the work was
 done, so the data necessary to generate that proof--in this case, the
-block--is called proof of ork (PoW).
+block--is called proof of work (PoW).
 
 Transactions are added to the new block, prioritized by the highest fee rate
 transactions first and a few other criteria. Each miner starts the

ch03_bitcoin-core.adoc

@@ -263,7 +263,7 @@ Here are some useful options that override the default behavior of the
 <dd><p>If you are building a wallet, allow the use of an incompatible version of the Berkeley DB library.</p></dd>
 
 <dt><code>--with-gui=no</code></dt>
-<dd><p>Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin only.</p></dd>
+<dd><p>Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin Core only.</p></dd>
 </dl>
 ++++
 
@@ -297,7 +297,7 @@ will compile the source code, a process that can take up to an hour to
 complete, depending on the speed of your CPU and available memory.
 If an error
 occurs, or the compilation process is interrupted, it can be resumed any
-time by typing +make+ again. Type +make+ to start compiling the
+time by typing +make+ again. Type *+make+* to start compiling the
 executable application:
 
 ----
@@ -707,10 +707,10 @@ and their expected output.
 Bitcoin
 Core provides status reports on different modules through the JSON-RPC
 interface. The most important commands include +getblockchaininfo+,
-+getmempoolinfo+, +getnetworkinfo+, and +getwalletinfo+.
++getmempoo&#x2060;l&#x200b;info+, +getnetworkinfo+, and +getwalletinfo+.
 
 Bitcoin's +getblockchaininfo+ RPC command was introduced earlier. The
-+getnetworkinfo+ command displays basic information about the status of
++getnetwor&#x2060;k&#x200b;info+ command displays basic information about the status of
 the Bitcoin network node. Use +bitcoin-cli+ to run it:
 
 ----
@@ -1012,7 +1012,7 @@ $ curl --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031
 
 Alternatively, you can
 create a static password with the helper script provided in
-_./share/rpcauth/rpcauth.py_ in Bitcoin Core's source directory.
+[.keep-together]#_./share/rpcauth/rpcauth.py_# in Bitcoin Core's source directory.
 
 If you're implementing a JSON-RPC call in your own program, you can use
 a generic HTTP library to construct the call, similar to what is shown

ch04_keys.adoc

@@ -832,7 +832,7 @@ communicate his public key to her.  Like that problem, where
 public keys can be fairly large, the constraints Bob uses can also be
 quite large--potentially thousands of bytes.  That's not only thousands
 of bytes which need to be communicated to Alice, but thousands of bytes
-for which she needs to pay transaction fees every time she wants to spend.  However, the solution of using hash functions to create
+for which she needs to pay transaction fees every time she wants to spend money to Bob.  However, the solution of using hash functions to create
 small commitments to large amounts of data also applies here.
 
 The BIP16 upgrade to the Bitcoin protocol in 2012 allows an
@@ -859,7 +859,7 @@ OP_HASH160 <commitment> OP_EQUAL
 
 [WARNING]
 ====
-When using Spay to script hash (P2SH), you must use the specific P2SH template
+When using pay to script hash (P2SH), you must use the specific P2SH template
 with no extra data or conditions in the output script.  If the
 output script is not exactly +OP_HASH160 <20 bytes> OP_EQUAL+, the
 redeem script will not be used and any bitcoins may either be unspendable
@@ -1232,7 +1232,6 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
 
 [[scripts_for_diff_segwit_outputs]]
 .Scripts for different types of segwit outputs
-[cols="1,1"]
 [options="header"]
 |===
 
@@ -1398,7 +1397,7 @@ wallets support the ability to export or import an individual key.  The
 information in this section is mainly of interest to anyone needing
 compatibility with early Bitcoin wallets.
 
-For more information, see <<hd_wallets>>.
+See <<hd_wallets>> for more information.
 
 ****
 
@@ -1639,17 +1638,6 @@ keys, possibly with a hardware signing device to store keys and sign transaction
 USE PAPER WALLETS.
 ====
 
-Paper wallets come in many shapes, sizes, and designs, but at a very
-basic level are just a key and an address printed on paper.
-<<table_4-14>> shows the simplest form of a paper wallet.
-
-[[table_4-14]]
-.Simplest form of a paper wallet—a printout of the Bitcoin address and private key
-[options="header"]
-|=======================
-|Public address|Private key (WIF)
-|1424C2F4bC9JidNjjTUZCbUxv6Sa1Mt62x|5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
-|=======================
 
 Paper wallets come in many designs and sizes, with many different
 features. <<paper_wallet_simple>> shows a sample paper wallet.

ch05_wallets.adoc

@@ -431,7 +431,6 @@ an example, see <<alice_tx_labels>>.
 
 [[alice_tx_labels]]
 .Alice's transaction history with each transaction labeled
-[cols="1,1,>1"]
 [options="header"]
 |===
 | Date | Label | BTC
@@ -514,7 +513,6 @@ paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implic
 
 [[bip_implicit_paths]]
 .Implicit script paths defined by various BIPs
-[cols="1,1,1"]
 [options="header"]
 |===
 | Standard | Script | BIP32 path
@@ -1034,16 +1032,16 @@ coding for extended keys uses a special version number that results in
 the prefix "xprv" and "xpub" when encoded in base58 characters to make
 them easily recognizable. Because the extended key contains many more
 bytes than regular addresses,
-it is also much longer than other Base58Check-encoded strings we have
+it is also much longer than other base58check-encoded strings we have
 seen previously.
 
-Here's an example of an extended _private_ key, encoded in Base58Check:
+Here's an example of an extended _private_ key, encoded in base58check:
 
 ----
 xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
 ----
 
-Here's the corresponding extended _public_ key, encoded in Base58Check:
+Here's the corresponding extended _public_ key, encoded in base58check:
 
 ----
 xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9

ch07_authorization-authentication.adoc

@@ -152,7 +152,7 @@ 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
-can produce the TRUE result that signifies a valid transaction.
+can produce the +TRUE+ result that signifies a valid transaction.
 
 ===== A simple script
 
@@ -170,7 +170,7 @@ page].
 Although most legacy output scripts refer to a public key hash (essentially, a
 legacy Bitcoin address), thereby requiring proof of ownership to spend the
 funds, the script does not have to be that complex. Any combination of
-output and input scripts that results in a TRUE value is valid. The
+output and input scripts that results in a +TRUE+ value is valid. The
 simple arithmetic we used as an example of the scripting language is
 also a valid script.
 
@@ -268,10 +268,10 @@ signature created by the corresponding private key (see
 OP_DUP OP_HASH160 <Key Hash> OP_EQUALVERIFY OP_CHECKSIG
 ----
 
-The +Key Hash+ is the data that would be encoded into a legacy Base58Check
+The +Key Hash+ is the data that would be encoded into a legacy base58check
 address.  Most applications would show the _public key hash_ in a script
 using hexadecimal encoding and not the familiar Bitcoin
-address Base58Check format that begins with a "1."
+address base58check format that begins with a "1."
 
 The preceding output script can be satisfied with an input script
 of the form:
@@ -287,7 +287,7 @@ script:
 <Sig> <Pubkey> OP_DUP OP_HASH160 <Hash> OP_EQUALVERIFY OP_CHECKSIG
 ----
 
-The result will be TRUE if the input script
+The result will be +TRUE+ if the input script
 has a valid signature from Bob's private key that corresponds to
 the public key hash set as an encumbrance.
 
@@ -358,7 +358,7 @@ The two scripts together would form the combined validation script:
 <Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
 ----
 
-When executed, this combined script will evaluate to TRUE if
+When executed, this combined script will evaluate to +TRUE+ if
 the input script has
 two valid signatures from private keys that correspond to two of
 the three public keys set as an encumbrance.
@@ -605,13 +605,13 @@ If the redeem script hash matches, the redeem script is executed:
 
 Another
 important part of the P2SH feature is the ability to encode a script
-hash as an address, as defined in BIP13. P2SH addresses are Base58Check
+hash as an address, as defined in BIP13. P2SH addresses are base58check
 encodings of the 20-byte hash of a script, just like Bitcoin addresses
-are Base58Check encodings of the 20-byte hash of a public key. P2SH
+are base58check encodings of the 20-byte hash of a public key. P2SH
 addresses use the version prefix "5," which results in
-Base58Check-encoded addresses that start with a "3."
+base58check-encoded addresses that start with a "3."
 
-For example, Mohammed's complex script, hashed and Base58Check-encoded
+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
@@ -782,7 +782,7 @@ The +OP_CLTV+ opcode takes one parameter as input, expressed as a number in
 the same format as lock time (either a block height or Unix epoch
 time). As indicated by the +VERIFY+ suffix, +OP_CLTV+ is the type of opcode
 that halts execution of the script if the outcome is +FALSE+. If it
-results in TRUE, execution continues.
+results in +TRUE+, execution continues.
 
 In order to use +OP_CLTV+, you insert it into the redeem script of the
 output in the transaction that creates the output. For
@@ -902,7 +902,7 @@ implemented according to the specifications in
 https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68,
 Relative lock-time using consensus-enforced sequence numbers] and
 https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
-OP_CHECKSEQUENCEVERIFY].
++OP_CHECKSEQUENCEVERIFY+].
 
 BIP68 and BIP112 were activated in May 2016 as a soft fork upgrade to
 the consensus rules.
@@ -1035,7 +1035,7 @@ valid preimage and a signature:
 <Bob's Sig> <hash pre-image>
 ----
 
-Without presenting the pre-image, Bob can't get to the part of the
+Without presenting the preimage, Bob can't get to the part of the
 script that checks for his signature.
 
 

ch08_signatures.adoc

@@ -141,7 +141,7 @@ and is applied by bitwise OR, resulting in the combined flags as shown
 in <<sighash_types_with_modifiers>>.
 
 [[sighash_types_with_modifiers]]
-.++SIGHASH++ types with modifiers and their meanings
+.[.plain]#++SIGHASH++# types with modifiers and their meanings
 [options="header"]
 |=======================
 |++SIGHASH++ flag| Value | Description

ch09_fees.adoc

@@ -525,7 +525,7 @@ Protocol developers have been working on mitigating problems with
 transaction pinning for several years.  One partial solution is
 described in <<cpfp_carve_out>>.  Several other solutions have been
 proposed, and at least one solution is being actively developed as of
-this writing—https://bitcoinops.org/en/topics/ephemeral-anchors/[ephemeral anchors].
+this writing&emdash;https://bitcoinops.org/en/topics/ephemeral-anchors[ephemeral anchors].
 
 [[cpfp_carve_out]]
 === CPFP Carve Out and Anchor Outputs

ch10_network.adoc

@@ -270,7 +270,7 @@ information, including:
 +nTime+:: The current time
 +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., pass:[<span class="keep-together"><code>/Satoshi:0.9.2.1/</code></span>])
++subver+:: A subversion showing the type of software running on this [.keep-together]#node (e.g.,# pass:[<span class="keep-together"><code>/Satoshi:0.9.2.1/</code></span>])
 +BestHeight+:: The block height of this node's blockchain
 +fRelay+:: A field added by BIP37 for requesting not to receive unconfirmed transactions
 

ch11_blockchain.adoc

@@ -119,8 +119,8 @@ block header twice through the SHA256 algorithm. The resulting 32-byte
 hash is called the _block hash_ but is more accurately the _block header
 hash_, pass:[<span class="keep-together">because only the block header is
 used to compute it. For example,</span>]
-+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is
++000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ [.keep-together]#is
-the block hash of the first block on Bitcoin's blockchain. The block hash
+the block# hash of the first block on Bitcoin's blockchain. The block hash
 identifies a block uniquely and unambiguously and can be independently
 derived by any node by simply hashing the block header.
 
@@ -765,17 +765,17 @@ ecommerce site; or even developing novel smart contracts and complex
 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
+Test your code locally on a regtest as you develop it. Once you are
-ready to try it on a public network, switch to +signet+ or +testnet+ to expose your
+ready to try it on a public network, switch to signet or testnet to expose your
 code to a more dynamic environment with more diversity of code and
 applications. Finally, once you are confident your code works as
-expected, switch to +mainnet+ to deploy it in production. As you make
+expected, switch to mainnet to deploy it in production. As you make
 changes, improvements, bug fixes, etc., start the pipeline again,
-deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally
+deploying each change first on regtest, then on signet or testnet, and finally
 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
-specical commitment that both provides computational security and
+special commitment that both provides computational security and
 ensures no block can be changed without invalidating all other blocks
 built on top of it: Bitcoin's mining function.

meta/github_contrib.adoc

@@ -1,6 +1,6 @@
 ++++
 <ul class="twocolumn">
-<li>Abdussamad Abdurrazzaq (AbdussamadA)</li>
+<li>Abdussamad Abdurrazzaq [.keep-together]#(AbdussamadA)#</li>
 <li>Adán SDPC (aesedepece)</li>
 <li>Akira Chiku (achiku)</li>
 <li>Alex Waters (alexwaters)</li>
@@ -117,9 +117,9 @@
 <li>Maximilian Reichel (phramz)</li>
 <li>MG-ng (MG-ng)</li>
 <li>Michalis Kargakis (kargakis)</li>
-<li>Michael C. Ippolito (michaelcippolito)</li>
+<li>Michael C. Ippolito [.keep-together]#(michaelcippolito)#</li>
 <li>Michael Galero (mikong)</li>
-<li>Michael Newman (michaelbnewman)</li>
+<li>Michael Newman [.keep-together]#(michaelbnewman)#</li>
 <li>Mihail Russu (MihailRussu)</li>
 <li>mikew (mikew)</li>
 <li>milansismanovic</li>
@@ -137,7 +137,7 @@
 <li>Omar Boukli-Hacene (oboukli)</li>
 <li>Óscar Nájera (Titan-C)</li>
 <li>Parzival (Parz-val)</li>
-<li>Paul Desmond Parker (sunwukonga)</li>
+<li>Paul Desmond Parker [.keep-together]#(sunwukonga)#</li>
 <li>Philipp Gille (philippgille)</li>
 <li>ratijas</li>
 <li>rating89us</li>

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 a CD-ROM of 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 the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, 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_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
 
 Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
 

theme/pdf/pdf.css

@@ -65,11 +65,11 @@ pre.c_less_space2 {
   line-height: 105%;
 }
 
-/*----Uncomment to temporarily turn on code-eyballer highlighting (make sure to recomment after you build)---*/
+/*----Uncomment to temporarily turn on code-eyballer highlighting (make sure to recomment after you build)
 
 pre {
  background-color: yellow;
-}
+}---*/
 
 
 /*----Uncomment to turn on automatic code wrapping