arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-25 17:38:26 +00:00
Code Issues Releases Wiki Activity

periods in image captions

Browse Source
This commit is contained in:
Clare Laylock 2023-10-27 09:41:16 -04:00
parent f9b7a6087f
commit 599394a35e
11 changed files with 69 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ch01_intro.adoc
View File

@ -383,7 +383,7 @@ Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_
[role="width-50"] [role="width-50"]
[[wallet_receive]] [[wallet_receive]]
.Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format .Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format.
image::images/mbc3_0101.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"] image::images/mbc3_0101.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"]
The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera. The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@ -475,7 +475,7 @@ prompt him with a suggested fee (or fee rate). The higher the transaction fee,
faster the transaction will be confirmed (see <<confirmations>>). faster the transaction will be confirmed (see <<confirmations>>).
[[wallet-send]] [[wallet-send]]
.Bitcoin wallet send screen .Bitcoin wallet send screen.
image::images/mbc3_0102.png["Wallet send screen. Image derived from Bitcoin Design Guide CC-BY"] image::images/mbc3_0102.png["Wallet send screen. Image derived from Bitcoin Design Guide CC-BY"]
Joe then carefully checks to make sure he has entered the correct Joe then carefully checks to make sure he has entered the correct

16
ch02_overview.adoc
View File

@ -89,7 +89,7 @@ TODO: Replace QR code with test-BTC address
//// ////
[[invoice-QR]] [[invoice-QR]]
.Invoice QR code .Invoice QR code.
image::images/mbc3_0201.png["payment-request"] image::images/mbc3_0201.png["payment-request"]
Unlike a QR code that simply contains a destination Bitcoin address, this Unlike a QR code that simply contains a destination Bitcoin address, this
@ -177,7 +177,7 @@ is signing a transaction that transfers value from a previous
transaction over to a new owner identified by a Bitcoin ((("transactions", "inputs", startref="transaction-input-ch2")))((("transactions", "outputs", startref="transaction-output-ch2")))((("inputs", startref="input")))((("outputs", startref="output")))address. transaction over to a new owner identified by a Bitcoin ((("transactions", "inputs", startref="transaction-input-ch2")))((("transactions", "outputs", startref="transaction-output-ch2")))((("inputs", startref="input")))((("outputs", startref="output")))address.
[[transaction-double-entry]] [[transaction-double-entry]]
.Transaction as double-entry bookkeeping .Transaction as double-entry bookkeeping.
image::images/mbc3_0202.png["Transaction Double-Entry"] image::images/mbc3_0202.png["Transaction Double-Entry"]
==== Transaction Chains ==== Transaction Chains
@ -223,7 +223,7 @@ change.
//// ////
[[transaction-chain]] [[transaction-chain]]
.A chain of transactions, where the output of one transaction is the input of the next transaction .A chain of transactions, where the output of one transaction is the input of the next transaction.
image::images/mbc3_0203.png["Transaction chain"] image::images/mbc3_0203.png["Transaction chain"]
[TIP] [TIP]
@ -295,7 +295,7 @@ transaction has one input and two outputs and is shown in
<<transaction-common>>. <<transaction-common>>.
[[transaction-common]] [[transaction-common]]
.Most common transaction .Most common transaction.
image::images/mbc3_0204.png["Common Transaction"] image::images/mbc3_0204.png["Common Transaction"]
Another common form of transaction ((("consolidation transactions")))is a _consolidation transaction_, which spends several inputs Another common form of transaction ((("consolidation transactions")))is a _consolidation transaction_, which spends several inputs
@ -305,7 +305,7 @@ notes for a single larger note. Transactions like these are sometimes
generated by wallets and businesses to clean up lots of smaller amounts. generated by wallets and businesses to clean up lots of smaller amounts.
[[transaction-consolidating]] [[transaction-consolidating]]
.Consolidation transaction aggregating funds .Consolidation transaction aggregating funds.
image::images/mbc3_0205.png["Aggregating Transaction"] image::images/mbc3_0205.png["Aggregating Transaction"]
Finally, another transaction form that is seen often on the Finally, another transaction form that is seen often on the
@ -316,7 +316,7 @@ distribute funds, such as when processing payroll payments to multiple((("transa
employees. employees.
[[transaction-distributing]] [[transaction-distributing]]
.Batch transaction distributing funds .Batch transaction distributing funds.
image::images/mbc3_0206.png["Distributing Transaction"] image::images/mbc3_0206.png["Distributing Transaction"]
=== Constructing a Transaction === Constructing a Transaction
@ -589,7 +589,7 @@ the process of mining and the way it builds confidence in more ((("bitcoins", "m
<<mining>>. <<mining>>.
[[block-alice1]] [[block-alice1]]
.Alice's transaction included in a block .Alice's transaction included in a block.
image::images/mbc3_0207.png["Alice's transaction included in a block"] image::images/mbc3_0207.png["Alice's transaction included in a block"]
[role="less_space pagebreak-before"] [role="less_space pagebreak-before"]
@ -618,7 +618,7 @@ for a new website page. Now the chain of transactions will
look like <<block-alice2>>. look like <<block-alice2>>.
[[block-alice2]] [[block-alice2]]
.Alice's transaction as part of a transaction chain from Joe to Gopesh .Alice's transaction as part of a transaction chain from Joe to Gopesh.
image::images/mbc3_0208.png["Alice's transaction as part of a transaction chain"] image::images/mbc3_0208.png["Alice's transaction as part of a transaction chain"]
In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value

2
ch03_bitcoin-core.adoc
View File

@ -52,7 +52,7 @@ of Bitcoin peer-to-peer communication.
Core. Core.
[[bitcoin_core_architecture]] [[bitcoin_core_architecture]]
.Bitcoin Core architecture (Source: Eric Lombrozo) .Bitcoin Core architecture (Source: Eric Lombrozo).
image::images/mbc3_0301.png["Bitcoin Core Architecture"] image::images/mbc3_0301.png["Bitcoin Core Architecture"]
Although Bitcoin Core serves as a reference implementation for many Although Bitcoin Core serves as a reference implementation for many

20
ch04_keys.adoc
View File

@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
those goals, shown in <<pay-to-pure-pubkey>>. those goals, shown in <<pay-to-pure-pubkey>>.
[[pay-to-pure-pubkey]] [[pay-to-pure-pubkey]]
.Transaction chain from original Bitcoin paper .Transaction chain from original Bitcoin paper.
image::images/mbc3_aain01.png["Transaction chain from original Bitcoin paper"] image::images/mbc3_aain01.png["Transaction chain from original Bitcoin paper"]
A receiver like Bob A receiver like Bob
@ -172,7 +172,7 @@ by Bitcoin.
[[ecc-curve]] [[ecc-curve]]
[role="width-50"] [role="width-50"]
.An elliptic curve .An elliptic curve.
image::images/mbc3_0402.png["ecc-curve"] image::images/mbc3_0402.png["ecc-curve"]
Bitcoin uses a specific elliptic curve and set of mathematical Bitcoin uses a specific elliptic curve and set of mathematical
@ -212,7 +212,7 @@ grid. The +secp256k1+ Bitcoin elliptic curve can be thought of as a much
more complex pattern of dots on a unfathomably large grid. more complex pattern of dots on a unfathomably large grid.
[[ecc-over-F17-math]] [[ecc-over-F17-math]]
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17 .Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17.
image::images/mbc3_0403.png["ecc-over-F17-math"] image::images/mbc3_0403.png["ecc-over-F17-math"]
So, for example, the following is a point P with coordinates (x, y) that So, for example, the following is a point P with coordinates (x, y) that
@ -389,7 +389,7 @@ library] to do the elliptic curve((("public keys", "generating", startref="publi
==== ====
[[ecc_illustrated]] [[ecc_illustrated]]
.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve .Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve.
image::images/mbc3_0404.png["ecc_illustrated"] image::images/mbc3_0404.png["ecc_illustrated"]
=== Output and Input Scripts === Output and Input Scripts
@ -432,7 +432,7 @@ better understand why certain features may have been added to the
Bitcoin protocol. Bitcoin protocol.
[[bitcoin_01_send]] [[bitcoin_01_send]]
.Early send screen for Bitcoin via https://oreil.ly/IDV1a[The Internet Archive] .Early send screen for Bitcoin via https://oreil.ly/IDV1a[The Internet Archive].
image::images/mbc3_0405.png["Early Bitcoin send screen"] image::images/mbc3_0405.png["Early Bitcoin send screen"]
If Alice entered Bob's IP address in Bitcoin 0.1, her full node would If Alice entered Bob's IP address in Bitcoin 0.1, her full node would
@ -688,7 +688,7 @@ previously. <<base58check_encoding>> illustrates the base58check
encoding process. encoding process.
[[base58check_encoding]] [[base58check_encoding]]
.Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data .Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data.
image::images/mbc3_0406.png["Base58CheckEncoding"] image::images/mbc3_0406.png["Base58CheckEncoding"]
++++ ++++
@ -757,7 +757,7 @@ encoding, <<pubkey_to_address>> illustrates the conversion of a public key
into a Bitcoin ((("public key cryptography", "base58check encoding", startref="pub-key-base58")))((("base58check encoding", startref="base58-ch4")))((("encoding", "base58check", startref="encode-base58")))((("version prefixes", startref="version-prefix")))address. into a Bitcoin ((("public key cryptography", "base58check encoding", startref="pub-key-base58")))((("base58check encoding", startref="base58-ch4")))((("encoding", "base58check", startref="encode-base58")))((("version prefixes", startref="version-prefix")))address.
[[pubkey_to_address]] [[pubkey_to_address]]
.Public key to Bitcoin address: conversion of a public key to a Bitcoin address .Public key to Bitcoin address: conversion of a public key to a Bitcoin address.
image::images/mbc3_0407.png["pubkey_to_address"] image::images/mbc3_0407.png["pubkey_to_address"]
[[comp_pub]] [[comp_pub]]
@ -827,7 +827,7 @@ point. Public key compression is illustrated in <<pubkey_compression>>.
[[pubkey_compression]] [[pubkey_compression]]
.Public key compression .Public key compression.
image::images/mbc3_0408.png["pubkey_compression"] image::images/mbc3_0408.png["pubkey_compression"]
@ -1113,7 +1113,7 @@ https://oreil.ly/paWIx[bech32 address decoder demo].
<<bech32_qrcode_uc_lc>>. <<bech32_qrcode_uc_lc>>.
[[bech32_qrcode_uc_lc]] [[bech32_qrcode_uc_lc]]
.The same bech32 address QR encoded in lowercase and uppercase .The same bech32 address QR encoded in lowercase and uppercase.
image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and uppercase"] image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and uppercase"]
- Bech32 takes advantage of an upgrade mechanism designed as part of - Bech32 takes advantage of an upgrade mechanism designed as part of
@ -1858,7 +1858,7 @@ Paper wallets come in many designs and sizes, with many different
features. <<paper_wallet_simple>> shows a sample paper wallet. features. <<paper_wallet_simple>> shows a sample paper wallet.
[[paper_wallet_simple]] [[paper_wallet_simple]]
.An example of a simple paper wallet .An example of a simple paper wallet.
image::images/mbc3_0410.png[] image::images/mbc3_0410.png[]
Some are intended to be given as gifts and have seasonal themes, such as Some are intended to be given as gifts and have seasonal themes, such as

18
ch05_wallets.adoc
View File

@ -60,7 +60,7 @@ that could only reasonably be backed up using digital media.
[[Type0_wallet]] [[Type0_wallet]]
[role="width-60"] [role="width-60"]
.Nondeterministic key generation: a collection of independently generated keys stored in a wallet database .Nondeterministic key generation: a collection of independently generated keys stored in a wallet database.
image::images/mbc3_0501.png["Non-Deterministic Wallet"] image::images/mbc3_0501.png["Non-Deterministic Wallet"]
Modern wallet applications don't independently generate keys but instead Modern wallet applications don't independently generate keys but instead
@ -116,7 +116,7 @@ possible to store private keys more securely than ((("wallets", "key generation"
[[Type1_wallet]] [[Type1_wallet]]
[role="width-70"] [role="width-70"]
.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database .Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database.
image::images/mbc3_0502.png["Deterministic Wallet"] image::images/mbc3_0502.png["Deterministic Wallet"]
@ -210,7 +210,7 @@ limit on the depth of the tree. This tree structure is illustrated in
<<Type2_wallet>>. <<Type2_wallet>>.
[[Type2_wallet]] [[Type2_wallet]]
.HD wallet: a tree of keys generated from a single seed .HD wallet: a tree of keys generated from a single seed.
image::images/mbc3_0503.png["HD wallet"] image::images/mbc3_0503.png["HD wallet"]
The tree structure can be used to express additional The tree structure can be used to express additional
@ -748,7 +748,7 @@ of entropy, adds a checksum, and then maps the entropy to a word list:
generate a BIP39 recovery code. generate a BIP39 recovery code.
[[generating_entropy_and_encoding]] [[generating_entropy_and_encoding]]
.Generating entropy and encoding as a recovery code .Generating entropy and encoding as a recovery code.
image::images/mbc3_0504.png["Generating entropy and encoding as a recovery code"] image::images/mbc3_0504.png["Generating entropy and encoding as a recovery code"]
<<table_4-5>> shows the relationship between the size of the entropy <<table_4-5>> shows the relationship between the size of the entropy
@ -859,7 +859,7 @@ described previously in <<generating_recovery_words>>:
<<fig_5_7>> shows how a recovery code is used to generate a seed. <<fig_5_7>> shows how a recovery code is used to generate a seed.
[[fig_5_7]] [[fig_5_7]]
.From recovery code to seed .From recovery code to seed.
image::images/mbc3_0505.png["From recovery code to seed"] image::images/mbc3_0505.png["From recovery code to seed"]
@ -1057,7 +1057,7 @@ seed is derived from. The process of creating the master keys and master chain c
wallet is shown in <<HDWalletFromSeed>>. wallet is shown in <<HDWalletFromSeed>>.
[[HDWalletFromSeed]] [[HDWalletFromSeed]]
.Creating master keys and chain code from a root seed .Creating master keys and chain code from a root seed.
image::images/mbc3_0506.png["HDWalletFromRootSeed"] image::images/mbc3_0506.png["HDWalletFromRootSeed"]
The root seed is input into the HMAC-SHA512 algorithm and the resulting The root seed is input into the HMAC-SHA512 algorithm and the resulting
@ -1103,7 +1103,7 @@ index set to 0 to produce the "zero" (first by index) child of the
parent. parent.
[[CKDpriv]] [[CKDpriv]]
.Extending a parent private key to create a child private key .Extending a parent private key to create a child private key.
image::images/mbc3_0507.png["ChildPrivateDerivation"] image::images/mbc3_0507.png["ChildPrivateDerivation"]
Changing the index allows us to extend the parent and create the other Changing the index allows us to extend the parent and create the other
@ -1284,7 +1284,7 @@ the hardware signing device. <<CKDpub>> illustrates the
mechanism for extending a parent public key to derive child ((("wallets", "key generation", "HD (hierarchical deterministic)", startref="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", startref="keygen-hd")))((("HD (hierarchical deterministic) key generation", startref="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", startref="bip32")))((("seeds", "HD wallet creation", startref="seed-hdwallet")))((("key generation", "HD (hierarchical deterministic)", "public child key derivation", startref="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", startref="hd-keygen-public-child")))((("public child key derivation", startref="public-child")))((("child key pair derivation", "public keys", startref="child-key-pair-public")))public keys. mechanism for extending a parent public key to derive child ((("wallets", "key generation", "HD (hierarchical deterministic)", startref="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", startref="keygen-hd")))((("HD (hierarchical deterministic) key generation", startref="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", startref="bip32")))((("seeds", "HD wallet creation", startref="seed-hdwallet")))((("key generation", "HD (hierarchical deterministic)", "public child key derivation", startref="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", startref="hd-keygen-public-child")))((("public child key derivation", startref="public-child")))((("child key pair derivation", "public keys", startref="child-key-pair-public")))public keys.
[[CKDpub]] [[CKDpub]]
.Extending a parent public key to create a child public key .Extending a parent public key to create a child public key.
image::images/mbc3_0508.png["ChildPublicDerivation"] image::images/mbc3_0508.png["ChildPublicDerivation"]
==== Using an Extended Public Key on a Web Store ==== Using an Extended Public Key on a Web Store
@ -1360,7 +1360,7 @@ parent private key is used as input to the hash function, instead of the
parent public key, as shown in the diagram in <<CKDprime>>. parent public key, as shown in the diagram in <<CKDprime>>.
[[CKDprime]] [[CKDprime]]
.Hardened derivation of a child key; omits the parent public key .Hardened derivation of a child key; omits the parent public key.
image::images/mbc3_0509.png["ChildHardPrivateDerivation"] image::images/mbc3_0509.png["ChildHardPrivateDerivation"]

12
ch06_transactions.adoc
View File

@ -83,7 +83,7 @@ top-level fields. We'll examine each of them in the order they appear
in the transaction and describe any additional fields that they((("transactions", "serialized", startref="transaction-serialize")))((("serialized transactions", startref="serial-transactions")))((("Bitcoin Core", "serialized transactions", startref="bitcoin-core-serial-transaction"))) contain. in the transaction and describe any additional fields that they((("transactions", "serialized", startref="transaction-serialize")))((("serialized transactions", startref="serial-transactions")))((("Bitcoin Core", "serialized transactions", startref="bitcoin-core-serial-transaction"))) contain.
[[alice_tx_byte_map]] [[alice_tx_byte_map]]
.A byte map of Alice's transaction .A byte map of Alice's transaction.
image::images/mbc3_0601.png["A byte map of Alice's transaction"] image::images/mbc3_0601.png["A byte map of Alice's transaction"]
[[version]] [[version]]
@ -179,7 +179,7 @@ The((("transactions", "inputs", id="transaction-input")))((("inputs", id="input-
map of those bytes in <<alice_tx_input_map>>. map of those bytes in <<alice_tx_input_map>>.
[[alice_tx_input_map]] [[alice_tx_input_map]]
.Map of bytes in the inputs field of Alice's transaction .Map of bytes in the inputs field of Alice's transaction.
image::images/mbc3_0602.png["map of bytes in the inputs field of Alice's transaction"] image::images/mbc3_0602.png["map of bytes in the inputs field of Alice's transaction"]
==== Length of Transaction Input List ==== Length of Transaction Input List
@ -575,7 +575,7 @@ maximum relative timelock in both blocks and seconds from 16 bits
as defined by BIP68. as defined by BIP68.
[[bip_68_def_of_nseq]] [[bip_68_def_of_nseq]]
.BIP68 definition of sequence encoding (Source: BIP68) .BIP68 definition of sequence encoding (Source: BIP68).
image::images/mbc3_0603.png["BIP68 definition of sequence encoding"] image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
Note that any transaction that sets a relative timelock using sequence Note that any transaction that sets a relative timelock using sequence
@ -591,7 +591,7 @@ transaction where Alice pays Bob, displayed as
a map of those bytes in <<output-byte-map>>. a map of those bytes in <<output-byte-map>>.
[[output-byte-map]] [[output-byte-map]]
.A byte map of the outputs field from Alice's transaction .A byte map of the outputs field from Alice's transaction.
image::images/mbc3_0604.png["A byte map of the outputs field from Alice's transaction"] image::images/mbc3_0604.png["A byte map of the outputs field from Alice's transaction"]
==== Outputs Count ==== Outputs Count
@ -1020,7 +1020,7 @@ other fields, so we'll start with a map of those bytes from
Alice's transaction in <<alice_tx_witness_map>>. Alice's transaction in <<alice_tx_witness_map>>.
[[alice_tx_witness_map]] [[alice_tx_witness_map]]
.A byte map of the witness structure from Alice's transaction .A byte map of the witness structure from Alice's transaction.
image::images/mbc3_0605.png["A byte map of the witness from Alice's transaction"] image::images/mbc3_0605.png["A byte map of the witness from Alice's transaction"]
Unlike the inputs and outputs fields, the overall witness structure doesn't Unlike the inputs and outputs fields, the overall witness structure doesn't
@ -1261,7 +1261,7 @@ this chapter is shown represented in weight units in
the difference in size between the various fields in the ((("transactions", "weights", startref="transactions-weight")))((("weights (of transactions)", startref="weights")))((("vbytes", startref="vbytes")))two images. the difference in size between the various fields in the ((("transactions", "weights", startref="transactions-weight")))((("weights (of transactions)", startref="weights")))((("vbytes", startref="vbytes")))two images.
[[alice_tx_weight_map]] [[alice_tx_weight_map]]
.A byte map of Alice's transaction .A byte map of Alice's transaction.
image::images/mbc3_0606.png["A weight map of Alice's transaction"] image::images/mbc3_0606.png["A weight map of Alice's transaction"]
[[legacy_serialization]] [[legacy_serialization]]

20
ch07_authorization-authentication.adoc
View File

@ -129,7 +129,7 @@ from the concatenation of the scripts prior((("scripts", "input/output", "constr
validation. validation.
[[input_and_output_scripts_legacy]] [[input_and_output_scripts_legacy]]
.Combining input and output scripts to evaluate a transaction script .Combining input and output scripts to evaluate a transaction script.
image::images/mbc3_0701.png["input_and_output_scripts"] image::images/mbc3_0701.png["input_and_output_scripts"]
===== The script execution stack ===== The script execution stack
@ -201,7 +201,7 @@ to know that the number 2 satisfies the script.
[[simplemath_script]] [[simplemath_script]]
.Bitcoin's script validation doing simple math .Bitcoin's script validation doing simple math.
image::images/mbc3_0702.png["TxScriptSimpleMathExample"] image::images/mbc3_0702.png["TxScriptSimpleMathExample"]
[TIP] [TIP]
@ -302,11 +302,11 @@ execution of the combined script, which will prove this is a valid
transaction. transaction.
[[P2PubKHash1]] [[P2PubKHash1]]
.Evaluating a script for a P2PKH transaction (part 1 of 2) .Evaluating a script for a P2PKH transaction (part 1 of 2).
image::images/mbc3_0703.png["Tx_Script_P2PubKeyHash_1"] image::images/mbc3_0703.png["Tx_Script_P2PubKeyHash_1"]
[[P2PubKHash2]] [[P2PubKHash2]]
.Evaluating a script for a P2PKH transaction (part 2 of 2) .Evaluating a script for a P2PKH transaction (part 2 of 2).
image::images/mbc3_0704.png["Tx_Script_P2PubKeyHash_2"] image::images/mbc3_0704.png["Tx_Script_P2PubKeyHash_2"]
[[multisig]] [[multisig]]
@ -1630,7 +1630,7 @@ from <<variable_timelock_multisig>>, we construct a merkle tree for each
of the three authorization conditions in <<diagram_mast1>>. of the three authorization conditions in <<diagram_mast1>>.
[[diagram_mast1]] [[diagram_mast1]]
.A MAST with three subscripts .A MAST with three subscripts.
image::images/mbc3_0705.png["A MAST with three sub-scripts"] image::images/mbc3_0705.png["A MAST with three sub-scripts"]
We can now create a compact membership proof that proves a particular We can now create a compact membership proof that proves a particular
@ -1641,7 +1641,7 @@ computed from other data provided by the user, so they don't need to be
specified at spend time. specified at spend time.
[[diagram_mast2]] [[diagram_mast2]]
.A MAST membership proof for one of the subscripts .A MAST membership proof for one of the subscripts.
image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"] image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"]
[role="less_space pagebreak-before"] [role="less_space pagebreak-before"]
@ -1672,7 +1672,7 @@ conditions only exist in case something goes wrong. We can restructure
our tree with this knowledge as shown in <<diagram_mast3>>. our tree with this knowledge as shown in <<diagram_mast3>>.
[[diagram_mast3]] [[diagram_mast3]]
.A MAST with the most-expected script in the best position .A MAST with the most-expected script in the best position.
image::images/mbc3_0707.png["A MAST with the most-expected script in the best position"] image::images/mbc3_0707.png["A MAST with the most-expected script in the best position"]
[role="less_space pagebreak-before"] [role="less_space pagebreak-before"]
@ -1702,7 +1702,7 @@ _merklized abstract syntax trees_. In an abstract syntax tree (AST),
every condition in a script creates a new branch, as show in <<ast>>. every condition in a script creates a new branch, as show in <<ast>>.
[[ast]] [[ast]]
.An abstract syntax tree (AST) for a script .An abstract syntax tree (AST) for a script.
image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"] image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"]
ASTs are widely used by programs that parse and optimize code for other ASTs are widely used by programs that parse and optimize code for other
@ -1719,7 +1719,7 @@ one of them complete by itself, where only one can be selected--making
them alternatives for each other, as shown in <<alt_script>>. them alternatives for each other, as shown in <<alt_script>>.
[[alt_script]] [[alt_script]]
.An alternative script tree .An alternative script tree.
image::images/mbc3_0709.png["An alternative script tree"] image::images/mbc3_0709.png["An alternative script tree"]
Alternative script trees only require revealing one 32-byte digest for Alternative script trees only require revealing one 32-byte digest for
@ -1902,7 +1902,7 @@ revealing the MAST branch we want to use. That commitment tree
involving both a public key and a MAST is shown in <<diagram_taproot1>>. involving both a public key and a MAST is shown in <<diagram_taproot1>>.
[[diagram_taproot1]] [[diagram_taproot1]]
.A taproot with the public key committing to a merkle root .A taproot with the public key committing to a merkle root.
image::images/mbc3_0710.png["A taproot with the public key committing to a merkle root"] image::images/mbc3_0710.png["A taproot with the public key committing to a merkle root"]
This makes the mutual satisfaction clause using a multisignature This makes the mutual satisfaction clause using a multisignature

14
ch10_network.adoc
View File

@ -108,7 +108,7 @@ the time between when one miner announces a new block and when other
miners receive that block. miners receive that block.
[[mining_race]] [[mining_race]]
.A blockchain fork requiring a mining race .A blockchain fork requiring a mining race.
image::images/mbc3_1001.png["Mining race"] image::images/mbc3_1001.png["Mining race"]
In 2015, a new version of Bitcoin Core added a feature called In 2015, a new version of Bitcoin Core added a feature called
@ -307,7 +307,7 @@ is used to form introductions, the client will disconnect from it and
use the newly discovered peers. use the newly discovered peers.
[[network_handshake]] [[network_handshake]]
.The initial handshake between peers .The initial handshake between peers.
image::images/mbc3_1003.png["NetworkHandshake"] image::images/mbc3_1003.png["NetworkHandshake"]
Once one or more connections are established, the new node will send an Once one or more connections are established, the new node will send an
@ -322,7 +322,7 @@ existence on the network for other nodes to find it.
[[address_propagation]] [[address_propagation]]
.Address propagation and discovery .Address propagation and discovery.
image::images/mbc3_1004.png["AddressPropagation"] image::images/mbc3_1004.png["AddressPropagation"]
A node must connect to a few different peers in order to establish A node must connect to a few different peers in order to establish
@ -580,7 +580,7 @@ using a single +headers+ message. See the illustration in
<<spv_synchronization>>. <<spv_synchronization>>.
[[spv_synchronization]] [[spv_synchronization]]
.Lightweight client synchronizing the block headers .Lightweight client synchronizing the block headers.
image::images/mbc3_1005.png["Header synchronization"] image::images/mbc3_1005.png["Header synchronization"]
Block headers allow a lightweight client to verify that any individual block Block headers allow a lightweight client to verify that any individual block
@ -649,7 +649,7 @@ In <<bloom1>>, we use a very small array of 16 bits and a set of three
hash functions to demonstrate how bloom filters work. hash functions to demonstrate how bloom filters work.
[[bloom1]] [[bloom1]]
.An example of a simplistic bloom filter, with a 16-bit field and three hash functions .An example of a simplistic bloom filter, with a 16-bit field and three hash functions.
image::images/mbc3_1006.png["Bloom1"] image::images/mbc3_1006.png["Bloom1"]
The bloom filter is initialized so that the array of bits is all zeros. The bloom filter is initialized so that the array of bits is all zeros.
@ -680,13 +680,13 @@ array or fewer hash functions will record fewer patterns and produce
less accuracy. less accuracy.
[[bloom2]] [[bloom2]]
.Adding a pattern "A" to our simple bloom filter .Adding a pattern "A" to our simple bloom filter.
image::images/mbc3_1007.png["Bloom2"] image::images/mbc3_1007.png["Bloom2"]
<<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter. <<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter.
[[bloom3]] [[bloom3]]
.Adding a second pattern "B" to our simple bloom filter .Adding a second pattern "B" to our simple bloom filter.
image::images/mbc3_1008.png["Bloom3"] image::images/mbc3_1008.png["Bloom3"]
[role="less_space pagebreak-before"] [role="less_space pagebreak-before"]

12
ch11_blockchain.adoc
View File

@ -354,7 +354,7 @@ 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]]
.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[]
[[merkle_trees]] [[merkle_trees]]
@ -418,7 +418,7 @@ header and summarizes all the data in all four transactions.
of the nodes. of the nodes.
[[simple_merkle]] [[simple_merkle]]
.Calculating the nodes in a merkle tree .Calculating the nodes in a merkle tree.
image::images/mbc3_1102.png["merkle_tree"] image::images/mbc3_1102.png["merkle_tree"]
Because the merkle tree is a binary tree, it needs Because the merkle tree is a binary tree, it needs
@ -430,7 +430,7 @@ Similarly, if there are an odd number of hashes to process at any level,
the last hash is duplicated. the last hash is duplicated.
[[merkle_tree_odd]] [[merkle_tree_odd]]
.Duplicating one data element achieves an even number of data elements .Duplicating one data element achieves an even number of data elements.
image::images/mbc3_1103.png["merkle_tree_odd"] image::images/mbc3_1103.png["merkle_tree_odd"]
.A Design Flaw in Bitcoin's Merkle Tree .A Design Flaw in Bitcoin's Merkle Tree
@ -454,7 +454,7 @@ trees in <<cve_tree>>:
[[cve_tree]] [[cve_tree]]
[role="width-90"] [role="width-90"]
.Two Bitcoin-style merkle trees with the same root but a different number of leaves .Two Bitcoin-style merkle trees with the same root but a different number of leaves.
image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"] image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"]
The transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and The transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and
@ -500,7 +500,7 @@ transaction out of more than a thousand transactions in a multimegabyte
block. block.
[[merkle_tree_large]] [[merkle_tree_large]]
.A merkle tree summarizing many data elements .A merkle tree summarizing many data elements.
image::images/mbc3_1105.png["merkle_tree_large"] image::images/mbc3_1105.png["merkle_tree_large"]
In <<merkle_tree_path>>, a node can prove that a transaction K is In <<merkle_tree_path>>, a node can prove that a transaction K is
@ -515,7 +515,7 @@ H~IJKLMNOP~, and the merkle tree root (outlined in a dashed line in the
diagram). diagram).
[[merkle_tree_path]] [[merkle_tree_path]]
.A merkle path used to prove inclusion of a data element .A merkle path used to prove inclusion of a data element.
image::images/mbc3_1106.png["merkle_tree_path"] image::images/mbc3_1106.png["merkle_tree_path"]
The efficiency of merkle trees becomes obvious as the scale increases. The efficiency of merkle trees becomes obvious as the scale increases.

6
ch12_mining.adoc
View File

@ -120,7 +120,7 @@ miners will be rewarded solely through the transaction fees.
time, as the issuance of currency decreases. time, as the issuance of currency decreases.
[[bitcoin_money_supply]] [[bitcoin_money_supply]]
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate .Supply of bitcoin currency over time based on a geometrically decreasing issuance rate.
image::images/mbc3_1201.png["BitcoinMoneySupply"] image::images/mbc3_1201.png["BitcoinMoneySupply"]
[NOTE] [NOTE]
@ -1683,7 +1683,7 @@ we saw in <<forks>>. With the mining of block 5, the network converges
on one chain and the fork is resolved. on one chain and the fork is resolved.
[[blockchainwithforks]] [[blockchainwithforks]]
.A blockchain with forks .A blockchain with forks.
image::images/mbc3_1202.png[A blockchain with forks] image::images/mbc3_1202.png[A blockchain with forks]
Later, however, at block height 6, Later, however, at block height 6,
@ -2065,7 +2065,7 @@ proposal state changes to +FAILED+, indicating a rejected proposal.
+FAILED+ proposals remain in that state perpetually. +FAILED+ proposals remain in that state perpetually.
[[bip9states]] [[bip9states]]
.BIP9 state transition diagram .BIP9 state transition diagram.
image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram] image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram]
BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+

14
ch14_applications.adoc
View File

@ -444,7 +444,7 @@ else or submitted to the blockchain.
showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions. showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions.
[[payment_channel]] [[payment_channel]]
.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions .A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions.
image::images/mbc3_1401.png["A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions"] image::images/mbc3_1401.png["A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions"]
==== Simple Payment Channel Example ==== Simple Payment Channel Example
@ -470,7 +470,7 @@ Fabian. <<emma_fabian_streaming_video>> shows Emma buying the video
streaming service from Fabian using a payment channel. streaming service from Fabian using a payment channel.
[[emma_fabian_streaming_video]] [[emma_fabian_streaming_video]]
.Emma purchases streaming video from Fabian with a payment channel, paying for each second of video .Emma purchases streaming video from Fabian with a payment channel, paying for each second of video.
image::images/mbc3_1402.png["Emma purchases streaming video from Fabian with a payment channel, paying for each second of video"] image::images/mbc3_1402.png["Emma purchases streaming video from Fabian with a payment channel, paying for each second of video"]
In this example, Fabian and Emma are using special software that handles In this example, Fabian and Emma are using special software that handles
@ -546,7 +546,7 @@ transaction that allocated the final balance correctly between((("payment channe
participants. participants.
[[video_payment_channel]] [[video_payment_channel]]
.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel .Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel.
image::images/mbc3_1403.png["Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel"] image::images/mbc3_1403.png["Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel"]
==== Making Trustless Channels ==== Making Trustless Channels
@ -612,7 +612,7 @@ shorter timelock, allowing it to be spent before the previous
commitments become valid. commitments become valid.
[[timelocked_commitments]] [[timelocked_commitments]]
.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid .Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid.
image::images/mbc3_1404.png["Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid"] image::images/mbc3_1404.png["Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid"]
Each subsequent commitment transaction must have a shorter timelock so Each subsequent commitment transaction must have a shorter timelock so
@ -802,7 +802,7 @@ isn't enough to encourage fair conduct.
where the output paying the holder of the commitment is delayed. where the output paying the holder of the commitment is delayed.
[[asymmetric_commitments]] [[asymmetric_commitments]]
.Two asymmetric commitment transactions with delayed payment for the party holding the transaction .Two asymmetric commitment transactions with delayed payment for the party holding the transaction.
image::images/mbc3_1405.png["Two asymmetric commitment transactions with delayed payment for the party holding the transaction"] image::images/mbc3_1405.png["Two asymmetric commitment transactions with delayed payment for the party holding the transaction"]
Now we introduce the final element of this scheme: a revocation key that Now we introduce the final element of this scheme: a revocation key that
@ -1005,7 +1005,7 @@ capacity of 4 bitcoins in each channel.
to make a payment from Alice to Eric (see <<lightning_network>>). to make a payment from Alice to Eric (see <<lightning_network>>).
[[lightning_network_fig]] [[lightning_network_fig]]
.A series of bidirectional payment channels linked to form an LN that can route a payment from Alice to Eric .A series of bidirectional payment channels linked to form an LN that can route a payment from Alice to Eric.
image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"] image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"]
Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
@ -1019,7 +1019,7 @@ payment from Alice to Eric, through a series of HTLC commitments on the
payment channels connecting the participants. payment channels connecting the participants.
[[ln_payment_process]] [[ln_payment_process]]
.Step-by-step payment routing through an LN .Step-by-step payment routing through an LN.
image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"] image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"]
Alice is running an LN node that is keeping track of Alice is running an LN node that is keeping track of