mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-22 08:08:11 +00:00
periods in image captions
This commit is contained in:
Clare Laylock
parent
f9b7a6087f
commit
599394a35e
@ -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 <<confirmations>>).
|
||||
|
||||
[[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
|
||||
|
||||
@ -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>>.
|
||||
|
||||
[[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
|
||||
<<mining>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
|
||||
those goals, shown in <<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"]
|
||||
|
||||
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. <<base58check_encoding>> 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, <<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.
|
||||
|
||||
[[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>>.
|
||||
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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. <<paper_wallet_simple>> 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
|
||||
|
||||
@ -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>>.
|
||||
|
||||
[[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"]
|
||||
|
||||
<<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]]
|
||||
.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>>.
|
||||
|
||||
[[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. <<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.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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"]
|
||||
|
||||
|
||||
|
||||
@ -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>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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]]
|
||||
|
||||
@ -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 <<variable_timelock_multisig>>, we construct a merkle tree for each
|
||||
of the three authorization conditions in <<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"]
|
||||
|
||||
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>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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>>.
|
||||
|
||||
[[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
|
||||
|
||||
@ -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>>.
|
||||
|
||||
[[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 <<bloom1>>, 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"]
|
||||
|
||||
<<bloom3>> 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"]
|
||||
|
||||
@ -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>>:
|
||||
|
||||
[[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 <<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).
|
||||
|
||||
[[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.
|
||||
|
||||
@ -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 <<forks>>. 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+
|
||||
|
||||
@ -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. <<emma_fabian_streaming_video>> 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>>).
|
||||
|
||||
[[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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user