List of Figures
Chapter 1. Introduction to Bitcoin
Figure 1.1. The Bitcoin network and its ecosystem
Figure 1.2. A Bitcoin payment. The payment is processed in four steps.
Figure 1.3. Alice creates a transaction, signs it, and sends it to one or more Bitcoin nodes in the Bitcoin network.
Figure 1.4. Alice has sent her transaction to a node in the network. The node verifies the transaction and forwards it to
other nodes. Eventually, the transaction will reach all nodes in the network.
Figure 1.5. Transactions arrive in different orders at different nodes. If all nodes wrote their transactions to the blockchain
in order of arrival, the different nodes’ blockchains would differ.
Figure 1.6. One node takes the lead and tells the others in what order to add transactions. The other nodes verify the block
and update their blockchain copies accordingly.
Figure 1.7. Bob’s wallet has asked a node to notify the wallet upon activity at Bob’s Bitcoin address. Alice pays to Bob’s
address, and the node has just written the transaction to the blockchain, so it notifies Bob’s wallet.
Figure 1.8. Inflation
Figure 1.9. Centralized and decentralized services
Figure 1.10. The supply of bitcoins approaches 21 million over time. The increase is barely visible during the last 100 years
before 2140.
Figure 1.11. Bitcoin is borderless.
Figure 1.12. A remittance company uses Bitcoin to transfer money from Sweden to the Philippines.
Figure 1.13. Price in USD since the beginning of Bitcoin
Figure 1.14. Network effect
Chapter 2. Cryptographic hash functions and digital signatures
Figure 2.1. Digital signatures in Bitcoin
Figure 2.2. The cookie token spreadsheet has a column for the sender, a column for the recipient, and a column for the number
of cookie tokens transferred. New cookie token transfers are appended at the end of the spreadsheet.
Figure 2.3. Lisa calculates Alice’s balance. The sum of her received cookie tokens is 100, and the sum of her withdrawn cookie
tokens is 30. Alice’s balance is 70 CT.
Figure 2.4. Lisa adds Alice’s payment for a cookie. The payment is appended last in the cookie token spreadsheet.
Figure 2.5. Lisa is rewarded with cookie tokens.
Figure 2.6. Creating a cryptographic hash of a cat picture. Input is the cat picture, and output is a big, 32-byte number.
Figure 2.7. Hashing a modified cat picture. Can you spot the difference? The cryptographic hash function certainly did.
Figure 2.8. Save a hash of the cat picture on a piece of paper.
Figure 2.9. Check the integrity of the cat picture. You detect a change.
Figure 2.10. Simplistic hash function using byte-wise addition modulo 256
Figure 2.11. A cryptographic hash function, SHA256, in action. The input “Hello!” will give you the same output every time,
but the slightly modified input “Hello” will give you totally different output.
Figure 2.12. Different desirable properties for cryptographic hash functions. For collision resistance, X can be anything,
as long as the two different inputs give the same output X.
Figure 2.13. You send a digitally signed cat picture to Fred. Fred verifies the signature to make sure he’s got the same cat
as the cat you signed.
Figure 2.14. John needs to digitally sign his payment request and include the signature in the email.
Figure 2.15. The digital signature process. 1 John creates a key pair and gives the public key to Lisa. 2 John signs a message
with the private key. 3 Lisa verifies the message is signed with the private key belonging to the public key she got from
John.
Figure 2.16. John creates a key pair. The private key is a huge random number, and the public key is derived from that random
number. John stores his private key on his hard drive, and the public key is handed to Lisa.
Figure 2.17. Encrypting and decrypting with the public and private keys. Left: Encrypt with the public key, and decrypt with
the private key. Right: Encrypt with the private key, and decrypt with the public key.
Figure 2.18. Digital signatures in Bitcoin
Figure 2.19. John digitally signs the transfer of 10 CT to the cafe. The message to Lisa is first hashed and then encrypted
with John’s private key. The email to Lisa contains both the message in cleartext and the signature.
Figure 2.20. Lisa uses the message A, the signature B, and John’s public key C to verify that the message is signed with John’s
private key.
Figure 2.21. Lisa has added a row for John’s cookie token transfer after verifying the signature of John’s message.
Figure 2.22. Someone stole money from John. Who is Melissa, and how was this possible? John didn’t sign any such transfer.
Figure 2.23. Security considerations against attackers. Note how the more secure options are also more inconvenient.
Chapter 3. Addresses
Figure 3.1. Cookie token addresses are exactly the same as Bitcoin addresses. They’re used mainly by wallet software.
Figure 3.2. Acme Insurances keeps an eye on Chloe’s cookie-eating habits.
Figure 3.3. Replacing names with public keys. The spreadsheet is now more unreadable, which is good from a privacy perspective.
Figure 3.4. New-style payment using public keys instead of names
Figure 3.5. Faiza creates her public key and gives it to the company. The company creates a payment with Faiza’s public key
as the recipient.
Figure 3.6. Replacing the public keys with the RIPEMD160 hash of the SHA256 hash of the public key
Figure 3.7. John buys a cookie. The sender is still a public key, but the recipient is a PKH instead of public key. Lisa needs
to create the PKH from the sender’s public key to verify the balance and execute the payment.
Figure 3.8. John makes a typo in the recipient in the email to Lisa. What now?
Figure 3.9. Bitcoin addresses
Figure 3.10. Overview of base58check encoding, which transforms a PKH into a cookie token address
Figure 3.11. Faiza makes a payment to John’s cookie token address. She decodes the address into a PKH, verifying that the
address isn’t misspelled.
Figure 3.12. The PKH can be encoded into an address and decoded back into the PKH.
Figure 3.13. Base58check encoding John’s PKH. A version is added to the hash, and then a checksum is created and appended
to the versioned hash. Finally, the checksummed, versioned hash is base58 encoded.
Figure 3.14. Encoding John’s versioned and checksummed PKH with base58. The essential part is where you divide the number
by 58 and keep the remainders, which are then mapped one by one in the lookup table.
Figure 3.15. Base58check decoding is basically done by reversing the base58check encoding. Typing errors are detected when
the checksums don’t match.
Chapter 4. Wallets
Figure 4.1. Using a Bitcoin wallet
Figure 4.2. John buys a cookie using the wallet app. The cafe generates a key and displays to John a QR code with payment
details. John scans the payment details and taps OK to approve the payment. John’s wallet sends an email to Lisa.
Figure 4.3. John has just clicked OK in his wallet to approve the payment. The wallet takes care of the rest. It selects a
key with enough funds and signs a message to Lisa. It then automatically emails the signed message to Lisa.
Figure 4.4. John’s and the cafe’s wallets check the spreadsheet every few seconds. If a new payment, either incoming or outgoing,
is found, the wallet updates the balance of the concerned keys and notifies its user.
Figure 4.5. John backs up his private keys. They’re sent in a text file to his email address.
Figure 4.6. John backs up his private keys. They’re sent in a file encrypted with a password that John enters into his phone.
Figure 4.7. Backing up a seed. This is how you want to make backups.
Figure 4.8. Rita creates two accounts, with five addresses in the shopping account and three addresses in the savings account.
Figure 4.9. Creating the first two of Rita’s three savings keys. A random seed is used to create a master extended private
key, which is then used to create child extended private keys.
Figure 4.10. An xprv consists of a private key and a chain code.
Figure 4.11. Deriving Rita’s master xprv. The seed is hashed with HMAC-SHA512. The resulting hash of 512 bits is split into
the left 256 bits, which become the master private key, and the right 256 bits, which become the chain code.
Figure 4.12. Deriving a child xprv from a parent xprv. The parent’s public key and chain code and the desired index are hashed
together. The parent private key is added to the left half of the hash, and the sum becomes the child private key. The right
half becomes the child chain code.
Figure 4.13. You’re working on making a great wallet for users.
Figure 4.14. Encoding a random seed as a 12-word mnemonic sentence. The seed is checksummed, and every group of 11 bits is
looked up in a word list of 2,048 words.
Figure 4.15. Decoding a mnemonic sentence into the seed
Figure 4.16. The cafe copies its online sales xprv to the web server.
Figure 4.17. An xpub consists of a public key and a chain code.
Figure 4.18. Generating the tree of xpubs from the master xpub. The general pattern is the same as when generating xprvs,
but the child-derivation function differs.
Figure 4.19. Xpub derivation. The private key addition from the xprv derivation is replaced by public key “addition.”
Figure 4.20. The plus on the private side has a corresponding plus on the public side. The parent private key plus some value
is the child private key. The parent public key plus the public key derived from the same value is the child public key.
Figure 4.21. Mallory has stolen the private key m/1/1 from the cafe and the parent xpub from the web server. She can now steal
all the money in the online sales account.
Figure 4.22. Deriving a hardened child xprv for the online sales account. You use the parent private key as input to the hash
function instead of the public key.
Figure 4.23. The master xpub can’t be used to generate any child keys because m/0' and m/1' are hardened keys.
Figure 4.24. Whole-number solutions to the elliptic curve y2 = x3 + 7 mod 11. Each such solution is a public key.
Figure 4.25. Point addition. You add (x, y) = (6, 5) to (2, 2) by drawing a straight line through them that will intersect
a third point.
Figure 4.26. Point doubling. To double a point P, draw a line through P with a special slope that’s calculated from P. The
line crosses another point, (3,10). The complement point (3, 1) is the doubling result.
Figure 4.27. The child public key is derived by adding the parent public key with the public key derived from the left 256
bits.
Figure 4.28. Xpub derivation and normal public-key derivation. A normal public key is the starting point G multiplied by a
private key. A child public key is the parent public key added to the public key derived from the left-half hash.
Figure 4.29. Each point on the curve has a symmetric point at the same x value.
Chapter 5. Transactions
Figure 5.1. Bitcoin transactions
Figure 5.2. Bad stuff Lisa could do. She wouldn’t, but she could.
Figure 5.3. The payment process is the same for users, but it’s different for Lisa and the spreadsheet.
Figure 5.4. John’s wallet prepares to pay 10 CT for a cookie. He uses two keys with funds to cover the cost. He pays himself
the change of 3 CT to a fresh address. The transaction isn’t yet signed.
Figure 5.5. John’s wallet signs the transaction. Each input gets its own signature. The public key is also needed in the inputs
because anyone should be able to verify the signature.
Figure 5.6. Lisa verifies that John doesn’t double spend by using her UTXO set.
Figure 5.7. Lisa verifies the first signature of John’s transaction.
Figure 5.8. Lisa adds the transaction to the spreadsheet and removes the spent outputs from the UTXO set.
Figure 5.9. Lisa can no longer steal someone else’s money. If she does, the signatures will become invalid and disclose her
immoral act.
Figure 5.10. The input reveals the public key. We made an extra effort to avoid this in chapter 3.
Figure 5.11. The signature script is the first part of a program. The pubkey script in the spent output is the second part.
If the complete program results in OK, then the payment is authorized to spend the output.
Figure 5.12. Adding a signature and a public key to the stack
Figure 5.13. Copying the public key on the stack, and adding a PKH
Figure 5.14. Adding PKH1 to the stack and comparing the two PKH items
Figure 5.15. Verifying the signature using John’s transaction and the rest of the items from the stack
Figure 5.16. The first input is verified.
Figure 5.17. This chapter covers transactions. Right now, we’re exploring different ways to authenticate transactions.
Figure 5.18. Multisignature setup between Faiza, Ellen, and John. Two of the three keys are needed to spend money.
Figure 5.19. A program that enforces two signatures out of three possible keys. The secret sauce is OP_CHECKMULTISIG.
Figure 5.20. Moving some data items to the stack
Figure 5.21. Executing the OP_CHECKMULTISIG operator, which results in OK this time
Figure 5.22. Overview of p2sh. The pubkey script is simple. The signature script is special because it contains a data item
that contains a program.
Figure 5.23. Verifying the p2sh transaction using old software
Figure 5.24. The stack is replaced by the saved stack, and redeemScript is taken off the stack.
Figure 5.25. Executing the program contained in the redeem script
Figure 5.26. Creating a p2sh address. The difference from normal addresses is the version, which is 05 for p2sh addresses
instead of 00.
Figure 5.27. Encoding a versioned and checksummed script hash with base58. The result will always start with the character
3.
Figure 5.28. Lisa rewards herself every day with a coinbase transaction.
Figure 5.29. The transaction graph. All transactions descend from one or more coinbase transactions.
Chapter 6. The blockchain
Figure 6.1. The Bitcoin blockchain
Figure 6.2. Lisa buys a cookie and then reverts the transaction. She just stole a cookie from the cafe! The cafe and Lisa
now have different UTXO sets.
Figure 6.3. A blockchain is a chain of blocks. These blocks contain transactions, and each block references its predecessor.
Figure 6.4. Each block header protects the integrity of the contained transactions and the blockchain before the block.
Figure 6.5. Lisa creates a new block. It’s called a block template because it isn’t yet signed.
Figure 6.6. Lisa signs a block with her block-signing private key. The public key is well known among the coworkers.
Figure 6.7. Lisa has signed her new block and saves it into a new file in the shared folder.
Figure 6.8. Transactions must be ordered in spending order. Otherwise, there are no restrictions.
Figure 6.9. This block is invalid because a transaction spends an output that doesn’t yet exist.
Figure 6.10. Lisa creates a block containing her payment for a cookie.
Figure 6.11. Lisa creates an alternative block at height 21 that doesn’t contain her transaction.
Figure 6.12. The cafe sees two versions of block 21, one with Lisa’s transaction and one without.
Figure 6.13. Lisa needs to create alternative versions of the block containing her transaction and all subsequent blocks.
Figure 6.14. Each block signs all transactions ever made, thanks to the headers’ previous block ID field.
Figure 6.15. Information exchange between a lightweight wallet and a full node. The full node sends all block headers and
a fraction of all transactions to the wallet.
Figure 6.16. The client sends a bloom filter to the full node to obfuscate what addresses belong to the wallet.
Figure 6.17. The lightweight wallet creates a bloom filter to send to the full node. Each address in the wallet is added to
the bloom filter.
Figure 6.18. The block to send contains three transactions; only one concerns John.
Figure 6.19. The full node uses the bloom filter to determine which transactions are “interesting” to the wallet.
Figure 6.20. Several things in a transaction are tested through the bloom filter to determine whether the transaction is possibly
interesting.
Figure 6.21. A Bitcoin wallet is notified of an incoming payment by a full node.
Figure 6.22. The full node feeds the lightweight wallet the block header and potentially relevant transactions.
Figure 6.23. Lisa creates a merkle root from the transactions in a block.
Figure 6.24. A change in the transactions will cause a change in the merkle root, making the signature invalid.
Figure 6.25. The bare minimum to prove Tx2 is in the block. The full node sends this to the wallet.
Figure 6.26. The lightweight wallet verifies that Tx2 is in the block by reconstructing the merkle root.
Figure 6.27. The full node constructs a partial merkle tree that connects Tx2 to the merkle root in the block header.
Figure 6.28. The wallet verifies the partial merkle tree.
Figure 6.29. The wallet checks that the merkle roots match and that Tx2 is included in the list of hashes. If so, Tx2 is proven
to belong to the block.
Figure 6.30. Constructing a partial merkle tree from 12 transactions and two interesting transactions
Figure 6.31. John’s wallet is connected to multiple full nodes. Hopefully, they don’t all collude to fool John.
Figure 6.32. John has set up a trusted node that his lightweight wallet connects to.
Chapter 7. Proof of work
Figure 7.1. Proof of work
Figure 7.2. Lisa could censor transactions like a dictator. No cookies for John!
Figure 7.3. Tom and Qi begin creating blocks just as Lisa does, resulting in block collisions. The block headers have been
simplified for clarity.
Figure 7.4. Three miners build blocks. Usually blocks are created nicely, one by one, but sometimes they will compete to become
the next block, as at height 106.
Figure 7.5. An immediate resolution: Lisa draws a lucky number.
Figure 7.6. Both Lisa and Qi draw a lucky number at the same time. The situation isn’t resolved yet.
Figure 7.7. Tom is the next lucky miner, and he gets to extend “his” branch, which will now become the longest.
Figure 7.8. One of the branches experiences yet another split. This new split is resolved like the previous one.
Figure 7.9. Proof of work is how you select a leader without a leader.
Figure 7.10. The block signatures are replaced by proof of work.
Figure 7.11. The block ID must be less than or equal to the target in the header. Otherwise, the block is invalid.
Figure 7.12. Qi tests if her block is valid by verifying the proof of work.
Figure 7.13. Qi increases the nonce and makes a second attempt at finding a valid proof of work. This also fails.
Figure 7.14. Changing the input of a cryptographic hash function results in completely different output.
Figure 7.15. Qi’s third attempt at finding a valid proof of work. She fails again.
Figure 7.16. Qi’s try with nonce 227,299,124. Close but no cigar!
Figure 7.17. Qi keeps on working.
Figure 7.18. The nonce 492781982 is a winner!
Figure 7.19. Block verification has changed. The verifier no longer needs anything from outside the block.
Figure 7.20. The blockchain works the same as when lucky numbers were used.
Figure 7.21. The block header can be changed in different ways.
Figure 7.22. Adjusting the target based on the last 2,016 blocks. The goal is 2,016 blocks in two weeks.
Figure 7.23. Two blocks are mined with decreasing timestamps. That’s OK.
Figure 7.24. A natural split with differing timestamps between the branches will cause one branch to become stronger than
the other in case of a retarget.
Figure 7.25. Lisa creates two transactions that spend one common output.
Figure 7.26. Lisa pulls off a double-spend attack—and succeeds despite her small hashrate.
Figure 7.27. Lisa tries to double spend a transaction with six confirmations. She fails.
Figure 7.28. Tom attempts to double spend with an 18% hashrate and gives up. He’s lucky to find 2 blocks in about the same
time the honest miners find 3.
Figure 7.29. Hashrate distribution. Two miners can collude to control a majority of the hashrate.
Figure 7.30. New hashrate distribution. It’s much harder to get control over a majority of the hashrate.
Figure 7.31. Lisa and Tom compete to get Qi and the other miners to mine on top of their block. Tom wins this race because
his block was smaller.
Figure 7.32. John includes a fee for the miner who mines a block with his transaction.
Figure 7.33. Lisa’s working on a block, and she’s included John’s transaction and a few others. She collects the fees in the
coinbase output.
Figure 7.34. In a fee market, transactions compete for block space. The numbers in the transactions denote the fee level in
CT/byte.
Figure 7.35. When there is no fee market, transactions don’t compete with each other. They just have to pay for the lost competitiveness.
Figure 7.36. A miner must make at least enough money to pay the electricity bill.
Chapter 8. Peer-to-peer network
Figure 8.1. Bitcoin’s peer-to-peer network
Figure 8.2. The shared folder is a central point of authority.
Figure 8.3. In a peer-to-peer network, blocks are passed from one node to another, much as gossip spreads among people.
Figure 8.4. If the cafe refuses to relay a block to Lisa, someone else will do it.
Figure 8.5. Transactions travel the peer-to-peer network just like blocks do. Wallets no longer need to know the miners.
Figure 8.6. Tom and Lisa communicate over the internet through a communication channel.
Figure 8.7. Tom’s computer program sets up a TCP connection to Lisa’s computer program. After this, they can send and receive
data between each other.
Figure 8.8. Lisa must be able to understand what Tom writes on the channel.
Figure 8.9. A typical network message
Figure 8.10. Lightweight wallets communicate with nodes using the Bitcoin network protocol.
Figure 8.11. The transaction is sent to Tom’s node through a TCP connection.
Figure 8.12. Tom’s node is informed about John’s transaction so that Tom can fetch it.
Figure 8.13. Tom forwards the transaction to his peers.
Figure 8.14. Tom’s node sends the transaction to Qi’s node using the familiar three-step process.
Figure 8.15. Lisa’s node sends an inv to Qi’s node, but Qi’s node already has the transaction.
Figure 8.16. The cafe’s lightweight wallet has a TCP connection to its own full node.
Figure 8.17. The cafe’s wallet gets John’s transaction from the cafe’s trusted node after the transaction is checked against
the bloom filter.
Figure 8.18. Rashid’s block containing John’s transaction
Figure 8.19. Rashid’s node sends Rashid’s block to Qi’s node.
Figure 8.20. All but Lisa have the block. Tom, the cafe, and Qi send headers messages.
Figure 8.21. Tom sends a merkleblock containing a merkle proof that John’s transaction is in the block.
Figure 8.22. The merkleblock message contains a block header and a partial merkle tree.
Figure 8.23. The cafe requests a merkle block from its trusted full node.
Figure 8.24. As more blocks arrive, John’s transaction becomes safer and safer.
Figure 8.25. The cookie token system’s evolution
Figure 8.26. The Bitcoin network distributes blocks (and transactions) to all participants.
Figure 8.27. Running a full node involves downloading and running the software, connecting to other nodes, downloading old
blocks, and entering normal operation.
Figure 8.28. The Bitcoin Core team signs the released program with their private key.
Figure 8.29. Selma verifies the Bitcoin Core signature and that the hash in the signature file matches the hash of the actual
program.
Figure 8.30. Selma’s full node has three different types of sources to find initial peers.
Figure 8.31. Selma exchanges a version message with Qi.
Figure 8.32. Selma asks her peers for more peer addresses to connect to.
Figure 8.33. Selma requests more peer addresses from Rashid’s node. He responds with a bunch.
Figure 8.34. Selma downloads block headers from Tom by repeatedly sending a getheaders message with her latest block ID.
Figure 8.35. Selma downloads blocks from Rashid by repeatedly sending a getdata message with a list block IDs she wants the
blocks for.
Figure 8.36. To speed up initial block download, signatures of reasonably old transactions won’t be verified.
Figure 8.37. Selma is finally an active part of the Bitcoin peer-to-peer network.
Figure 8.38. The Bitcoin Core team signs the released program with their private key.
Chapter 9. Transactions revisited
Figure 9.1. A payment to your daughter that will become valid on 30 April 2019
Figure 9.2. Make Tx1 invalid by spending an output that Tx1 spends, and create a new time-locked transaction for your daughter.
Figure 9.3. Your daughter can claim your money after the median time past is earlier than your lock time.
Figure 9.4. A time-locked transaction based on block height. This transaction is first valid at block height 571020.
Figure 9.5. Relative time locks can be expressed either as a number of blocks or as a number of time units. You use the inputs’
sequence numbers for this.
Figure 9.6. The first input locks the transaction for 30 days from the spent output.
Figure 9.7. The second input locks the transaction for 1,000 blocks from the spent output.
Figure 9.8. Paying allowance in advance to your daughter. She may not spend it before 1 May.
Figure 9.9. Various spending transactions and their validity
Figure 9.10. Spending a relative time-locked output is allowed after a certain number of blocks have passed.
Figure 9.11. John and Fadime create a contract transaction each. The redeem script of the p2sh output contains the contract
details.
Figure 9.12. The first step of the actual swap. John claims Fadime’s 100 NMC by revealing the secret S.
Figure 9.13. Fadime completes the atomic swap by sending her swap transaction to the Bitcoin network.
Figure 9.14. Ampere creates a new token for a newly built car. It issues the token to itself because it still owns this car.
Figure 9.15. Ampere sells the car to a car dealer with public key hash PKHD.
Figure 9.16. The car dealer transfers the car’s ownership to Fadime’s PKHF.
Figure 9.17. Fadime starts her car by signing a challenge with her private key.
Figure 9.18. You pay for your book and set the transaction fee to 0.00001 BTC.
Figure 9.19. You try to replace your old, stuck transaction with a new one with a higher fee.
Figure 9.20. Use opt-in RBF to easily replace a transaction before it’s confirmed.
Figure 9.21. You haven’t paid a sufficient transaction fee. The transaction is stuck pending because miners don’t want to
include it in a block.
Figure 9.22. Spending your change and paying an extra fee for the “parent” transaction
Figure 9.23. Normally, the entire transaction is signed. All inputs and all outputs are covered.
Figure 9.24. A signature can commit to different parts of the transaction depending on the SIGHASH types. The signature doesn’t
include the grayed-out parts.
Chapter 10. Segregated witness
Figure 10.1. You spend one of the outputs that the previous time-locked transaction spends and create a new time-locked transaction
that you give to your daughter.
Figure 10.2. Your transaction is being modified by Qi on its way through the network.
Figure 10.3. The inheritance fails because your daughter’s time-locked transaction is forever invalid due to transaction malleability.
Figure 10.4. Three classes of transaction malleability
Figure 10.5. Signing the first input. You prepare by copying the pubkey script to the signature script.
Figure 10.6. Signing the second input
Figure 10.7. Total time for hashing during signature verification. Time roughly quadruples when the number of inputs doubles.
Figure 10.8. Without the signature scripts, a lightweight wallet can’t verify that a transaction is included in the block.
Figure 10.9. Using OP_CLTV to lock an output until 1 May
Figure 10.10. The txid is calculated from the entire transaction, including signature scripts.
Figure 10.11. A segwit transaction contains no signature data. The signatures are attached, instead. The txid doesn’t commit
to the signatures.
Figure 10.12. Amy decodes the segwit address to get the witness version and the witness program.
Figure 10.13. Amy sends 0.1 BTC to your segwit address. The pubkey script doesn’t contain any script operators, just data.
Figure 10.14. You create and broadcast a payment to the popcorn machine owner.
Figure 10.15. A full node verifies your transaction’s witness. The pattern 00 followed by exactly 20 bytes gets special treatment.
Figure 10.16. An old node sees just two data items in the pubkey script and an empty signature script.
Figure 10.17. Your segwit transaction gets included in a block. The block commits to the witnesses by putting the witness
commitment into an output of the coinbase transaction.
Figure 10.18. The coinbase transaction’s witness contains the witness reserved value, and an OP_RETURN output contains the
witness commitment.
Figure 10.19. An old node verifies the block with your transaction. It won’t verify the signatures or the witness commitment.
Figure 10.20. John and Faiza spend an output from their multisig wallet.
Figure 10.21. The witness script is hashed into a witness script hash.
Figure 10.22. The popcorn guy sends the money to the charity’s p2wsh address.
Figure 10.23. The charity pays 0.07 BTC to the shelter’s address. The witness is the signatures followed by a data item that
contains the actual witness script.
Figure 10.24. Preparing to verify the p2wsh input
Figure 10.25. Verifying the witness of a p2wsh payment
Figure 10.26. Hashing is done in two steps. The intermediate hash is reused for each input.
Figure 10.27. An offline wallet can’t know a transaction’s fee.
Figure 10.28. Nina sends 0.1 BTC to your segwit wallet using a p2wpkh inside a p2sh address.
Figure 10.29. You spend the money you got from Nina by setting the version byte and witness program in the redeem script in
your input’s signature script.
Figure 10.30. p2pkh: address format 1<some base58 characters>
Figure 10.31. p2sh: address format 3<some base58 characters>
Figure 10.32. p2wpkh: address format bc1q<38 base32 characters>
Figure 10.33. p2wsh: address format bc1q<58 base32 characters>
Figure 10.34. p2wpkh nested in p2sh: address format 3<some base58 characters>
Figure 10.35. p2wsh nested in p2sh: address format 3<some base58 characters>
Figure 10.36. Witness bytes and nonwitness bytes are counted differently. Witness bytes contribute less to the block weight
and not at all to the traditional block size, the base block size.
Chapter 11. Bitcoin upgrades
Figure 11.1. Soft forks tighten the consensus rules, whereas hard forks widen them—for example, decreasing the maximum block
weight or increasing it, respectively.
Figure 11.2. Your new message will be accepted by New nodes and ignored by Old nodes.
Figure 11.3. Qi gets a transaction twice: first during transaction propagation, and then during block propagation.
Figure 11.4. Compact blocks in action. Rashid sends just the necessary data to Qi.
Figure 11.5. Your node running Bitcoin New is a loser against the Bitcoin Old nodes. Bitcoin Old will discard all of your
blocks that violate the ≤ 4,000,000 WU rule.
Figure 11.6. A majority of the hashrate runs Bitcoin New. It seems to have caused a permanent chain split.
Figure 11.7. The Bitcoin New chain is wiped out because the Bitcoin Old chain becomes stronger.
Figure 11.8. Bitcoin Cash protects against wipeout by requiring the first block after the chain split to be >1 MB.
Figure 11.9. An Old miner regards a segwit output as anyone-can-spend and adds to the block a transaction that spends it as
such.
Figure 11.10. The soft fork might cause a chain split if the Bitcoin Old nodes produce a block that Bitcoin New miners don’t
accept.
Figure 11.11. As people adopt Bitcoin New, the branch will cause a reorg for Old nodes.
Figure 11.12. After a chain split, you effectively have two versions of your UTXOs.
Figure 11.13. Your transaction to the bookstore is valid on both the Bitcoin Old and the Bitcoin New branches.
Figure 11.14. Transaction replay causes you to pay in both currencies.
Figure 11.15. With replay protection, a transaction is valid on only one of the branches.
Figure 11.16. A miner signals support for p2sh by writing /P2SH/ in the coinbase’s signature script.
Figure 11.17. The block header contains a block version. The first blocks used version 1.
Figure 11.18. BIP34 requires that all blocks contain the block height in the coinbase.
Figure 11.19. Miners that run the soft fork signal support for it by increasing their block version.
Figure 11.20. The Old nodes could cause a chain split, but it probably won’t last for long.
Figure 11.21. The block version is treated differently. Each of the right 29 bits can signal for different proposals.
Figure 11.22. State transitions happen every 2,016 blocks.
Figure 11.23. BIP9 deployment of csv. It went well.
Figure 11.24. The segwit deployment didn’t proceed as anticipated.
Figure 11.25. BIP91 updates its state every 336 blocks instead of the usual 2,016. This went quickly.
Figure 11.26. Segwit finally activates thanks to BIP91.
Figure 11.27. Users start rejecting big blocks. They see no new valid blocks, but plenty of invalid (too-big) blocks.
Figure 11.28. One miner decides to go with the users’ will and only build small blocks. This miner will be able to pay the
bills.
Figure 11.29. A few more miners realize it’s more profitable to work on the users’ branch.
Figure 11.30. The users’ branch is stronger and wipes out the big-blocks branch.