diff --git a/ch01_intro.adoc b/ch01_intro.adoc index 0fb329af..528244d4 100644 --- a/ch01_intro.adoc +++ b/ch01_intro.adoc @@ -383,7 +383,7 @@ Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_ [role="width-50"] [[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"] 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 <>). [[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"] Joe then carefully checks to make sure he has entered the correct diff --git a/ch02_overview.adoc b/ch02_overview.adoc index ce60d541..c9fdcdfc 100644 --- a/ch02_overview.adoc +++ b/ch02_overview.adoc @@ -89,7 +89,7 @@ TODO: Replace QR code with test-BTC address //// [[invoice-QR]] -.Invoice QR code +.Invoice QR code. image::images/mbc3_0201.png["payment-request"] 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-double-entry]] -.Transaction as double-entry bookkeeping +.Transaction as double-entry bookkeeping. image::images/mbc3_0202.png["Transaction Double-Entry"] ==== Transaction Chains @@ -223,7 +223,7 @@ change. //// [[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"] [TIP] @@ -295,7 +295,7 @@ transaction has one input and two outputs and is shown in <>. [[transaction-common]] -.Most common transaction +.Most common transaction. image::images/mbc3_0204.png["Common Transaction"] 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. [[transaction-consolidating]] -.Consolidation transaction aggregating funds +.Consolidation transaction aggregating funds. image::images/mbc3_0205.png["Aggregating Transaction"] 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. [[transaction-distributing]] -.Batch transaction distributing funds +.Batch transaction distributing funds. image::images/mbc3_0206.png["Distributing Transaction"] === Constructing a Transaction @@ -589,7 +589,7 @@ the process of mining and the way it builds confidence in more ((("bitcoins", "m <>. [[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"] [role="less_space pagebreak-before"] @@ -618,7 +618,7 @@ for a new website page. Now the chain of transactions will look like <>. [[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"] 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 diff --git a/ch03_bitcoin-core.adoc b/ch03_bitcoin-core.adoc index da800537..0c9a46a4 100644 --- a/ch03_bitcoin-core.adoc +++ b/ch03_bitcoin-core.adoc @@ -52,7 +52,7 @@ of Bitcoin peer-to-peer communication. Core. [[bitcoin_core_architecture]] -.Bitcoin Core architecture (Source: Eric Lombrozo) +.Bitcoin Core architecture (Source: Eric Lombrozo). image::images/mbc3_0301.png["Bitcoin Core Architecture"] Although Bitcoin Core serves as a reference implementation for many diff --git a/ch04_keys.adoc b/ch04_keys.adoc index 5540ead5..8a217f82 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving those goals, shown in <>. [[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"] A receiver like Bob @@ -172,7 +172,7 @@ by Bitcoin. [[ecc-curve]] [role="width-50"] -.An elliptic curve +.An elliptic curve. image::images/mbc3_0402.png["ecc-curve"] 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. [[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"] 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]] -.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"] === Output and Input Scripts @@ -432,7 +432,7 @@ better understand why certain features may have been added to the Bitcoin protocol. [[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"] If Alice entered Bob's IP address in Bitcoin 0.1, her full node would @@ -688,7 +688,7 @@ previously. <> illustrates the base58check encoding process. [[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"] ++++ @@ -757,7 +757,7 @@ encoding, <> 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. [[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"] [[comp_pub]] @@ -827,7 +827,7 @@ point. Public key compression is illustrated in <>. [[pubkey_compression]] -.Public key compression +.Public key compression. image::images/mbc3_0408.png["pubkey_compression"] @@ -1113,7 +1113,7 @@ https://oreil.ly/paWIx[bech32 address decoder demo]. <>. [[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"] - 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. <> shows a sample paper wallet. [[paper_wallet_simple]] -.An example of a simple paper wallet +.An example of a simple paper wallet. image::images/mbc3_0410.png[] Some are intended to be given as gifts and have seasonal themes, such as diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index 389b618e..ff2d5261 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -60,7 +60,7 @@ that could only reasonably be backed up using digital media. [[Type0_wallet]] [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"] 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]] [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"] @@ -210,7 +210,7 @@ limit on the depth of the tree. This tree structure is illustrated in <>. [[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"] 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. [[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"] <> shows the relationship between the size of the entropy @@ -859,7 +859,7 @@ described previously in <>: <> shows how a recovery code is used to generate a seed. [[fig_5_7]] -.From recovery code to seed +.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]] -.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"] 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. [[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"] Changing the index allows us to extend the parent and create the other @@ -1284,7 +1284,7 @@ the hardware signing device. <> 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. [[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"] ==== 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]] -.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"] diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index 6fc17aac..7f0b4ec4 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -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. [[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"] [[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 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"] ==== Length of Transaction Input List @@ -575,7 +575,7 @@ maximum relative timelock in both blocks and seconds from 16 bits as defined by BIP68. [[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"] 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 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"] ==== 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]] -.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"] 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. [[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"] [[legacy_serialization]] diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc index 4f5a0358..fa332047 100644 --- a/ch07_authorization-authentication.adoc +++ b/ch07_authorization-authentication.adoc @@ -129,7 +129,7 @@ from the concatenation of the scripts prior((("scripts", "input/output", "constr validation. [[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"] ===== The script execution stack @@ -201,7 +201,7 @@ to know that the number 2 satisfies the script. [[simplemath_script]] -.Bitcoin's script validation doing simple math +.Bitcoin's script validation doing simple math. image::images/mbc3_0702.png["TxScriptSimpleMathExample"] [TIP] @@ -302,11 +302,11 @@ execution of the combined script, which will prove this is a valid transaction. [[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"] [[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"] [[multisig]] @@ -1630,7 +1630,7 @@ from <>, we construct a merkle tree for each of the three authorization conditions in <>. [[diagram_mast1]] -.A MAST with three subscripts +.A MAST with three subscripts. image::images/mbc3_0705.png["A MAST with three sub-scripts"] 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. [[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"] [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]] -.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"] [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]] -.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"] 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]] -.An alternative script tree +.An alternative script tree. image::images/mbc3_0709.png["An alternative script tree"] 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]] -.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"] This makes the mutual satisfaction clause using a multisignature diff --git a/ch10_network.adoc b/ch10_network.adoc index 8ff400fe..85358c3d 100644 --- a/ch10_network.adoc +++ b/ch10_network.adoc @@ -108,7 +108,7 @@ the time between when one miner announces a new block and when other miners receive that block. [[mining_race]] -.A blockchain fork requiring a mining race +.A blockchain fork requiring a mining race. image::images/mbc3_1001.png["Mining race"] 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. [[network_handshake]] -.The initial handshake between peers +.The initial handshake between peers. image::images/mbc3_1003.png["NetworkHandshake"] 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 and discovery +.Address propagation and discovery. image::images/mbc3_1004.png["AddressPropagation"] 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]] -.Lightweight client synchronizing the block headers +.Lightweight client synchronizing the block headers. image::images/mbc3_1005.png["Header synchronization"] Block headers allow a lightweight client to verify that any individual block @@ -649,7 +649,7 @@ In <>, we use a very small array of 16 bits and a set of three hash functions to demonstrate how bloom filters work. [[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"] 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. [[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"] <> is an example of adding a second pattern "B" to the simple bloom filter. [[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"] [role="less_space pagebreak-before"] diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc index 4849bb5d..d124776e 100644 --- a/ch11_blockchain.adoc +++ b/ch11_blockchain.adoc @@ -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. [[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[] [[merkle_trees]] @@ -418,7 +418,7 @@ header and summarizes all the data in all four transactions. of the nodes. [[simple_merkle]] -.Calculating the nodes in a merkle tree +.Calculating the nodes in a merkle tree. image::images/mbc3_1102.png["merkle_tree"] 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. [[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"] .A Design Flaw in Bitcoin's Merkle Tree @@ -454,7 +454,7 @@ trees in <>: [[cve_tree]] [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"] 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. [[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"] In <>, 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). [[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"] The efficiency of merkle trees becomes obvious as the scale increases. diff --git a/ch12_mining.adoc b/ch12_mining.adoc index d0527c9e..905a526f 100644 --- a/ch12_mining.adoc +++ b/ch12_mining.adoc @@ -120,7 +120,7 @@ miners will be rewarded solely through the transaction fees. time, as the issuance of currency decreases. [[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"] [NOTE] @@ -1683,7 +1683,7 @@ we saw in <>. With the mining of block 5, the network converges on one chain and the fork is resolved. [[blockchainwithforks]] -.A blockchain with forks +.A blockchain with forks. image::images/mbc3_1202.png[A blockchain with forks] 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. [[bip9states]] -.BIP9 state transition diagram +.BIP9 state transition diagram. image::images/mbc3_1203.png[BIP9 Proposal State Transition Diagram] BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ diff --git a/ch14_applications.adoc b/ch14_applications.adoc index 71780e04..600aa3e4 100644 --- a/ch14_applications.adoc +++ b/ch14_applications.adoc @@ -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. [[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"] ==== Simple Payment Channel Example @@ -470,7 +470,7 @@ Fabian. <> shows Emma buying the video streaming service from Fabian using a payment channel. [[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"] 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. [[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"] ==== Making Trustless Channels @@ -612,7 +612,7 @@ shorter timelock, allowing it to be spent before the previous commitments become valid. [[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"] 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. [[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"] 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_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"] 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. [[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"] Alice is running an LN node that is keeping track of