From a39fb72df21a7c680606aacd0aa8f40d9db4247a Mon Sep 17 00:00:00 2001 From: Clare Laylock Date: Mon, 9 Oct 2023 11:56:00 -0400 Subject: [PATCH] ce check --- appc_bips.adoc | 2 +- ch02_overview.adoc | 2 +- ch03_bitcoin-core.adoc | 10 +++++----- ch04_keys.adoc | 18 +++--------------- ch05_wallets.adoc | 8 +++----- ch07_authorization-authentication.adoc | 26 +++++++++++++------------- ch08_signatures.adoc | 2 +- ch09_fees.adoc | 2 +- ch10_network.adoc | 2 +- ch11_blockchain.adoc | 14 +++++++------- meta/github_contrib.adoc | 8 ++++---- preface.asciidoc | 2 +- theme/pdf/pdf.css | 4 ++-- 13 files changed, 43 insertions(+), 57 deletions(-) diff --git a/appc_bips.adoc b/appc_bips.adoc index 091d6872..c3b78d1b 100644 --- a/appc_bips.adoc +++ b/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). diff --git a/ch02_overview.adoc b/ch02_overview.adoc index 6ea81862..1a436c38 100644 --- a/ch02_overview.adoc +++ b/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 diff --git a/ch03_bitcoin-core.adoc b/ch03_bitcoin-core.adoc index 3465a224..999a9e99 100644 --- a/ch03_bitcoin-core.adoc +++ b/ch03_bitcoin-core.adoc @@ -263,7 +263,7 @@ Here are some useful options that override the default behavior of the

If you are building a wallet, allow the use of an incompatible version of the Berkeley DB library.

--with-gui=no
-

Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin only.

+

Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin Core only.

++++ @@ -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⁠l​info+, +getnetworkinfo+, and +getwalletinfo+. Bitcoin's +getblockchaininfo+ RPC command was introduced earlier. The -+getnetworkinfo+ command displays basic information about the status of ++getnetwor⁠k​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 diff --git a/ch04_keys.adoc b/ch04_keys.adoc index 39c483a6..4401d1e1 100644 --- a/ch04_keys.adoc +++ b/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 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 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 <>. +See <> 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. -<> 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. <> shows a sample paper wallet. diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index 18aaead1..c8aa54ef 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -431,7 +431,6 @@ an example, see <>. [[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 < 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: OP_DUP OP_HASH160 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: 2 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: ---- -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. diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index 042e14d5..77a0ae72 100644 --- a/ch08_signatures.adoc +++ b/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 and their meanings +.[.plain]#++SIGHASH++# types with modifiers and their meanings [options="header"] |======================= |++SIGHASH++ flag| Value | Description diff --git a/ch09_fees.adoc b/ch09_fees.adoc index 6ce81dbe..3596448a 100644 --- a/ch09_fees.adoc +++ b/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 <>. 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 diff --git a/ch10_network.adoc b/ch10_network.adoc index c99704ac..dd37a947 100644 --- a/ch10_network.adoc +++ b/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:[/Satoshi:0.9.2.1/]) ++subver+:: A subversion showing the type of software running on this [.keep-together]#node (e.g.,# pass:[/Satoshi:0.9.2.1/]) +BestHeight+:: The block height of this node's blockchain +fRelay+:: A field added by BIP37 for requesting not to receive unconfirmed transactions diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc index d6339c08..c0e63eef 100644 --- a/ch11_blockchain.adoc +++ b/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:[because only the block header is used to compute it. For example,] -+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is -the block hash of the first block on Bitcoin's blockchain. The block hash ++000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ [.keep-together]#is +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 -ready to try it on a public network, switch to +signet+ or +testnet+ to expose your +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 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. diff --git a/meta/github_contrib.adoc b/meta/github_contrib.adoc index e905bf71..7477925f 100644 --- a/meta/github_contrib.adoc +++ b/meta/github_contrib.adoc @@ -1,6 +1,6 @@ ++++
    -
  • Abdussamad Abdurrazzaq (AbdussamadA)
    • +
  • Abdussamad Abdurrazzaq [.keep-together]#(AbdussamadA)#
  • Adán SDPC (aesedepece)
  • Akira Chiku (achiku)
  • Alex Waters (alexwaters)
    • @@ -117,9 +117,9 @@
  • Maximilian Reichel (phramz)
  • MG-ng (MG-ng)
  • Michalis Kargakis (kargakis)
    • -
  • Michael C. Ippolito (michaelcippolito)
    • +
  • Michael C. Ippolito [.keep-together]#(michaelcippolito)#
  • Michael Galero (mikong)
    • -
  • Michael Newman (michaelbnewman)
    • +
  • Michael Newman [.keep-together]#(michaelbnewman)#
  • Mihail Russu (MihailRussu)
  • mikew (mikew)
  • milansismanovic
    • @@ -137,7 +137,7 @@
  • Omar Boukli-Hacene (oboukli)
  • Óscar Nájera (Titan-C)
  • Parzival (Parz-val)
    • -
  • Paul Desmond Parker (sunwukonga)
    • +
  • Paul Desmond Parker [.keep-together]#(sunwukonga)#
  • Philipp Gille (philippgille)
  • ratijas
  • rating89us
    • diff --git a/preface.asciidoc b/preface.asciidoc index 6db7c819..d6f0cc53 100644 --- a/preface.asciidoc +++ b/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. diff --git a/theme/pdf/pdf.css b/theme/pdf/pdf.css index 8b9edaf9..3006c8e1 100644 --- a/theme/pdf/pdf.css +++ b/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