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

Move chapters to top level directory to fix Atlas build issue

Browse Source 
They use "safe" build mode which doesn't let me reference arbitrary
diroctories in include files.
This commit is contained in:
David A. Harding 2023-08-25 19:06:37 +02:00
parent 67a69200f7
commit 7da725a096
21 changed files with 130 additions and 131 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
chapters/applications.adoc → applications.adoc
View File

@ -452,7 +452,7 @@ cases", "buying coffee", startref="alicetwelve")))
[[payment_channel]] [[payment_channel]]
.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions .A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions
image::../images/mbc2_1204.png["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"]
==== Simple Payment Channel Example ==== Simple Payment Channel Example
@ -478,7 +478,7 @@ streaming service from Fabian using a payment channel.
[[emma_fabian_streaming_video]] [[emma_fabian_streaming_video]]
.Emma purchases streaming video from Fabian with a payment channel, paying for each second of video .Emma purchases streaming video from Fabian with a payment channel, paying for each second of video
image::../images/mbc2_1205.png["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"]
In this example, Fabian and Emma are using special software that handles In this example, Fabian and Emma are using special software that handles
both the payment channel and the video streaming. Emma is running the both the payment channel and the video streaming. Emma is running the
@ -554,7 +554,7 @@ participants.((("", startref="PSCexample12")))
[[video_payment_channel]] [[video_payment_channel]]
.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel .Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
image::../images/mbc2_1206.png["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"]
==== Making Trustless Channels ==== Making Trustless Channels
@ -620,7 +620,7 @@ commitments become valid.
[[timelocked_commitments]] [[timelocked_commitments]]
.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid .Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid
image::../images/mbc2_1207.png["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"]
Each subsequent commitment transaction must have a shorter timelock so Each subsequent commitment transaction must have a shorter timelock so
that it may be broadcast before its predecessors and before the refund that it may be broadcast before its predecessors and before the refund
@ -810,7 +810,7 @@ where the output paying the holder of the commitment is delayed.
[[asymmetric_commitments]] [[asymmetric_commitments]]
.Two asymmetric commitment transactions with delayed payment for the party holding the transaction .Two asymmetric commitment transactions with delayed payment for the party holding the transaction
image::../images/mbc2_1208.png["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"]
Now we introduce the final element of this scheme: a revocation key that Now we introduce the final element of this scheme: a revocation key that
prevents a cheater from broadcasting an expired commitment. The prevents a cheater from broadcasting an expired commitment. The
@ -1016,7 +1016,7 @@ to make a payment from Alice to Eric (<<lightning_network>>).
[[lightning_network_fig]] [[lightning_network_fig]]
.A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric .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/mbc2_1209.png["A series of bi-directional payment channels linked to form a Lightning Network"]
Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
Eric by a payment channel. Creating a payment channel requires a funding Eric by a payment channel. Creating a payment channel requires a funding
@ -1030,7 +1030,7 @@ payment channels connecting the participants.
[[ln_payment_process]] [[ln_payment_process]]
.Step-by-step payment routing through a Lightning Network .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/mbc2_1210.png["Step-by-step payment routing through a Lightning Network"]
Alice is running a Lightning Network (LN) node that is keeping track of 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 her payment channel to Bob and has the ability to discover routes

36
atlas.json
View File

@ -6,24 +6,24 @@
"copyright.html", "copyright.html",
"dedication.html", "dedication.html",
"toc.html", "toc.html",
"chapters/preface.asciidoc", "preface.asciidoc",
"chapters/intro.adoc", "intro.adoc",
"chapters/overview.adoc", "overview.adoc",
"chapters/bitcoin-core.adoc", "bitcoin-core.adoc",
"chapters/keys.adoc", "keys.adoc",
"chapters/wallets.adoc", "wallets.adoc",
"chapters/transactions.adoc", "transactions.adoc",
"chapters/authorization-authentication.adoc", "authorization-authentication.adoc",
"chapters/signatures.adoc", "signatures.adoc",
"chapters/fees.adoc", "fees.adoc",
"chapters/network.adoc", "network.adoc",
"chapters/blockchain.adoc", "blockchain.adoc",
"chapters/mining.adoc", "mining.adoc",
"chapters/security.adoc", "security.adoc",
"chapters/applications.adoc", "applications.adoc",
"chapters/whitepaper.adoc", "whitepaper.adoc",
"chapters/errata.adoc", "errata.adoc",
"chapters/bips.adoc", "bips.adoc",
"author_bio.html" "author_bio.html"
], ],
"formats": { "formats": {

20
chapters/authorization-authentication.adoc → authorization-authentication.adoc
View File

@ -134,7 +134,7 @@ validation.
[[input_and_output_scripts_legacy]] [[input_and_output_scripts_legacy]]
.Combining input and output scripts to evaluate a transaction script .Combining input and output scripts to evaluate a transaction script
image::../images/mbc2_0603.png["input_and_output_scripts"] image::images/mbc2_0603.png["input_and_output_scripts"]
===== The script execution stack ===== The script execution stack
@ -221,7 +221,7 @@ Wiki's script page].
[[simplemath_script]] [[simplemath_script]]
.Bitcoin's script validation doing simple math .Bitcoin's script validation doing simple math
image::../images/mbc2_0604.png["TxScriptSimpleMathExample"] image::images/mbc2_0604.png["TxScriptSimpleMathExample"]
[role="pagebreak-before"] [role="pagebreak-before"]
The following is a slightly more complex script, which calculates The following is a slightly more complex script, which calculates
@ -310,11 +310,11 @@ startref="Stransact06")))
[[P2PubKHash1]] [[P2PubKHash1]]
.Evaluating a script for a P2PKH transaction (part 1 of 2) .Evaluating a script for a P2PKH transaction (part 1 of 2)
image::../images/mbc2_0605.png["Tx_Script_P2PubKeyHash_1"] image::images/mbc2_0605.png["Tx_Script_P2PubKeyHash_1"]
[[P2PubKHash2]] [[P2PubKHash2]]
.Evaluating a script for a P2PKH transaction (part 2 of 2) .Evaluating a script for a P2PKH transaction (part 2 of 2)
image::../images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"] image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
[[multisig]] [[multisig]]
=== Scripted multisignatures === Scripted multisignatures
@ -1668,7 +1668,7 @@ of the three authorization conditions in <<diagram_mast1>>.
[[diagram_mast1]] [[diagram_mast1]]
.A MAST with three sub-scripts .A MAST with three sub-scripts
image::../images/mast1.dot.png["A MAST with three sub-scripts"] image::images/mast1.dot.png["A MAST with three sub-scripts"]
We can now create a compact membership proof that proves a particular We can now create a compact membership proof that proves a particular
authorization condition is a member of the merkle tree without authorization condition is a member of the merkle tree without
@ -1679,7 +1679,7 @@ specified at spend time.
[[diagram_mast2]] [[diagram_mast2]]
.A MAST membership proof for one of the sub-scripts .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/mast2.dot.png["A MAST membership proof for one of the sub-scripts"]
The hash digests used to create the commitments are each 32-bytes, so 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 proving the above spend is authorized (using a merkle tree and the
@ -1710,7 +1710,7 @@ our tree with this knowledge in <<diagram_mast3>>.
[[diagram_mast3]] [[diagram_mast3]]
.A MAST with the most-expected script in the best position .A MAST with the most-expected script in the best position
image::../images/mast3.dot.png["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"]
Now we only need to provide two commitments for the common case (saving 32 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. bytes), although we still need three commitments for the less common cases.
@ -1739,7 +1739,7 @@ every condition in a script creates a new branch, as show in <<ast>>.
[[ast]] [[ast]]
.An Abstract Syntax Tree (AST) for a script .An Abstract Syntax Tree (AST) for a script
image::../images/ast.dot.png["An Abstract Syntax Tree (AST) for a script"] image::images/ast.dot.png["An Abstract Syntax Tree (AST) for a script"]
ASTs are widely used by programs that parse and optimize code for other ASTs are widely used by programs that parse and optimize code for other
programs, such as compilers. A merklized AST would commit to every part programs, such as compilers. A merklized AST would commit to every part
@ -1756,7 +1756,7 @@ them alternatives for each other, as shown in <<alt_script>>.
[[alt_script]] [[alt_script]]
.An alternative script tree .An alternative script tree
image::../images/alt_script.dot.png["An alternative script tree"] image::images/alt_script.dot.png["An alternative script tree"]
Alternative script trees only require revealing one 32-byte digest for Alternative script trees only require revealing one 32-byte digest for
each level of depth between the spender's chosen script and the root of each level of depth between the spender's chosen script and the root of
@ -1935,7 +1935,7 @@ involving both a public key and a MAST is shown in <<diagram_taproot1>>.
[[diagram_taproot1]] [[diagram_taproot1]]
.A taproot with the public key committing to a merkle root .A taproot with the public key committing to a merkle root
image::../images/taproot1.dot.png["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"]
This makes the mutual satisfaction clause using a multisignature This makes the mutual satisfaction clause using a multisignature
extremely efficient and very private. It's even more private than it extremely efficient and very private. It's even more private than it

0
chapters/bips.adoc → bips.adoc
View File

8
chapters/bitcoin-core.adoc → bitcoin-core.adoc
View File

@ -55,7 +55,7 @@ Core.((("Bitcoin Core", "architecture")))
[[bitcoin_core_architecture]] [[bitcoin_core_architecture]]
.Bitcoin Core architecture (Source: Eric Lombrozo) .Bitcoin Core architecture (Source: Eric Lombrozo)
image::../images/mbc2_0301.png["Bitcoin Core Architecture"] image::images/mbc2_0301.png["Bitcoin Core Architecture"]
Although Bitcoin Core serves as a reference implementation for many Although Bitcoin Core serves as a reference implementation for many
major parts of the system, the Bitcoin whitepaper describes several major parts of the system, the Bitcoin whitepaper describes several
@ -1058,7 +1058,7 @@ Core.
==== ====
[source,python] [source,python]
---- ----
include::../code/rpc_example.py[] include::code/rpc_example.py[]
---- ----
==== ====
@ -1085,7 +1085,7 @@ change back to Alice.
==== ====
[source,python] [source,python]
---- ----
include::../code/rpc_transaction.py[] include::code/rpc_transaction.py[]
---- ----
==== ====
@ -1112,7 +1112,7 @@ value.((("", startref="alicethree")))
==== ====
[source,python] [source,python]
---- ----
include::../code/rpc_block.py[] include::code/rpc_block.py[]
---- ----
==== ====

12
chapters/blockchain.adoc → blockchain.adoc
View File

@ -303,7 +303,7 @@ references in the +previousblockhash+ field.
[[chain_of_blocks]] [[chain_of_blocks]]
[role="smallerfourtyfive"] [role="smallerfourtyfive"]
.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/mbc2_0901.png[] image::images/mbc2_0901.png[]
[[merkle_trees]] [[merkle_trees]]
=== Merkle Trees === Merkle Trees
@ -368,7 +368,7 @@ of the nodes.
[[simple_merkle]] [[simple_merkle]]
.Calculating the nodes in a merkle tree .Calculating the nodes in a merkle tree
image::../images/mbc2_0902.png["merkle_tree"] image::images/mbc2_0902.png["merkle_tree"]
((("balanced trees")))Because the merkle tree is a binary tree, it needs ((("balanced trees")))Because the merkle tree is a binary tree, it needs
an even number of leaf nodes. If there is an odd number of transactions an even number of leaf nodes. If there is an odd number of transactions
@ -380,7 +380,7 @@ the last hash is duplicated.
[[merkle_tree_odd]] [[merkle_tree_odd]]
.Duplicating one data element achieves an even number of data elements .Duplicating one data element achieves an even number of data elements
image::../images/mbc2_0903.png["merkle_tree_odd"] image::images/mbc2_0903.png["merkle_tree_odd"]
.A design flaw in Bitcoin's merkle tree .A design flaw in Bitcoin's merkle tree
**** ****
@ -403,7 +403,7 @@ trees:
[[cve_tree]] [[cve_tree]]
.Two Bitcoin-style merkle tree with the same root but a different number of leaves .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/cve-2012-2459.dot.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 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 6 are repeated) result in the same root hash A (because the hash of both
@ -448,7 +448,7 @@ block.
[[merkle_tree_large]] [[merkle_tree_large]]
.A merkle tree summarizing many data elements .A merkle tree summarizing many data elements
image::../images/mbc2_0904.png["merkle_tree_large"] image::images/mbc2_0904.png["merkle_tree_large"]
In <<merkle_tree_path>>, a node can prove that a transaction K is In <<merkle_tree_path>>, a node can prove that a transaction K is
included in the block by producing a merkle path that is only four included in the block by producing a merkle path that is only four
@ -463,7 +463,7 @@ diagram).
[[merkle_tree_path]] [[merkle_tree_path]]
.A merkle path used to prove inclusion of a data element .A merkle path used to prove inclusion of a data element
image::../images/mbc2_0905.png["merkle_tree_path"] image::images/mbc2_0905.png["merkle_tree_path"]
The efficiency of merkle trees becomes obvious as the scale increases. The efficiency of merkle trees becomes obvious as the scale increases.
The largest possible block can hold almost 16,000 transactions in 4,000,000 The largest possible block can hold almost 16,000 transactions in 4,000,000

36
book.adoc
View File

@ -1,37 +1,37 @@
= Mastering Bitcoin = Mastering Bitcoin
include::chapters/preface.asciidoc[] include::preface.asciidoc[]
include::chapters/intro.adoc[] include::intro.adoc[]
include::chapters/overview.adoc[] include::overview.adoc[]
include::chapters/bitcoin-core.adoc[] include::bitcoin-core.adoc[]
include::chapters/keys.adoc[] include::keys.adoc[]
include::chapters/wallets.adoc[] include::wallets.adoc[]
include::chapters/transactions.adoc[] include::transactions.adoc[]
include::chapters/authorization-authentication.adoc[] include::authorization-authentication.adoc[]
include::chapters/signatures.adoc[] include::signatures.adoc[]
include::chapters/fees.adoc[] include::fees.adoc[]
include::chapters/network.adoc[] include::network.adoc[]
include::chapters/blockchain.adoc[] include::blockchain.adoc[]
include::chapters/mining.adoc[] include::mining.adoc[]
include::chapters/security.adoc[] include::security.adoc[]
include::chapters/applications.adoc[] include::applications.adoc[]
include::chapters/whitepaper.adoc[] include::whitepaper.adoc[]
include::chapters/errata.adoc[] include::errata.adoc[]
include::chapters/bips.adoc[] include::bips.adoc[]

0
chapters/errata.adoc → errata.adoc
View File

0
chapters/fees.adoc → fees.adoc
View File

4
chapters/intro.adoc → intro.adoc
View File

@ -399,7 +399,7 @@ Alice uses the _Receive_ button, which displays a QR code, shown in <<wallet_rec
[[wallet_receive]] [[wallet_receive]]
.Alice uses the Receive screen on her mobile Bitcoin wallet, and displays her address in a QR code format .Alice uses the Receive screen on her mobile Bitcoin wallet, and displays her address in a QR code format
image::../images/receive.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"] image::images/receive.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"]
The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera. The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@ -497,7 +497,7 @@ faster the transaction will be confirmed (see <<confirmations>>).
[[wallet-send]] [[wallet-send]]
[role="smallereighty"] [role="smallereighty"]
.Bitcoin wallet send screen .Bitcoin wallet send screen
image::../images/send.png["Wallet send screen. Image derived from Bitcoin Design Guide CC-BY"] image::images/send.png["Wallet send screen. Image derived from Bitcoin Design Guide CC-BY"]
Joe then carefully checks to make sure he has entered the correct Joe then carefully checks to make sure he has entered the correct
amount, because he is about to transmit money and mistakes will soon become amount, because he is about to transmit money and mistakes will soon become

22
chapters/keys.adoc → keys.adoc
View File

@ -20,7 +20,7 @@ that itself commits to Bob's public key and other transaction details.
[[pay-to-pure-pubkey]] [[pay-to-pure-pubkey]]
.Transaction chain from original Bitcoin paper .Transaction chain from original Bitcoin paper
image::../images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"] image::images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"]
We'll examine public keys, private keys, signatures, and hash functions We'll examine public keys, private keys, signatures, and hash functions
in this chapter, and then use all of them together to describe in this chapter, and then use all of them together to describe
@ -178,7 +178,7 @@ by Bitcoin.
[[ecc-curve]] [[ecc-curve]]
[role="smallerthirty"] [role="smallerthirty"]
.An elliptic curve .An elliptic curve
image::../images/mbc2_0402.png["ecc-curve"] image::images/mbc2_0402.png["ecc-curve"]
Bitcoin uses a specific elliptic curve and set of mathematical Bitcoin uses a specific elliptic curve and set of mathematical
constants, as defined in a standard called +secp256k1+, established by constants, as defined in a standard called +secp256k1+, established by
@ -219,7 +219,7 @@ more complex pattern of dots on a unfathomably large grid.
[[ecc-over-F17-math]] [[ecc-over-F17-math]]
[role="smallersixty"] [role="smallersixty"]
.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/mbc2_0403.png["ecc-over-F17-math"] image::images/mbc2_0403.png["ecc-over-F17-math"]
So, for example, the following is a point P with coordinates (x,y) that So, for example, the following is a point P with coordinates (x,y) that
is a point on the +secp256k1+ curve: is a point on the +secp256k1+ curve:
@ -386,7 +386,7 @@ library] to do the elliptic curve math.
[[ecc_illustrated]] [[ecc_illustrated]]
.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve .Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve
image::../images/mbc2_0404.png["ecc_illustrated"] image::images/mbc2_0404.png["ecc_illustrated"]
=== Output and Input Scripts === Output and Input Scripts
@ -428,7 +428,7 @@ Bitcoin protocol.
[[bitcoin_01_send]] [[bitcoin_01_send]]
.Early send screen for Bitcoin via https://web.archive.org/web/20090722011820/https://bitcoin.org/[The Internet Archive] .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/bitcoin-01-send.png["Early Bitcoin send screen"]
If Alice entered Bob's IP address in Bitcoin 0.1, her full node would If Alice entered Bob's IP address in Bitcoin 0.1, her full node would
establish a connection with his full node and receive a new public key establish a connection with his full node and receive a new public key
@ -687,7 +687,7 @@ encoding process.
[[base58check_encoding]] [[base58check_encoding]]
.Base58Check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data .Base58Check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data
image::../images/mbc2_0406.png["Base58CheckEncoding"] image::images/mbc2_0406.png["Base58CheckEncoding"]
In Bitcoin, other data besides public key commitments are presented to the user in 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 base58check encoding to make that data compact, easy to read, and easy to detect
@ -720,7 +720,7 @@ into a Bitcoin address in <<pubkey_to_address>>.
[[pubkey_to_address]] [[pubkey_to_address]]
.Public key to Bitcoin address: conversion of a public key into a Bitcoin 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/mbc2_0405.png["pubkey_to_address"]
[[comp_pub]] [[comp_pub]]
=== Compressed public keys === Compressed public keys
@ -811,7 +811,7 @@ addresses.
[[pubkey_compression]] [[pubkey_compression]]
[role="smallerseventy"] [role="smallerseventy"]
.Public key compression .Public key compression
image::../images/mbc2_0407.png["pubkey_compression"] image::images/mbc2_0407.png["pubkey_compression"]
Compressed public keys are now the default in almost all Bitcoin Compressed public keys are now the default in almost all Bitcoin
software, and were made required when using certain new features added software, and were made required when using certain new features added
@ -1075,7 +1075,7 @@ https://bitcoin.sipa.be/bech32/demo/demo.html[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/bech32-qrcode-uc-lc.png["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"]
- Bech32 takes advantage of an upgrade mechanism designed as part of - Bech32 takes advantage of an upgrade mechanism designed as part of
segwit to make it possible for spender wallets to be able to pay segwit to make it possible for spender wallets to be able to pay
@ -1673,7 +1673,7 @@ features. <<paper_wallet_simple>> shows a sample paper wallet.
[[paper_wallet_simple]] [[paper_wallet_simple]]
.An example of a simple paper wallet .An example of a simple paper wallet
image::../images/mbc2_0408.png[] image::images/mbc2_0408.png[]
Some are intended to be given as gifts and have seasonal themes, such as Some are intended to be given as gifts and have seasonal themes, such as
Christmas and New Year's themes. Others are designed for storage in a Christmas and New Year's themes. Others are designed for storage in a
@ -1687,7 +1687,7 @@ startref="Wpaper04")))((("", startref="paperw04")))
[[paper_wallet_spw]] [[paper_wallet_spw]]
.An example of a paper wallet with additional copies of the keys on a backup "stub" .An example of a paper wallet with additional copies of the keys on a backup "stub"
image::../images/mbc2_0412.png[] image::images/mbc2_0412.png[]
From the original public-key focused design of Bitcoin to modern addresses From the original public-key focused design of Bitcoin to modern addresses
and scripts like bech32m and pay-to-taproot--and even addresses for and scripts like bech32m and pay-to-taproot--and even addresses for

8
chapters/mining.adoc → mining.adoc
View File

@ -126,7 +126,7 @@ time, as the issuance of currency decreases.
[[bitcoin_money_supply]] [[bitcoin_money_supply]]
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate .Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
image::../images/mbc2_1001.png["BitcoinMoneySupply"] image::images/mbc2_1001.png["BitcoinMoneySupply"]
[NOTE] [NOTE]
==== ====
@ -145,7 +145,7 @@ bitcoin that will be issued.
==== ====
[source, python] [source, python]
---- ----
include::../code/max_money.py[] include::code/max_money.py[]
---- ----
==== ====
@ -1647,7 +1647,7 @@ on one chain and the fork is resolved.
[[blockchainwithforks]] [[blockchainwithforks]]
.A blockchain with forks .A blockchain with forks
image::../images/fork.dot.png[A blockchain with forks] image::images/fork.dot.png[A blockchain with forks]
Later, however, at block height 6, Later, however, at block height 6,
a new implementation of the client is released with a change in the a new implementation of the client is released with a change in the
@ -2050,7 +2050,7 @@ proposal state changes to +FAILED+, indicating a rejected proposal.
[[bip9states]] [[bip9states]]
.BIP9 state transition diagram .BIP9 state transition diagram
image::../images/mbc2_1010.png[BIP9 Proposal State Transition Diagram] image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram]
BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+ BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
and associated BIPs (68, 112, 113). The proposal named "csv" was and associated BIPs (68, 112, 113). The proposal named "csv" was

20
chapters/network.adoc → network.adoc
View File

@ -123,7 +123,7 @@ miners receive that block.
[[mining_race]] [[mining_race]]
.A blockchain fork requiring a mining race .A blockchain fork requiring a mining race
image::../images/race1.dot.png["Mining race"] image::images/race1.dot.png["Mining race"]
In 2015, a new version of Bitcoin Core added a feature called In 2015, a new version of Bitcoin Core added a feature called
_compact block relay_ (specified in BIP152) that allows transferring new _compact block relay_ (specified in BIP152) that allows transferring new
@ -192,7 +192,7 @@ quickly announcing blocks).
// released into the public domain by Nicolas Dorier // released into the public domain by Nicolas Dorier
[[bip152_illustration]] [[bip152_illustration]]
.BIP152 modes compared (from BIP152). They grey bar indicates the time it takes the node to validate the block .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/bip152.png["BIP152"]
The names of the two methods (which are taken from BIP152) can be a bit 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 confusing. Low-bandwidth mode saves bandwidth by not sending blocks in
@ -324,7 +324,7 @@ use the newly discovered peers.
[[network_handshake]] [[network_handshake]]
.The initial handshake between peers .The initial handshake between peers
image::../images/mbc2_0804.png["NetworkHandshake"] image::images/mbc2_0804.png["NetworkHandshake"]
Once one or more connections are established, the new node will send an Once one or more connections are established, the new node will send an
+addr+ message containing its own IP address to its neighbors. The +addr+ message containing its own IP address to its neighbors. The
@ -340,7 +340,7 @@ discovery")))shows the address discovery protocol.
[[address_propagation]] [[address_propagation]]
.Address propagation and discovery .Address propagation and discovery
image::../images/mbc2_0805.png["AddressPropagation"] image::images/mbc2_0805.png["AddressPropagation"]
A node must connect to a few different peers in order to establish A node must connect to a few different peers in order to establish
diverse paths into the Bitcoin network. Paths are not reliable—nodes diverse paths into the Bitcoin network. Paths are not reliable—nodes
@ -600,7 +600,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/mbc2_0807.png["Header synchronization"] image::images/mbc2_0807.png["Header synchronization"]
Block headers allow a lightweight client to verify that any individual block Block headers allow a lightweight client to verify that any individual block
belongs to the blockchain with the most proof of work, but they don't belongs to the blockchain with the most proof of work, but they don't
@ -673,7 +673,7 @@ hash functions to demonstrate how bloom filters work.
[[bloom1]] [[bloom1]]
.An example of a simplistic bloom filter, with a 16-bit field and three hash functions .An example of a simplistic bloom filter, with a 16-bit field and three hash functions
image::../images/mbc2_0808.png["Bloom1"] image::images/mbc2_0808.png["Bloom1"]
The bloom filter is initialized so that the array of bits is all zeros. The bloom filter is initialized so that the array of bits is all zeros.
To add a pattern to the bloom filter, the pattern is hashed by each hash To add a pattern to the bloom filter, the pattern is hashed by each hash
@ -704,14 +704,14 @@ less accuracy.
[[bloom2]] [[bloom2]]
.Adding a pattern "A" to our simple bloom filter .Adding a pattern "A" to our simple bloom filter
image::../images/mbc2_0809.png["Bloom2"] image::images/mbc2_0809.png["Bloom2"]
<<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter. <<bloom3>> is an example of adding a second pattern "B" to the simple bloom filter.
[[bloom3]] [[bloom3]]
[role="smallereighty"] [role="smallereighty"]
.Adding a second pattern "B" to our simple bloom filter .Adding a second pattern "B" to our simple bloom filter
image::../images/mbc2_0810.png["Bloom3"] image::images/mbc2_0810.png["Bloom3"]
To test if a pattern is part of a bloom filter, the pattern is hashed by 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 each hash function and the resulting bit pattern is tested against the
@ -728,7 +728,7 @@ pattern is probably a match.
[[bloom4]] [[bloom4]]
[role="smallereighty"] [role="smallereighty"]
.Testing the existence of pattern "X" in the bloom filter. The result is a probabilistic positive match, meaning "Maybe." .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/mbc2_0811.png["Bloom4"]
On the contrary, if a pattern is tested against the bloom filter and any 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 one of the bits is set to +0+, this proves that the pattern was not
@ -742,7 +742,7 @@ pattern is definitely not a match.
[[bloom5]] [[bloom5]]
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!" .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/mbc2_0812.png[]
=== How Lightweight Clients Use Bloom Filters === How Lightweight Clients Use Bloom Filters

18
chapters/overview.adoc → overview.adoc
View File

@ -34,7 +34,7 @@ relationships and flows between them.
[[bitcoin-overview]] [[bitcoin-overview]]
.Bitcoin overview .Bitcoin overview
image::../images/mbc2_0201.png["Bitcoin Overview"] image::images/mbc2_0201.png["Bitcoin Overview"]
((("Bitcoin Block Explorer")))Popular blockchain explorers include: ((("Bitcoin Block Explorer")))Popular blockchain explorers include:
@ -99,7 +99,7 @@ TODO: Replace QR code with test-BTC address
[[invoice-QR]] [[invoice-QR]]
.Invoice QR code .Invoice QR code
image::../images/mbc2_0202.png["payment-request"] image::images/mbc2_0202.png["payment-request"]
[TIP] [TIP]
==== ====
@ -190,7 +190,7 @@ transaction over to a new owner identified by a Bitcoin address.
[[transaction-double-entry]] [[transaction-double-entry]]
.Transaction as double-entry bookkeeping .Transaction as double-entry bookkeeping
image::../images/mbc2_0203.png["Transaction Double-Entry"] image::images/mbc2_0203.png["Transaction Double-Entry"]
==== Transaction Chains ==== Transaction Chains
@ -236,7 +236,7 @@ change.
[[transaction-chain]] [[transaction-chain]]
.A chain of transactions, where the output of one transaction is the input of the next transaction .A chain of transactions, where the output of one transaction is the input of the next transaction
image::../images/transaction-chain.png["Transaction chain"] image::images/transaction-chain.png["Transaction chain"]
[TIP] [TIP]
==== ====
@ -310,7 +310,7 @@ transaction has one input and two outputs and is shown in
[[transaction-common]] [[transaction-common]]
.Most common transaction .Most common transaction
image::../images/mbc2_0205.png["Common Transaction"] image::images/mbc2_0205.png["Common Transaction"]
Another common form of transaction is a _consolidation transaction_ that spends several inputs Another common form of transaction is a _consolidation transaction_ that spends several inputs
into a single output (<<transaction-consolidating>>). This represents into a single output (<<transaction-consolidating>>). This represents
@ -320,7 +320,7 @@ generated by wallets and businesses to clean up lots of smaller amounts.
[[transaction-consolidating]] [[transaction-consolidating]]
.Consolidation transaction aggregating funds .Consolidation transaction aggregating funds
image::../images/mbc2_0206.png["Aggregating Transaction"] image::images/mbc2_0206.png["Aggregating Transaction"]
Finally, another transaction form that is seen often on the bitcoin Finally, another transaction form that is seen often on the bitcoin
ledger is _payment batching_ that pays to multiple outputs ledger is _payment batching_ that pays to multiple outputs
@ -331,7 +331,7 @@ employees.((("", startref="Tover02")))
[[transaction-distributing]] [[transaction-distributing]]
.Batch transaction distributing funds .Batch transaction distributing funds
image::../images/mbc2_0207.png["Distributing Transaction"] image::images/mbc2_0207.png["Distributing Transaction"]
=== Constructing a Transaction === Constructing a Transaction
@ -653,7 +653,7 @@ startref="MACover02")))
[[block-alice1]] [[block-alice1]]
.Alice's transaction included in a block .Alice's transaction included in a block
image::../images/mbc2_0209.png["Alice's transaction included in a block"] image::images/mbc2_0209.png["Alice's transaction included in a block"]
=== Spending the Transaction === Spending the Transaction
@ -681,7 +681,7 @@ look like <<block-alice2>>.
[[block-alice2]] [[block-alice2]]
.Alice's transaction as part of a transaction chain from Joe to Gopesh .Alice's transaction as part of a transaction chain from Joe to Gopesh
image::../images/mbc2_0210.png["Alice's transaction as part of a transaction chain"] image::images/mbc2_0210.png["Alice's transaction as part of a transaction chain"]
In this chapter, we saw how transactions build a chain that moves value 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 from owner to owner. We also tracked Alice's transaction, from the

4
chapters/preface.asciidoc → preface.asciidoc
View File

@ -69,7 +69,7 @@ If you feel your use of code examples falls outside fair use or the permission g
=== Changes since the previous edition === Changes since the previous edition
include::../meta/third_edition_changes.asciidoc[] include::meta/third_edition_changes.asciidoc[]
=== Bitcoin Addresses and Transactions in This Book === Bitcoin Addresses and Transactions in This Book
@ -207,4 +207,4 @@ Many contributors offered comments, corrections, and additions to the early-rele
Following is a list of notable GitHub contributors, including their GitHub ID in parentheses: Following is a list of notable GitHub contributors, including their GitHub ID in parentheses:
include::../meta/github_contrib.adoc[] include::meta/github_contrib.adoc[]

0
chapters/security.adoc → security.adoc
View File

0
chapters/signatures.adoc → signatures.adoc
View File

5
tools/check
View File

@ -1,5 +1,4 @@
#!/bin/bash -eu #!/bin/bash -eu
mkdir -p build asciidoctor --failure-level=WARN -v book.adoc -o book.html
asciidoctor --failure-level=WARN -v book.adoc -o build/book.html htmlproofer --disable-external book.html
htmlproofer --disable-external build/book.html

12
chapters/transactions.adoc → transactions.adoc
View File

@ -84,7 +84,7 @@ in the transaction and describe any additional fields that they contain.
[[alice_tx_byte_map]] [[alice_tx_byte_map]]
.A byte map of Alice's transaction .A byte map of Alice's transaction
image::../images/tx-map-1.png["A byte map of Alice's transaction"] image::images/tx-map-1.png["A byte map of Alice's transaction"]
[[version]] [[version]]
=== Version === Version
@ -178,7 +178,7 @@ map of those bytes in <<alice_tx_input_map>>.
[[alice_tx_input_map]] [[alice_tx_input_map]]
.Map of bytes in the input field of Alice's transaction .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/input-byte-map.png["map of bytes in the input field of Alice's transaction"]
==== Length of transaction input list ==== Length of transaction input list
@ -544,7 +544,7 @@ as defined by BIP68.
[[bip_68_def_of_nseq]] [[bip_68_def_of_nseq]]
.BIP68 definition of sequence encoding (Source: BIP68) .BIP68 definition of sequence encoding (Source: BIP68)
image::../images/mbc2_0701.png["BIP68 definition of sequence encoding"] image::images/mbc2_0701.png["BIP68 definition of sequence encoding"]
Note that any transaction which sets a relative timelock using sequence Note that any transaction which sets a relative timelock using sequence
also sends the signal for opt-in replace-by-fee as described in 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>>.
[[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/output-byte-map.png["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"]
==== Outputs Count ==== Outputs Count
@ -970,7 +970,7 @@ Alice's transaction in <<alice_tx_witness_map>>:
[[alice_tx_witness_map]] [[alice_tx_witness_map]]
.A byte map of the witness structure from Alice's transaction .A byte map of the witness structure from Alice's transaction
image::../images/witness-byte-map.png["A byte map of the witness from Alice's transaction"] image::images/witness-byte-map.png["A byte map of the witness from Alice's transaction"]
Unlike the inputs and outputs fields, the overall witness structure doesn't Unlike the inputs and outputs fields, the overall witness structure doesn't
start with any indication of the total number of witness stacks it contains. 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]] [[alice_tx_weight_map]]
.A byte map of Alice's transaction .A byte map of Alice's transaction
image::../images/tx-weight-map.png["A weight map of Alice's transaction"] image::images/tx-weight-map.png["A weight map of Alice's transaction"]
[[legacy_serialization]] [[legacy_serialization]]
=== Legacy Serialization === Legacy Serialization

20
chapters/wallets.adoc → wallets.adoc
View File

@ -57,7 +57,7 @@ that could only reasonably be backed up using digital media.
[[Type0_wallet]] [[Type0_wallet]]
[role="smallersixty"] [role="smallersixty"]
.Non-deterministic key generation: a collection of independently generated keys stored in a wallet database .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/mbc2_0501.png["Non-Deterministic Wallet"]
Modern wallet applications don't independently generate keys but instead Modern wallet applications don't independently generate keys but instead
derive them from a single random seed using a repeatable (deterministic) 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]] [[Type1_wallet]]
[role="smallersixty"] [role="smallersixty"]
.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/mbc2_0502.png["Deterministic Wallet"] image::images/mbc2_0502.png["Deterministic Wallet"]
[[public_child_key_derivation]] [[public_child_key_derivation]]
==== 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]] [[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/mbc2_0503.png["HD wallet"] image::images/mbc2_0503.png["HD wallet"]
The tree structure can be used to express additional The tree structure can be used to express additional
organizational meaning, such as when a specific branch of subkeys is organizational meaning, such as when a specific branch of subkeys is
@ -684,7 +684,7 @@ generate a BIP39 recovery code.
[[generating_entropy_and_encoding]] [[generating_entropy_and_encoding]]
[role="smallerseventy"] [role="smallerseventy"]
.Generating entropy and encoding as a recovery code .Generating entropy and encoding as a recovery code
image::../images/mbc2_0506.png["Generating entropy and encoding as a recovery code"] image::images/mbc2_0506.png["Generating entropy and encoding as a recovery code"]
<<table_4-5>> shows the relationship between the size of the entropy <<table_4-5>> shows the relationship between the size of the entropy
data and the length of recovery code in words. data and the length of recovery code in words.
@ -741,7 +741,7 @@ described previously in <<generating_recovery_words>>:
[[fig_5_7]] [[fig_5_7]]
.From recovery code to seed .From recovery code to seed
image::../images/mbc2_0507.png["From recovery code to seed"] image::images/mbc2_0507.png["From recovery code to seed"]
[TIP] [TIP]
==== ====
@ -932,7 +932,7 @@ wallet is shown in <<HDWalletFromSeed>>.
[[HDWalletFromSeed]] [[HDWalletFromSeed]]
.Creating master keys and chain code from a root seed .Creating master keys and chain code from a root seed
image::../images/mbc2_0509.png["HDWalletFromRootSeed"] image::images/mbc2_0509.png["HDWalletFromRootSeed"]
The root seed is input into the HMAC-SHA512 algorithm and the resulting The root seed is input into the HMAC-SHA512 algorithm and the resulting
hash is used to create a _master private key_ (m) and a _master chain hash is used to create a _master private key_ (m) and a _master chain
@ -979,7 +979,7 @@ parent.
[[CKDpriv]] [[CKDpriv]]
.Extending a parent private key to create a child private key .Extending a parent private key to create a child private key
image::../images/mbc2_0510.png["ChildPrivateDerivation"] image::images/mbc2_0510.png["ChildPrivateDerivation"]
Changing the index allows us to extend the parent and create the other Changing the index allows us to extend the parent and create the other
children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each
@ -1157,7 +1157,7 @@ mechanism for extending a parent public key to derive child public keys.
[[CKDpub]] [[CKDpub]]
.Extending a parent public key to create a child public key .Extending a parent public key to create a child public key
image::../images/mbc2_0511.png["ChildPublicDerivation"] image::images/mbc2_0511.png["ChildPublicDerivation"]
==== Using an Extended Public Key on a Web Store ==== Using an Extended Public Key on a Web Store
@ -1209,7 +1209,7 @@ never export private keys--those always remain on the device.
[[export_xpub]] [[export_xpub]]
.Exporting an xpub from a Trezor hardware signing device .Exporting an xpub from a Trezor hardware signing device
image::../images/mbc2_0512.png["Exporting the xpub from the Trezor"] image::images/mbc2_0512.png["Exporting the xpub from the Trezor"]
Gabriel copies the xpub to his web store's Bitcoin payment processing Gabriel copies the xpub to his web store's Bitcoin payment processing
software, such as the widely used open source BTCPay Server. software, such as the widely used open source BTCPay Server.
@ -1240,7 +1240,7 @@ parent public key, as shown in the diagram in <<CKDprime>>.
[[CKDprime]] [[CKDprime]]
.Hardened derivation of a child key; omits the parent public key .Hardened derivation of a child key; omits the parent public key
image::../images/mbc2_0513.png["ChildHardPrivateDerivation"] image::images/mbc2_0513.png["ChildHardPrivateDerivation"]
[role="pagebreak-before"] [role="pagebreak-before"]
When the hardened private derivation function is used, the resulting When the hardened private derivation function is used, the resulting

22
chapters/whitepaper.adoc → whitepaper.adoc
View File

@ -25,7 +25,7 @@ What is needed is an electronic payment system based on cryptographic proof inst
==== Transactions ==== 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. 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/mbc2_abin01.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. 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 ==== 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. 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/mbc2_abin02.png["timestamp server"]
==== Proof-of-Work ==== 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. 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/mbc2_abin03.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. 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
<p>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 <a href="#ref_seven">[7]</a> <a href="#ref_two">[2]</a> <a href="#ref_five">[5]</a>, 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.</p> <p>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 <a href="#ref_seven">[7]</a> <a href="#ref_two">[2]</a> <a href="#ref_five">[5]</a>, 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.</p>
++++ ++++
image::../images/mbc2_abin04.png["disk"] image::images/mbc2_abin04.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. 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 ==== 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. 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/mbc2_abin05.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. 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 ==== 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. 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/mbc2_abin06.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. 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 ==== 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. 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/mbc2_abin07.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. 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.
@ -113,7 +113,7 @@ q = probability the attacker finds the next block
q~z~ = probability the attacker will ever catch up from z blocks behind q~z~ = probability the attacker will ever catch up from z blocks behind
image::../images/mbc2_abin08.png["eq1"] image::images/mbc2_abin08.png["eq1"]
Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.
@ -123,15 +123,15 @@ The receiver generates a new key pair and gives the public key to the sender sho
The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value: The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value:
image::../images/mbc2_abin09.png["eq2"] image::images/mbc2_abin09.png["eq2"]
To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point: To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:
image::../images/mbc2_abin10.png["eq3"] image::images/mbc2_abin10.png["eq3"]
Rearranging to avoid summing the infinite tail of the distribution... Rearranging to avoid summing the infinite tail of the distribution...
image::../images/mbc2_abin11.png["eq4"] image::images/mbc2_abin11.png["eq4"]
Converting to C code... Converting to C code...