diff --git a/appa_whitepaper.adoc b/appa_whitepaper.adoc
index 2ac133e4..81219436 100644
--- a/appa_whitepaper.adoc
+++ b/appa_whitepaper.adoc
@@ -25,7 +25,7 @@ What is needed is an electronic payment system based on cryptographic proof inst
==== Transactions
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
-image::images/mbc2_abin01.png["Transactions"]
+image::images/mbc3_0401.png["Transactions"]
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
@@ -34,12 +34,12 @@ We need a way for the payee to know that the previous owners did not sign any ea
==== Timestamp Server
The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
-image::images/mbc2_abin02.png["timestamp server"]
+image::images/mbc3_aain02.png["timestamp server"]
==== Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
-image::images/mbc2_abin03.png["pow"]
+image::images/mbc3_aain03.png["pow"]
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
@@ -73,28 +73,28 @@ The incentive may help encourage nodes to stay honest. If a greedy attacker is a
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7] [2] [5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.
++++
-image::images/mbc2_abin04.png["disk"]
+image::images/mbc3_aain04.png["disk"]
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, +80 bytes * 6 * 24 * 365 = 4.2MB+ per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
==== Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
-image::images/mbc2_abin05.png["spv"]
+image::images/mbc3_aain05.png["spv"]
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
==== Combining and Splitting Value
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
-image::images/mbc2_abin06.png["combining-splitting"]
+image::images/mbc3_aain06.png["combining-splitting"]
It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history.
==== Privacy
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.
-image::images/mbc2_abin07.png["privacy"]
+image::images/mbc3_aain07.png["privacy"]
As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
diff --git a/ch01_intro.adoc b/ch01_intro.adoc
index d2332b7c..4de8d8a6 100644
--- a/ch01_intro.adoc
+++ b/ch01_intro.adoc
@@ -378,7 +378,7 @@ Alice uses the _Receive_ button, which displays a QR code, shown in <>).
[[wallet-send]]
[role="smallereighty"]
.Bitcoin wallet send screen
-image::images/send.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
amount, because he is about to transmit money and mistakes will soon become
diff --git a/ch02_overview.adoc b/ch02_overview.adoc
index 4c80de05..913dbb48 100644
--- a/ch02_overview.adoc
+++ b/ch02_overview.adoc
@@ -32,7 +32,7 @@ relationships and flows between them.
[[bitcoin-overview]]
.Bitcoin overview
-image::images/mbc2_0201.png["Bitcoin Overview"]
+image::images/mbc3_0201.png["Bitcoin Overview"]
Popular blockchain explorers include:
@@ -97,7 +97,7 @@ TODO: Replace QR code with test-BTC address
[[invoice-QR]]
.Invoice QR code
-image::images/mbc2_0202.png["payment-request"]
+image::images/mbc3_0202.png["payment-request"]
[TIP]
====
@@ -185,7 +185,7 @@ transaction over to a new owner identified by a Bitcoin address.
[[transaction-double-entry]]
.Transaction as double-entry bookkeeping
-image::images/mbc2_0203.png["Transaction Double-Entry"]
+image::images/mbc3_0203.png["Transaction Double-Entry"]
==== Transaction Chains
@@ -231,7 +231,7 @@ change.
[[transaction-chain]]
.A chain of transactions, where the output of one transaction is the input of the next transaction
-image::images/transaction-chain.png["Transaction chain"]
+image::images/mbc3_0204.png["Transaction chain"]
[TIP]
====
@@ -304,7 +304,7 @@ transaction has one input and two outputs and is shown in
[[transaction-common]]
.Most common transaction
-image::images/mbc2_0205.png["Common Transaction"]
+image::images/mbc3_0205.png["Common Transaction"]
Another common form of transaction is a _consolidation transaction_ that spends several inputs
into a single output (<>). This represents
@@ -314,7 +314,7 @@ generated by wallets and businesses to clean up lots of smaller amounts.
[[transaction-consolidating]]
.Consolidation transaction aggregating funds
-image::images/mbc2_0206.png["Aggregating Transaction"]
+image::images/mbc3_0206.png["Aggregating Transaction"]
Finally, another transaction form that is seen often on the
blockchain is _payment batching_ that pays to multiple outputs
@@ -325,7 +325,7 @@ employees.
[[transaction-distributing]]
.Batch transaction distributing funds
-image::images/mbc2_0207.png["Distributing Transaction"]
+image::images/mbc3_0207.png["Distributing Transaction"]
=== Constructing a Transaction
@@ -598,7 +598,7 @@ the process of mining and the way it builds confidence in more detail in
[[block-alice1]]
.Alice's transaction included in a block
-image::images/mbc2_0209.png["Alice's transaction included in a block"]
+image::images/mbc3_0208.png["Alice's transaction included in a block"]
=== Spending the Transaction
@@ -626,7 +626,7 @@ look like <>.
[[block-alice2]]
.Alice's transaction as part of a transaction chain from Joe to Gopesh
-image::images/mbc2_0210.png["Alice's transaction as part of a transaction chain"]
+image::images/mbc3_0209.png["Alice's transaction as part of a transaction chain"]
In this chapter, we saw how transactions build a chain that moves value
from owner to owner. We also tracked Alice's transaction, from the
diff --git a/ch03_bitcoin-core.adoc b/ch03_bitcoin-core.adoc
index 7703ca06..e6d38c17 100644
--- a/ch03_bitcoin-core.adoc
+++ b/ch03_bitcoin-core.adoc
@@ -53,7 +53,7 @@ Core.
[[bitcoin_core_architecture]]
.Bitcoin Core architecture (Source: Eric Lombrozo)
-image::images/mbc2_0301.png["Bitcoin Core Architecture"]
+image::images/mbc3_0301.png["Bitcoin Core Architecture"]
Although Bitcoin Core serves as a reference implementation for many
major parts of the system, the Bitcoin whitepaper describes several
diff --git a/ch04_keys.adoc b/ch04_keys.adoc
index 158aa888..5ac97045 100644
--- a/ch04_keys.adoc
+++ b/ch04_keys.adoc
@@ -20,7 +20,7 @@ that itself commits to Bob's public key and other transaction details.
[[pay-to-pure-pubkey]]
.Transaction chain from original Bitcoin paper
-image::images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"]
+image::images/mbc3_aain01.png["Transaction chain from original Bitcoin paper"]
We'll examine public keys, private keys, signatures, and hash functions
in this chapter, and then use all of them together to describe
@@ -169,7 +169,7 @@ by Bitcoin.
[[ecc-curve]]
[role="smallerthirty"]
.An elliptic curve
-image::images/mbc2_0402.png["ecc-curve"]
+image::images/mbc3_0402.png["ecc-curve"]
Bitcoin uses a specific elliptic curve and set of mathematical
constants, as defined in a standard called +secp256k1+, established by
@@ -210,7 +210,7 @@ more complex pattern of dots on a unfathomably large grid.
[[ecc-over-F17-math]]
[role="smallersixty"]
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
-image::images/mbc2_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
is a point on the +secp256k1+ curve:
@@ -374,7 +374,7 @@ library] to do the elliptic curve math.
[[ecc_illustrated]]
.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve
-image::images/mbc2_0404.png["ecc_illustrated"]
+image::images/mbc3_0404.png["ecc_illustrated"]
=== Output and Input Scripts
@@ -416,7 +416,7 @@ Bitcoin protocol.
[[bitcoin_01_send]]
.Early send screen for Bitcoin via https://web.archive.org/web/20090722011820/https://bitcoin.org/[The Internet Archive]
-image::images/bitcoin-01-send.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
establish a connection with his full node and receive a new public key
@@ -672,7 +672,7 @@ encoding process.
[[base58check_encoding]]
.Base58Check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data
-image::images/mbc2_0406.png["Base58CheckEncoding"]
+image::images/mbc3_0406.png["Base58CheckEncoding"]
In Bitcoin, other data besides public key commitments are presented to the user in
base58check encoding to make that data compact, easy to read, and easy to detect
@@ -705,7 +705,7 @@ into a Bitcoin address in <>.
[[pubkey_to_address]]
.Public key to Bitcoin address: conversion of a public key into a Bitcoin address
-image::images/mbc2_0405.png["pubkey_to_address"]
+image::images/mbc3_0407.png["pubkey_to_address"]
[[comp_pub]]
=== Compressed public keys
@@ -796,7 +796,7 @@ addresses.
[[pubkey_compression]]
[role="smallerseventy"]
.Public key compression
-image::images/mbc2_0407.png["pubkey_compression"]
+image::images/mbc3_0408.png["pubkey_compression"]
Compressed public keys are now the default in almost all Bitcoin
software, and were made required when using certain new features added
@@ -1060,7 +1060,7 @@ https://bitcoin.sipa.be/bech32/demo/demo.html[bech32 address decoder demo].
[[bech32_qrcode_uc_lc]]
.The same bech32 address QR encoded in lowercase and uppercase
-image::images/bech32-qrcode-uc-lc.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
segwit to make it possible for spender wallets to be able to pay
@@ -1650,7 +1650,7 @@ features. <> shows a sample paper wallet.
[[paper_wallet_simple]]
.An example of a simple paper wallet
-image::images/mbc2_0408.png[]
+image::images/mbc3_0410.png[]
Some are intended to be given as gifts and have seasonal themes, such as
Christmas and New Year's themes. Others are designed for storage in a
@@ -1663,7 +1663,7 @@ other natural disasters.
[[paper_wallet_spw]]
.An example of a paper wallet with additional copies of the keys on a backup "stub"
-image::images/mbc2_0412.png[]
+image::images/mbc3_0411.png[]
From the original public-key focused design of Bitcoin to modern addresses
and scripts like bech32m and pay-to-taproot--and even addresses for
diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc
index 28028688..a414e052 100644
--- a/ch05_wallets.adoc
+++ b/ch05_wallets.adoc
@@ -57,7 +57,7 @@ that could only reasonably be backed up using digital media.
[[Type0_wallet]]
[role="smallersixty"]
.Non-deterministic key generation: a collection of independently generated keys stored in a wallet database
-image::images/mbc2_0501.png["Non-Deterministic Wallet"]
+image::images/mbc3_0501.png["Non-Deterministic Wallet"]
Modern wallet applications don't independently generate keys but instead
derive them from a single random seed using a repeatable (deterministic)
@@ -113,7 +113,7 @@ possible to store private keys more securely than public keys.
[[Type1_wallet]]
[role="smallersixty"]
.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
-image::images/mbc2_0502.png["Deterministic Wallet"]
+image::images/mbc3_0502.png["Deterministic Wallet"]
[[public_child_key_derivation]]
==== Public Child Key Derivation
@@ -198,7 +198,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
-image::images/mbc2_0503.png["HD wallet"]
+image::images/mbc3_0503.png["HD wallet"]
The tree structure can be used to express additional
organizational meaning, such as when a specific branch of subkeys is
@@ -681,7 +681,7 @@ generate a BIP39 recovery code.
[[generating_entropy_and_encoding]]
[role="smallerseventy"]
.Generating entropy and encoding as a recovery code
-image::images/mbc2_0506.png["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
data and the length of recovery code in words.
@@ -738,7 +738,7 @@ described previously in <>:
[[fig_5_7]]
.From recovery code to seed
-image::images/mbc2_0507.png["From recovery code to seed"]
+image::images/mbc3_0505.png["From recovery code to seed"]
[TIP]
====
@@ -915,7 +915,7 @@ wallet is shown in <>.
[[HDWalletFromSeed]]
.Creating master keys and chain code from a root seed
-image::images/mbc2_0509.png["HDWalletFromRootSeed"]
+image::images/mbc3_0506.png["HDWalletFromRootSeed"]
The root seed is input into the HMAC-SHA512 algorithm and the resulting
hash is used to create a _master private key_ (m) and a _master chain
@@ -961,7 +961,7 @@ parent.
[[CKDpriv]]
.Extending a parent private key to create a child private key
-image::images/mbc2_0510.png["ChildPrivateDerivation"]
+image::images/mbc3_0507.png["ChildPrivateDerivation"]
Changing the index allows us to extend the parent and create the other
children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each
@@ -1138,7 +1138,7 @@ mechanism for extending a parent public key to derive child public keys.
[[CKDpub]]
.Extending a parent public key to create a child public key
-image::images/mbc2_0511.png["ChildPublicDerivation"]
+image::images/mbc3_0508.png["ChildPublicDerivation"]
==== Using an Extended Public Key on a Web Store
@@ -1189,7 +1189,7 @@ never export private keys--those always remain on the device.
[[export_xpub]]
.Exporting an xpub from a Trezor hardware signing device
-image::images/mbc2_0512.png["Exporting the xpub from the Trezor"]
+image::images/mbc3_0509.png["Exporting the xpub from the Trezor"]
Gabriel copies the xpub to his web store's Bitcoin payment processing
software, such as the widely used open source BTCPay Server.
@@ -1219,7 +1219,7 @@ parent public key, as shown in the diagram in <>.
[[CKDprime]]
.Hardened derivation of a child key; omits the parent public key
-image::images/mbc2_0513.png["ChildHardPrivateDerivation"]
+image::images/mbc3_0510.png["ChildHardPrivateDerivation"]
[role="pagebreak-before"]
When the hardened private derivation function is used, the resulting
diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc
index bcbbf3a3..ffcf86ee 100644
--- a/ch06_transactions.adoc
+++ b/ch06_transactions.adoc
@@ -84,7 +84,7 @@ in the transaction and describe any additional fields that they contain.
[[alice_tx_byte_map]]
.A byte map of Alice's transaction
-image::images/tx-map-1.png["A byte map of Alice's transaction"]
+image::images/mbc3_0601.png["A byte map of Alice's transaction"]
[[version]]
=== Version
@@ -178,7 +178,7 @@ map of those bytes in <>.
[[alice_tx_input_map]]
.Map of bytes in the input field of Alice's transaction
-image::images/input-byte-map.png["map of bytes in the input field of Alice's transaction"]
+image::images/mbc3_0602.png["map of bytes in the input field of Alice's transaction"]
==== Length of transaction input list
@@ -544,7 +544,7 @@ as defined by BIP68.
[[bip_68_def_of_nseq]]
.BIP68 definition of sequence encoding (Source: BIP68)
-image::images/mbc2_0701.png["BIP68 definition of sequence encoding"]
+image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
Note that any transaction which sets a relative timelock using sequence
also sends the signal for opt-in replace-by-fee as described in
@@ -560,7 +560,7 @@ a map of those bytes in <>.
[[output-byte-map]]
.A byte map of the outputs field from Alice's transaction
-image::images/output-byte-map.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
@@ -970,7 +970,7 @@ Alice's transaction in <>:
[[alice_tx_witness_map]]
.A byte map of the witness structure from Alice's transaction
-image::images/witness-byte-map.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
start with any indication of the total number of witness stacks it contains.
@@ -1152,7 +1152,7 @@ the difference in size between the various fields in the two images.
[[alice_tx_weight_map]]
.A byte map of Alice's transaction
-image::images/tx-weight-map.png["A weight map of Alice's transaction"]
+image::images/mbc3_0606.png["A weight map of Alice's transaction"]
[[legacy_serialization]]
=== Legacy Serialization
diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc
index bfec3f81..2dfd71eb 100644
--- a/ch07_authorization-authentication.adoc
+++ b/ch07_authorization-authentication.adoc
@@ -131,7 +131,7 @@ validation.
[[input_and_output_scripts_legacy]]
.Combining input and output scripts to evaluate a transaction script
-image::images/mbc2_0603.png["input_and_output_scripts"]
+image::images/mbc3_0701.png["input_and_output_scripts"]
===== The script execution stack
@@ -216,7 +216,7 @@ Wiki's script page].
[[simplemath_script]]
.Bitcoin's script validation doing simple math
-image::images/mbc2_0604.png["TxScriptSimpleMathExample"]
+image::images/mbc3_0702.png["TxScriptSimpleMathExample"]
[role="pagebreak-before"]
The following is a slightly more complex script, which calculates
@@ -302,11 +302,11 @@ transaction.
[[P2PubKHash1]]
.Evaluating a script for a P2PKH transaction (part 1 of 2)
-image::images/mbc2_0605.png["Tx_Script_P2PubKeyHash_1"]
+image::images/mbc3_0703.png["Tx_Script_P2PubKeyHash_1"]
[[P2PubKHash2]]
.Evaluating a script for a P2PKH transaction (part 2 of 2)
-image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
+image::images/mbc3_0704.png["Tx_Script_P2PubKeyHash_2"]
[[multisig]]
=== Scripted multisignatures
@@ -1615,7 +1615,7 @@ of the three authorization conditions in <>.
[[diagram_mast1]]
.A MAST with three sub-scripts
-image::images/mast1.dot.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
authorization condition is a member of the merkle tree without
@@ -1626,7 +1626,7 @@ specified at spend time.
[[diagram_mast2]]
.A MAST membership proof for one of the sub-scripts
-image::images/mast2.dot.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"]
The hash digests used to create the commitments are each 32-bytes, so
proving the above spend is authorized (using a merkle tree and the
@@ -1657,7 +1657,7 @@ our tree with this knowledge in <>.
[[diagram_mast3]]
.A MAST with the most-expected script in the best position
-image::images/mast3.dot.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"]
Now we only need to provide two commitments for the common case (saving 32
bytes), although we still need three commitments for the less common cases.
@@ -1686,7 +1686,7 @@ every condition in a script creates a new branch, as show in <>.
[[ast]]
.An Abstract Syntax Tree (AST) for a script
-image::images/ast.dot.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
programs, such as compilers. A merklized AST would commit to every part
@@ -1703,7 +1703,7 @@ them alternatives for each other, as shown in <>.
[[alt_script]]
.An alternative script tree
-image::images/alt_script.dot.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
each level of depth between the spender's chosen script and the root of
@@ -1882,7 +1882,7 @@ involving both a public key and a MAST is shown in <>.
[[diagram_taproot1]]
.A taproot with the public key committing to a merkle root
-image::images/taproot1.dot.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
extremely efficient and very private. It's even more private than it
diff --git a/ch10_network.adoc b/ch10_network.adoc
index abb7d3d0..7289a77b 100644
--- a/ch10_network.adoc
+++ b/ch10_network.adoc
@@ -107,7 +107,7 @@ miners receive that block.
[[mining_race]]
.A blockchain fork requiring a mining race
-image::images/race1.dot.png["Mining race"]
+image::images/mbc3_1001.png["Mining race"]
In 2015, a new version of Bitcoin Core added a feature called
_compact block relay_ (specified in BIP152) that allows transferring new
@@ -176,7 +176,7 @@ quickly announcing blocks).
// released into the public domain by Nicolas Dorier
[[bip152_illustration]]
.BIP152 modes compared (from BIP152). They grey bar indicates the time it takes the node to validate the block
-image::images/bip152.png["BIP152"]
+image::images/mbc3_1002.png["BIP152"]
The names of the two methods (which are taken from BIP152) can be a bit
confusing. Low-bandwidth mode saves bandwidth by not sending blocks in
@@ -305,7 +305,7 @@ use the newly discovered peers.
[[network_handshake]]
.The initial handshake between peers
-image::images/mbc2_0804.png["NetworkHandshake"]
+image::images/mbc3_1003.png["NetworkHandshake"]
Once one or more connections are established, the new node will send an
+addr+ message containing its own IP address to its neighbors. The
@@ -320,7 +320,7 @@ existence on the network for other nodes to find it.
[[address_propagation]]
.Address propagation and discovery
-image::images/mbc2_0805.png["AddressPropagation"]
+image::images/mbc3_1004.png["AddressPropagation"]
A node must connect to a few different peers in order to establish
diverse paths into the Bitcoin network. Paths are not reliable—nodes
@@ -578,7 +578,7 @@ using a single +headers+ message. See the illustration in
[[spv_synchronization]]
.Lightweight client synchronizing the block headers
-image::images/mbc2_0807.png["Header synchronization"]
+image::images/mbc3_1005.png["Header synchronization"]
Block headers allow a lightweight client to verify that any individual block
belongs to the blockchain with the most proof of work, but they don't
@@ -647,7 +647,7 @@ 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
-image::images/mbc2_0808.png["Bloom1"]
+image::images/mbc3_1006.png["Bloom1"]
The bloom filter is initialized so that the array of bits is all zeros.
To add a pattern to the bloom filter, the pattern is hashed by each hash
@@ -678,14 +678,14 @@ less accuracy.
[[bloom2]]
.Adding a pattern "A" to our simple bloom filter
-image::images/mbc2_0809.png["Bloom2"]
+image::images/mbc3_1007.png["Bloom2"]
<> is an example of adding a second pattern "B" to the simple bloom filter.
[[bloom3]]
[role="smallereighty"]
.Adding a second pattern "B" to our simple bloom filter
-image::images/mbc2_0810.png["Bloom3"]
+image::images/mbc3_1008.png["Bloom3"]
To test if a pattern is part of a bloom filter, the pattern is hashed by
each hash function and the resulting bit pattern is tested against the
@@ -702,7 +702,7 @@ pattern is probably a match.
[[bloom4]]
[role="smallereighty"]
.Testing the existence of pattern "X" in the bloom filter. The result is a probabilistic positive match, meaning "Maybe."
-image::images/mbc2_0811.png["Bloom4"]
+image::images/mbc3_1009.png["Bloom4"]
On the contrary, if a pattern is tested against the bloom filter and any
one of the bits is set to +0+, this proves that the pattern was not
@@ -716,7 +716,7 @@ pattern is definitely not a match.
[[bloom5]]
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
-image::images/mbc2_0812.png[]
+image::images/mbc3_1010.png[]
=== How Lightweight Clients Use Bloom Filters
diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc
index 44f757e7..6b6dcf12 100644
--- a/ch11_blockchain.adoc
+++ b/ch11_blockchain.adoc
@@ -295,7 +295,7 @@ references in the +previousblockhash+ field.
[[chain_of_blocks]]
[role="smallerfourtyfive"]
.Blocks linked in a chain by each referencing the previous block header hash
-image::images/mbc2_0901.png[]
+image::images/mbc3_1101.png[]
[[merkle_trees]]
=== Merkle Trees
@@ -359,7 +359,7 @@ of the nodes.
[[simple_merkle]]
.Calculating the nodes in a merkle tree
-image::images/mbc2_0902.png["merkle_tree"]
+image::images/mbc3_1102.png["merkle_tree"]
Because the merkle tree is a binary tree, it needs
an even number of leaf nodes. If there is an odd number of transactions
@@ -371,7 +371,7 @@ the last hash is duplicated.
[[merkle_tree_odd]]
.Duplicating one data element achieves an even number of data elements
-image::images/mbc2_0903.png["merkle_tree_odd"]
+image::images/mbc3_1103.png["merkle_tree_odd"]
.A design flaw in Bitcoin's merkle tree
****
@@ -394,7 +394,7 @@ trees:
[[cve_tree]]
.Two Bitcoin-style merkle tree with the same root but a different number of leaves
-image::images/cve-2012-2459.dot.png["Two Bitcoin-style merkle tree with the same root but a different number of leaves"]
+image::images/mbc3_1104.png["Two Bitcoin-style merkle tree with the same root but a different number of leaves"]
For transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and
6 are repeated) result in the same root hash A (because the hash of both
@@ -439,7 +439,7 @@ block.
[[merkle_tree_large]]
.A merkle tree summarizing many data elements
-image::images/mbc2_0904.png["merkle_tree_large"]
+image::images/mbc3_1105.png["merkle_tree_large"]
In <>, a node can prove that a transaction K is
included in the block by producing a merkle path that is only four
@@ -454,7 +454,7 @@ diagram).
[[merkle_tree_path]]
.A merkle path used to prove inclusion of a data element
-image::images/mbc2_0905.png["merkle_tree_path"]
+image::images/mbc3_1106.png["merkle_tree_path"]
The efficiency of merkle trees becomes obvious as the scale increases.
The largest possible block can hold almost 16,000 transactions in 4,000,000
diff --git a/ch12_mining.adoc b/ch12_mining.adoc
index 75f3979a..78f9e96c 100644
--- a/ch12_mining.adoc
+++ b/ch12_mining.adoc
@@ -121,7 +121,7 @@ time, as the issuance of currency decreases.
[[bitcoin_money_supply]]
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
-image::images/mbc2_1001.png["BitcoinMoneySupply"]
+image::images/mbc3_1201.png["BitcoinMoneySupply"]
[NOTE]
====
@@ -1575,7 +1575,7 @@ on one chain and the fork is resolved.
[[blockchainwithforks]]
.A blockchain with forks
-image::images/fork.dot.png[A blockchain with forks]
+image::images/mbc3_1202.png[A blockchain with forks]
Later, however, at block height 6,
a new implementation of the client is released with a change in the
@@ -1958,7 +1958,7 @@ proposal state changes to +FAILED+, indicating a rejected proposal.
[[bip9states]]
.BIP9 state transition diagram
-image::images/mbc2_1010.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+
and associated BIPs (68, 112, 113). The proposal named "csv" was
diff --git a/ch14_applications.adoc b/ch14_applications.adoc
index 8d76eb04..1297f638 100644
--- a/ch14_applications.adoc
+++ b/ch14_applications.adoc
@@ -442,7 +442,7 @@ showing the funding, commitment, and settlement transactions.
[[payment_channel]]
.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions
-image::images/mbc2_1204.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
@@ -468,7 +468,7 @@ 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
-image::images/mbc2_1205.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
both the payment channel and the video streaming. Emma is running the
@@ -544,7 +544,7 @@ participants.
[[video_payment_channel]]
.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
-image::images/mbc2_1206.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
@@ -609,7 +609,7 @@ commitments become valid.
[[timelocked_commitments]]
.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid
-image::images/mbc2_1207.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
that it may be broadcast before its predecessors and before the refund
@@ -798,7 +798,7 @@ 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
-image::images/mbc2_1208.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
prevents a cheater from broadcasting an expired commitment. The
@@ -999,7 +999,7 @@ to make a payment from Alice to Eric (<>).
[[lightning_network_fig]]
.A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric
-image::images/mbc2_1209.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
Eric by a payment channel. Creating a payment channel requires a funding
@@ -1013,7 +1013,7 @@ payment channels connecting the participants.
[[ln_payment_process]]
.Step-by-step payment routing through a Lightning Network
-image::images/mbc2_1210.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 a Lightning Network (LN) node that is keeping track of
her payment channel to Bob and has the ability to discover routes
diff --git a/figs/incoming/mbc3_0101.png b/figs/incoming/mbc3_0101.png
new file mode 100644
index 00000000..e16b32cc
Binary files /dev/null and b/figs/incoming/mbc3_0101.png differ
diff --git a/figs/incoming/mbc3_0102.png b/figs/incoming/mbc3_0102.png
new file mode 100644
index 00000000..74c3cd44
Binary files /dev/null and b/figs/incoming/mbc3_0102.png differ
diff --git a/figs/incoming/mbc3_0201.png b/figs/incoming/mbc3_0201.png
new file mode 100755
index 00000000..cc054cf4
Binary files /dev/null and b/figs/incoming/mbc3_0201.png differ
diff --git a/figs/incoming/mbc3_0202.png b/figs/incoming/mbc3_0202.png
new file mode 100755
index 00000000..126f6fbe
Binary files /dev/null and b/figs/incoming/mbc3_0202.png differ
diff --git a/figs/incoming/mbc3_0203.png b/figs/incoming/mbc3_0203.png
new file mode 100755
index 00000000..38c0b642
Binary files /dev/null and b/figs/incoming/mbc3_0203.png differ
diff --git a/figs/incoming/mbc3_0204.png b/figs/incoming/mbc3_0204.png
new file mode 100644
index 00000000..21290c33
Binary files /dev/null and b/figs/incoming/mbc3_0204.png differ
diff --git a/figs/incoming/mbc3_0205.png b/figs/incoming/mbc3_0205.png
new file mode 100755
index 00000000..8e52f7dc
Binary files /dev/null and b/figs/incoming/mbc3_0205.png differ
diff --git a/figs/incoming/mbc3_0206.png b/figs/incoming/mbc3_0206.png
new file mode 100755
index 00000000..d3859104
Binary files /dev/null and b/figs/incoming/mbc3_0206.png differ
diff --git a/figs/incoming/mbc3_0207.png b/figs/incoming/mbc3_0207.png
new file mode 100755
index 00000000..793be129
Binary files /dev/null and b/figs/incoming/mbc3_0207.png differ
diff --git a/figs/incoming/mbc3_0208.png b/figs/incoming/mbc3_0208.png
new file mode 100755
index 00000000..46c66445
Binary files /dev/null and b/figs/incoming/mbc3_0208.png differ
diff --git a/figs/incoming/mbc3_0209.png b/figs/incoming/mbc3_0209.png
new file mode 100755
index 00000000..b77ce4e6
Binary files /dev/null and b/figs/incoming/mbc3_0209.png differ
diff --git a/figs/incoming/mbc3_0301.png b/figs/incoming/mbc3_0301.png
new file mode 100755
index 00000000..b3813f21
Binary files /dev/null and b/figs/incoming/mbc3_0301.png differ
diff --git a/figs/incoming/mbc3_0401.png b/figs/incoming/mbc3_0401.png
new file mode 100755
index 00000000..4e3a76d3
Binary files /dev/null and b/figs/incoming/mbc3_0401.png differ
diff --git a/figs/incoming/mbc3_0402.png b/figs/incoming/mbc3_0402.png
new file mode 100755
index 00000000..88a7484d
Binary files /dev/null and b/figs/incoming/mbc3_0402.png differ
diff --git a/figs/incoming/mbc3_0403.png b/figs/incoming/mbc3_0403.png
new file mode 100755
index 00000000..23a1e1cc
Binary files /dev/null and b/figs/incoming/mbc3_0403.png differ
diff --git a/figs/incoming/mbc3_0404.png b/figs/incoming/mbc3_0404.png
new file mode 100755
index 00000000..0915b66a
Binary files /dev/null and b/figs/incoming/mbc3_0404.png differ
diff --git a/figs/incoming/mbc3_0405.png b/figs/incoming/mbc3_0405.png
new file mode 100644
index 00000000..61cc270e
Binary files /dev/null and b/figs/incoming/mbc3_0405.png differ
diff --git a/figs/incoming/mbc3_0406.png b/figs/incoming/mbc3_0406.png
new file mode 100755
index 00000000..c3d0ba52
Binary files /dev/null and b/figs/incoming/mbc3_0406.png differ
diff --git a/figs/incoming/mbc3_0407.png b/figs/incoming/mbc3_0407.png
new file mode 100755
index 00000000..f4474c0d
Binary files /dev/null and b/figs/incoming/mbc3_0407.png differ
diff --git a/figs/incoming/mbc3_0408.png b/figs/incoming/mbc3_0408.png
new file mode 100755
index 00000000..47a13db4
Binary files /dev/null and b/figs/incoming/mbc3_0408.png differ
diff --git a/figs/incoming/mbc3_0409.png b/figs/incoming/mbc3_0409.png
new file mode 100644
index 00000000..b3a4db04
Binary files /dev/null and b/figs/incoming/mbc3_0409.png differ
diff --git a/figs/incoming/mbc3_0410.png b/figs/incoming/mbc3_0410.png
new file mode 100755
index 00000000..b5e3e963
Binary files /dev/null and b/figs/incoming/mbc3_0410.png differ
diff --git a/figs/incoming/mbc3_0411.png b/figs/incoming/mbc3_0411.png
new file mode 100755
index 00000000..d5ab60d7
Binary files /dev/null and b/figs/incoming/mbc3_0411.png differ
diff --git a/figs/incoming/mbc3_0501.png b/figs/incoming/mbc3_0501.png
new file mode 100755
index 00000000..8613d133
Binary files /dev/null and b/figs/incoming/mbc3_0501.png differ
diff --git a/figs/incoming/mbc3_0502.png b/figs/incoming/mbc3_0502.png
new file mode 100755
index 00000000..74e6be24
Binary files /dev/null and b/figs/incoming/mbc3_0502.png differ
diff --git a/figs/incoming/mbc3_0503.png b/figs/incoming/mbc3_0503.png
new file mode 100755
index 00000000..f5959d52
Binary files /dev/null and b/figs/incoming/mbc3_0503.png differ
diff --git a/figs/incoming/mbc3_0504.png b/figs/incoming/mbc3_0504.png
new file mode 100755
index 00000000..b65a9038
Binary files /dev/null and b/figs/incoming/mbc3_0504.png differ
diff --git a/figs/incoming/mbc3_0505.png b/figs/incoming/mbc3_0505.png
new file mode 100644
index 00000000..0c13fe83
Binary files /dev/null and b/figs/incoming/mbc3_0505.png differ
diff --git a/figs/incoming/mbc3_0506.png b/figs/incoming/mbc3_0506.png
new file mode 100644
index 00000000..8bdd4cb0
Binary files /dev/null and b/figs/incoming/mbc3_0506.png differ
diff --git a/figs/incoming/mbc3_0507.png b/figs/incoming/mbc3_0507.png
new file mode 100755
index 00000000..5c9eb2e1
Binary files /dev/null and b/figs/incoming/mbc3_0507.png differ
diff --git a/figs/incoming/mbc3_0508.png b/figs/incoming/mbc3_0508.png
new file mode 100644
index 00000000..bfdd82c3
Binary files /dev/null and b/figs/incoming/mbc3_0508.png differ
diff --git a/figs/incoming/mbc3_0509.png b/figs/incoming/mbc3_0509.png
new file mode 100755
index 00000000..a0d524d0
Binary files /dev/null and b/figs/incoming/mbc3_0509.png differ
diff --git a/figs/incoming/mbc3_0510.png b/figs/incoming/mbc3_0510.png
new file mode 100755
index 00000000..26d6f223
Binary files /dev/null and b/figs/incoming/mbc3_0510.png differ
diff --git a/figs/incoming/mbc3_0601.png b/figs/incoming/mbc3_0601.png
new file mode 100644
index 00000000..fec2399a
Binary files /dev/null and b/figs/incoming/mbc3_0601.png differ
diff --git a/figs/incoming/mbc3_0602.png b/figs/incoming/mbc3_0602.png
new file mode 100644
index 00000000..d88a1835
Binary files /dev/null and b/figs/incoming/mbc3_0602.png differ
diff --git a/figs/incoming/mbc3_0603.png b/figs/incoming/mbc3_0603.png
new file mode 100755
index 00000000..6bab9362
Binary files /dev/null and b/figs/incoming/mbc3_0603.png differ
diff --git a/figs/incoming/mbc3_0604.png b/figs/incoming/mbc3_0604.png
new file mode 100644
index 00000000..8badcdb6
Binary files /dev/null and b/figs/incoming/mbc3_0604.png differ
diff --git a/figs/incoming/mbc3_0605.png b/figs/incoming/mbc3_0605.png
new file mode 100644
index 00000000..7117c815
Binary files /dev/null and b/figs/incoming/mbc3_0605.png differ
diff --git a/figs/incoming/mbc3_0606.png b/figs/incoming/mbc3_0606.png
new file mode 100644
index 00000000..6d53942c
Binary files /dev/null and b/figs/incoming/mbc3_0606.png differ
diff --git a/figs/incoming/mbc3_0701.png b/figs/incoming/mbc3_0701.png
new file mode 100644
index 00000000..5cadba5d
Binary files /dev/null and b/figs/incoming/mbc3_0701.png differ
diff --git a/figs/incoming/mbc3_0702.png b/figs/incoming/mbc3_0702.png
new file mode 100755
index 00000000..f3479abf
Binary files /dev/null and b/figs/incoming/mbc3_0702.png differ
diff --git a/figs/incoming/mbc3_0703.png b/figs/incoming/mbc3_0703.png
new file mode 100755
index 00000000..513ec136
Binary files /dev/null and b/figs/incoming/mbc3_0703.png differ
diff --git a/figs/incoming/mbc3_0704.png b/figs/incoming/mbc3_0704.png
new file mode 100755
index 00000000..42bfe298
Binary files /dev/null and b/figs/incoming/mbc3_0704.png differ
diff --git a/figs/incoming/mbc3_0705.png b/figs/incoming/mbc3_0705.png
new file mode 100644
index 00000000..7b4f8953
Binary files /dev/null and b/figs/incoming/mbc3_0705.png differ
diff --git a/figs/incoming/mbc3_0706.png b/figs/incoming/mbc3_0706.png
new file mode 100644
index 00000000..ba4dd840
Binary files /dev/null and b/figs/incoming/mbc3_0706.png differ
diff --git a/figs/incoming/mbc3_0707.png b/figs/incoming/mbc3_0707.png
new file mode 100644
index 00000000..6034d6c8
Binary files /dev/null and b/figs/incoming/mbc3_0707.png differ
diff --git a/figs/incoming/mbc3_0708.png b/figs/incoming/mbc3_0708.png
new file mode 100644
index 00000000..e5b11ce2
Binary files /dev/null and b/figs/incoming/mbc3_0708.png differ
diff --git a/figs/incoming/mbc3_0709.png b/figs/incoming/mbc3_0709.png
new file mode 100644
index 00000000..80c97f0e
Binary files /dev/null and b/figs/incoming/mbc3_0709.png differ
diff --git a/figs/incoming/mbc3_0710.png b/figs/incoming/mbc3_0710.png
new file mode 100644
index 00000000..39895f66
Binary files /dev/null and b/figs/incoming/mbc3_0710.png differ
diff --git a/figs/incoming/mbc3_1001.png b/figs/incoming/mbc3_1001.png
new file mode 100644
index 00000000..f638a71d
Binary files /dev/null and b/figs/incoming/mbc3_1001.png differ
diff --git a/figs/incoming/mbc3_1002.png b/figs/incoming/mbc3_1002.png
new file mode 100644
index 00000000..0d2b07d3
Binary files /dev/null and b/figs/incoming/mbc3_1002.png differ
diff --git a/figs/incoming/mbc3_1003.png b/figs/incoming/mbc3_1003.png
new file mode 100755
index 00000000..54623efd
Binary files /dev/null and b/figs/incoming/mbc3_1003.png differ
diff --git a/figs/incoming/mbc3_1004.png b/figs/incoming/mbc3_1004.png
new file mode 100755
index 00000000..a6117153
Binary files /dev/null and b/figs/incoming/mbc3_1004.png differ
diff --git a/figs/incoming/mbc3_1005.png b/figs/incoming/mbc3_1005.png
new file mode 100755
index 00000000..cd323cb7
Binary files /dev/null and b/figs/incoming/mbc3_1005.png differ
diff --git a/figs/incoming/mbc3_1006.png b/figs/incoming/mbc3_1006.png
new file mode 100755
index 00000000..d971ef18
Binary files /dev/null and b/figs/incoming/mbc3_1006.png differ
diff --git a/figs/incoming/mbc3_1007.png b/figs/incoming/mbc3_1007.png
new file mode 100755
index 00000000..5852da89
Binary files /dev/null and b/figs/incoming/mbc3_1007.png differ
diff --git a/figs/incoming/mbc3_1008.png b/figs/incoming/mbc3_1008.png
new file mode 100755
index 00000000..dc873c84
Binary files /dev/null and b/figs/incoming/mbc3_1008.png differ
diff --git a/figs/incoming/mbc3_1009.png b/figs/incoming/mbc3_1009.png
new file mode 100755
index 00000000..0fcb8343
Binary files /dev/null and b/figs/incoming/mbc3_1009.png differ
diff --git a/figs/incoming/mbc3_1010.png b/figs/incoming/mbc3_1010.png
new file mode 100755
index 00000000..8324a5a6
Binary files /dev/null and b/figs/incoming/mbc3_1010.png differ
diff --git a/figs/incoming/mbc3_1101.png b/figs/incoming/mbc3_1101.png
new file mode 100755
index 00000000..989d5003
Binary files /dev/null and b/figs/incoming/mbc3_1101.png differ
diff --git a/figs/incoming/mbc3_1102.png b/figs/incoming/mbc3_1102.png
new file mode 100755
index 00000000..bdb92117
Binary files /dev/null and b/figs/incoming/mbc3_1102.png differ
diff --git a/figs/incoming/mbc3_1103.png b/figs/incoming/mbc3_1103.png
new file mode 100755
index 00000000..e3873490
Binary files /dev/null and b/figs/incoming/mbc3_1103.png differ
diff --git a/figs/incoming/mbc3_1104.png b/figs/incoming/mbc3_1104.png
new file mode 100644
index 00000000..a61f33f9
Binary files /dev/null and b/figs/incoming/mbc3_1104.png differ
diff --git a/figs/incoming/mbc3_1105.png b/figs/incoming/mbc3_1105.png
new file mode 100755
index 00000000..9ede1979
Binary files /dev/null and b/figs/incoming/mbc3_1105.png differ
diff --git a/figs/incoming/mbc3_1106.png b/figs/incoming/mbc3_1106.png
new file mode 100755
index 00000000..c9bbd868
Binary files /dev/null and b/figs/incoming/mbc3_1106.png differ
diff --git a/figs/incoming/mbc3_1201.png b/figs/incoming/mbc3_1201.png
new file mode 100755
index 00000000..93511ea7
Binary files /dev/null and b/figs/incoming/mbc3_1201.png differ
diff --git a/figs/incoming/mbc3_1202.png b/figs/incoming/mbc3_1202.png
new file mode 100644
index 00000000..7d78b2b9
Binary files /dev/null and b/figs/incoming/mbc3_1202.png differ
diff --git a/figs/incoming/mbc3_1203.png b/figs/incoming/mbc3_1203.png
new file mode 100755
index 00000000..1ad258bd
Binary files /dev/null and b/figs/incoming/mbc3_1203.png differ
diff --git a/figs/incoming/mbc3_1401.png b/figs/incoming/mbc3_1401.png
new file mode 100755
index 00000000..7d197182
Binary files /dev/null and b/figs/incoming/mbc3_1401.png differ
diff --git a/figs/incoming/mbc3_1402.png b/figs/incoming/mbc3_1402.png
new file mode 100755
index 00000000..877b4448
Binary files /dev/null and b/figs/incoming/mbc3_1402.png differ
diff --git a/figs/incoming/mbc3_1403.png b/figs/incoming/mbc3_1403.png
new file mode 100755
index 00000000..5dc7d260
Binary files /dev/null and b/figs/incoming/mbc3_1403.png differ
diff --git a/figs/incoming/mbc3_1404.png b/figs/incoming/mbc3_1404.png
new file mode 100755
index 00000000..9925a086
Binary files /dev/null and b/figs/incoming/mbc3_1404.png differ
diff --git a/figs/incoming/mbc3_1405.png b/figs/incoming/mbc3_1405.png
new file mode 100755
index 00000000..2b5c23f3
Binary files /dev/null and b/figs/incoming/mbc3_1405.png differ
diff --git a/figs/incoming/mbc3_1406.png b/figs/incoming/mbc3_1406.png
new file mode 100755
index 00000000..4a84950a
Binary files /dev/null and b/figs/incoming/mbc3_1406.png differ
diff --git a/figs/incoming/mbc3_1407.png b/figs/incoming/mbc3_1407.png
new file mode 100755
index 00000000..385224ee
Binary files /dev/null and b/figs/incoming/mbc3_1407.png differ
diff --git a/figs/incoming/mbc3_aain01.png b/figs/incoming/mbc3_aain01.png
new file mode 100755
index 00000000..4e3a76d3
Binary files /dev/null and b/figs/incoming/mbc3_aain01.png differ
diff --git a/figs/incoming/mbc3_aain02.png b/figs/incoming/mbc3_aain02.png
new file mode 100755
index 00000000..0672636c
Binary files /dev/null and b/figs/incoming/mbc3_aain02.png differ
diff --git a/figs/incoming/mbc3_aain03.png b/figs/incoming/mbc3_aain03.png
new file mode 100755
index 00000000..af57bcd9
Binary files /dev/null and b/figs/incoming/mbc3_aain03.png differ
diff --git a/figs/incoming/mbc3_aain04.png b/figs/incoming/mbc3_aain04.png
new file mode 100755
index 00000000..6f63e066
Binary files /dev/null and b/figs/incoming/mbc3_aain04.png differ
diff --git a/figs/incoming/mbc3_aain05.png b/figs/incoming/mbc3_aain05.png
new file mode 100755
index 00000000..62f29fea
Binary files /dev/null and b/figs/incoming/mbc3_aain05.png differ
diff --git a/figs/incoming/mbc3_aain06.png b/figs/incoming/mbc3_aain06.png
new file mode 100755
index 00000000..219cf529
Binary files /dev/null and b/figs/incoming/mbc3_aain06.png differ
diff --git a/figs/incoming/mbc3_aain07.png b/figs/incoming/mbc3_aain07.png
new file mode 100755
index 00000000..3251e591
Binary files /dev/null and b/figs/incoming/mbc3_aain07.png differ
diff --git a/tools/figure_renaming_report.tsv b/tools/figure_renaming_report.tsv
index be640083..6315d71f 100644
--- a/tools/figure_renaming_report.tsv
+++ b/tools/figure_renaming_report.tsv
@@ -1,12 +1,83 @@
Original names New names
-images/transactions.PNG images/mbc2_abin01.png
-images/timestamp.PNG images/mbc2_abin02.png
-images/proof-of-work.PNG images/mbc2_abin03.png
-images/reclaiming-disk.PNG images/mbc2_abin04.png
-images/spv.PNG images/mbc2_abin05.png
-images/combining-splitting.PNG images/mbc2_abin06.png
-images/privacy.PNG images/mbc2_abin07.png
-images/eq1.PNG images/mbc2_abin08.png
-images/eq2.PNG images/mbc2_abin09.png
-images/eq3.PNG images/mbc2_abin10.png
-images/eq4.PNG images/mbc2_abin11.png
+images/receive.png images/mbc3_0101.png
+images/send.png images/mbc3_0102.png
+images/mbc2_0201.png images/mbc3_0201.png
+images/mbc2_0202.png images/mbc3_0202.png
+images/mbc2_0203.png images/mbc3_0203.png
+images/transaction-chain.png images/mbc3_0204.png
+images/mbc2_0205.png images/mbc3_0205.png
+images/mbc2_0206.png images/mbc3_0206.png
+images/mbc2_0207.png images/mbc3_0207.png
+images/mbc2_0209.png images/mbc3_0208.png
+images/mbc2_0210.png images/mbc3_0209.png
+images/mbc2_0301.png images/mbc3_0301.png
+images/mbc2_abin01.png images/mbc3_0401.png
+images/mbc2_0402.png images/mbc3_0402.png
+images/mbc2_0403.png images/mbc3_0403.png
+images/mbc2_0404.png images/mbc3_0404.png
+images/bitcoin-01-send.png images/mbc3_0405.png
+images/mbc2_0406.png images/mbc3_0406.png
+images/mbc2_0405.png images/mbc3_0407.png
+images/mbc2_0407.png images/mbc3_0408.png
+images/bech32-qrcode-uc-lc.png images/mbc3_0409.png
+images/mbc2_0408.png images/mbc3_0410.png
+images/mbc2_0412.png images/mbc3_0411.png
+images/mbc2_0501.png images/mbc3_0501.png
+images/mbc2_0502.png images/mbc3_0502.png
+images/mbc2_0503.png images/mbc3_0503.png
+images/mbc2_0506.png images/mbc3_0504.png
+images/mbc2_0507.png images/mbc3_0505.png
+images/mbc2_0509.png images/mbc3_0506.png
+images/mbc2_0510.png images/mbc3_0507.png
+images/mbc2_0511.png images/mbc3_0508.png
+images/mbc2_0512.png images/mbc3_0509.png
+images/mbc2_0513.png images/mbc3_0510.png
+images/tx-map-1.png images/mbc3_0601.png
+images/input-byte-map.png images/mbc3_0602.png
+images/mbc2_0701.png images/mbc3_0603.png
+images/output-byte-map.png images/mbc3_0604.png
+images/witness-byte-map.png images/mbc3_0605.png
+images/tx-weight-map.png images/mbc3_0606.png
+images/mbc2_0603.png images/mbc3_0701.png
+images/mbc2_0604.png images/mbc3_0702.png
+images/mbc2_0605.png images/mbc3_0703.png
+images/mbc2_0606.png images/mbc3_0704.png
+images/mast1.dot.png images/mbc3_0705.png
+images/mast2.dot.png images/mbc3_0706.png
+images/mast3.dot.png images/mbc3_0707.png
+images/ast.dot.png images/mbc3_0708.png
+images/alt_script.dot.png images/mbc3_0709.png
+images/taproot1.dot.png images/mbc3_0710.png
+images/race1.dot.png images/mbc3_1001.png
+images/bip152.png images/mbc3_1002.png
+images/mbc2_0804.png images/mbc3_1003.png
+images/mbc2_0805.png images/mbc3_1004.png
+images/mbc2_0807.png images/mbc3_1005.png
+images/mbc2_0808.png images/mbc3_1006.png
+images/mbc2_0809.png images/mbc3_1007.png
+images/mbc2_0810.png images/mbc3_1008.png
+images/mbc2_0811.png images/mbc3_1009.png
+images/mbc2_0812.png images/mbc3_1010.png
+images/mbc2_0901.png images/mbc3_1101.png
+images/mbc2_0902.png images/mbc3_1102.png
+images/mbc2_0903.png images/mbc3_1103.png
+images/cve-2012-2459.dot.png images/mbc3_1104.png
+images/mbc2_0904.png images/mbc3_1105.png
+images/mbc2_0905.png images/mbc3_1106.png
+images/mbc2_1001.png images/mbc3_1201.png
+images/fork.dot.png images/mbc3_1202.png
+images/mbc2_1010.png images/mbc3_1203.png
+images/mbc2_1204.png images/mbc3_1401.png
+images/mbc2_1205.png images/mbc3_1402.png
+images/mbc2_1206.png images/mbc3_1403.png
+images/mbc2_1207.png images/mbc3_1404.png
+images/mbc2_1208.png images/mbc3_1405.png
+images/mbc2_1209.png images/mbc3_1406.png
+images/mbc2_1210.png images/mbc3_1407.png
+images/mbc2_abin01.png images/mbc3_aain01.png
+images/mbc2_abin02.png images/mbc3_aain02.png
+images/mbc2_abin03.png images/mbc3_aain03.png
+images/mbc2_abin04.png images/mbc3_aain04.png
+images/mbc2_abin05.png images/mbc3_aain05.png
+images/mbc2_abin06.png images/mbc3_aain06.png
+images/mbc2_abin07.png images/mbc3_aain07.png