mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-25 01:18:18 +00:00
Move chapters to top level directory to fix Atlas build issue
They use "safe" build mode which doesn't let me reference arbitrary diroctories in include files.
This commit is contained in:
David A. Harding
parent
67a69200f7
commit
7da725a096
@ -452,7 +452,7 @@ cases", "buying coffee", startref="alicetwelve")))
|
||||
|
||||
[[payment_channel]]
|
||||
.A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions
|
||||
image::../images/mbc2_1204.png["A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions"]
|
||||
image::images/mbc2_1204.png["A payment channel between Bob and Alice, showing the funding, commitment, and settlement transactions"]
|
||||
|
||||
==== Simple Payment Channel Example
|
||||
|
||||
@ -478,7 +478,7 @@ streaming service from Fabian using a payment channel.
|
||||
|
||||
[[emma_fabian_streaming_video]]
|
||||
.Emma purchases streaming video from Fabian with a payment channel, paying for each second of video
|
||||
image::../images/mbc2_1205.png["Emma purchases streaming video from Fabian with a payment channel, paying for each second of video"]
|
||||
image::images/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
|
||||
both the payment channel and the video streaming. Emma is running the
|
||||
@ -554,7 +554,7 @@ participants.((("", startref="PSCexample12")))
|
||||
|
||||
[[video_payment_channel]]
|
||||
.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
|
||||
image::../images/mbc2_1206.png["Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel"]
|
||||
image::images/mbc2_1206.png["Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel"]
|
||||
|
||||
==== Making Trustless Channels
|
||||
|
||||
@ -620,7 +620,7 @@ commitments become valid.
|
||||
|
||||
[[timelocked_commitments]]
|
||||
.Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid
|
||||
image::../images/mbc2_1207.png["Each commitment sets a shorter timelock, allowing it to be spent before the previous commitments become valid"]
|
||||
image::images/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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
Eric by a payment channel. Creating a payment channel requires a funding
|
||||
@ -1030,7 +1030,7 @@ payment channels connecting the participants.
|
||||
|
||||
[[ln_payment_process]]
|
||||
.Step-by-step payment routing through a Lightning Network
|
||||
image::../images/mbc2_1210.png["Step-by-step payment routing through a Lightning Network"]
|
||||
image::images/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
|
||||
her payment channel to Bob and has the ability to discover routes
|
||||
36
atlas.json
36
atlas.json
@ -6,24 +6,24 @@
|
||||
"copyright.html",
|
||||
"dedication.html",
|
||||
"toc.html",
|
||||
"chapters/preface.asciidoc",
|
||||
"chapters/intro.adoc",
|
||||
"chapters/overview.adoc",
|
||||
"chapters/bitcoin-core.adoc",
|
||||
"chapters/keys.adoc",
|
||||
"chapters/wallets.adoc",
|
||||
"chapters/transactions.adoc",
|
||||
"chapters/authorization-authentication.adoc",
|
||||
"chapters/signatures.adoc",
|
||||
"chapters/fees.adoc",
|
||||
"chapters/network.adoc",
|
||||
"chapters/blockchain.adoc",
|
||||
"chapters/mining.adoc",
|
||||
"chapters/security.adoc",
|
||||
"chapters/applications.adoc",
|
||||
"chapters/whitepaper.adoc",
|
||||
"chapters/errata.adoc",
|
||||
"chapters/bips.adoc",
|
||||
"preface.asciidoc",
|
||||
"intro.adoc",
|
||||
"overview.adoc",
|
||||
"bitcoin-core.adoc",
|
||||
"keys.adoc",
|
||||
"wallets.adoc",
|
||||
"transactions.adoc",
|
||||
"authorization-authentication.adoc",
|
||||
"signatures.adoc",
|
||||
"fees.adoc",
|
||||
"network.adoc",
|
||||
"blockchain.adoc",
|
||||
"mining.adoc",
|
||||
"security.adoc",
|
||||
"applications.adoc",
|
||||
"whitepaper.adoc",
|
||||
"errata.adoc",
|
||||
"bips.adoc",
|
||||
"author_bio.html"
|
||||
],
|
||||
"formats": {
|
||||
|
||||
@ -134,7 +134,7 @@ validation.
|
||||
|
||||
[[input_and_output_scripts_legacy]]
|
||||
.Combining input and output scripts to evaluate a transaction script
|
||||
image::../images/mbc2_0603.png["input_and_output_scripts"]
|
||||
image::images/mbc2_0603.png["input_and_output_scripts"]
|
||||
|
||||
===== The script execution stack
|
||||
|
||||
@ -221,7 +221,7 @@ Wiki's script page].
|
||||
|
||||
[[simplemath_script]]
|
||||
.Bitcoin's script validation doing simple math
|
||||
image::../images/mbc2_0604.png["TxScriptSimpleMathExample"]
|
||||
image::images/mbc2_0604.png["TxScriptSimpleMathExample"]
|
||||
|
||||
[role="pagebreak-before"]
|
||||
The following is a slightly more complex script, which calculates
|
||||
@ -310,11 +310,11 @@ startref="Stransact06")))
|
||||
|
||||
[[P2PubKHash1]]
|
||||
.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]]
|
||||
.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]]
|
||||
=== Scripted multisignatures
|
||||
@ -1668,7 +1668,7 @@ of the three authorization conditions in <<diagram_mast1>>.
|
||||
|
||||
[[diagram_mast1]]
|
||||
.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
|
||||
authorization condition is a member of the merkle tree without
|
||||
@ -1679,7 +1679,7 @@ specified at spend time.
|
||||
|
||||
[[diagram_mast2]]
|
||||
.A MAST membership proof for one of the sub-scripts
|
||||
image::../images/mast2.dot.png["A MAST membership proof for one of the sub-scripts"]
|
||||
image::images/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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
extremely efficient and very private. It's even more private than it
|
||||
@ -55,7 +55,7 @@ Core.((("Bitcoin Core", "architecture")))
|
||||
|
||||
[[bitcoin_core_architecture]]
|
||||
.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
|
||||
major parts of the system, the Bitcoin whitepaper describes several
|
||||
@ -1058,7 +1058,7 @@ Core.
|
||||
====
|
||||
[source,python]
|
||||
----
|
||||
include::../code/rpc_example.py[]
|
||||
include::code/rpc_example.py[]
|
||||
----
|
||||
====
|
||||
|
||||
@ -1085,7 +1085,7 @@ change back to Alice.
|
||||
====
|
||||
[source,python]
|
||||
----
|
||||
include::../code/rpc_transaction.py[]
|
||||
include::code/rpc_transaction.py[]
|
||||
----
|
||||
====
|
||||
|
||||
@ -1112,7 +1112,7 @@ value.((("", startref="alicethree")))
|
||||
====
|
||||
[source,python]
|
||||
----
|
||||
include::../code/rpc_block.py[]
|
||||
include::code/rpc_block.py[]
|
||||
----
|
||||
====
|
||||
|
||||
@ -303,7 +303,7 @@ references in the +previousblockhash+ field.
|
||||
[[chain_of_blocks]]
|
||||
[role="smallerfourtyfive"]
|
||||
.Blocks linked in a chain by each referencing the previous block header hash
|
||||
image::../images/mbc2_0901.png[]
|
||||
image::images/mbc2_0901.png[]
|
||||
|
||||
[[merkle_trees]]
|
||||
=== Merkle Trees
|
||||
@ -368,7 +368,7 @@ of the nodes.
|
||||
|
||||
[[simple_merkle]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
****
|
||||
@ -403,7 +403,7 @@ trees:
|
||||
|
||||
[[cve_tree]]
|
||||
.Two Bitcoin-style merkle tree with the same root but a different number of leaves
|
||||
image::../images/cve-2012-2459.dot.png["Two Bitcoin-style merkle tree with the same root but a different number of leaves"]
|
||||
image::images/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
|
||||
6 are repeated) result in the same root hash A (because the hash of both
|
||||
@ -448,7 +448,7 @@ block.
|
||||
|
||||
[[merkle_tree_large]]
|
||||
.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
|
||||
included in the block by producing a merkle path that is only four
|
||||
@ -463,7 +463,7 @@ diagram).
|
||||
|
||||
[[merkle_tree_path]]
|
||||
.A merkle path used to prove inclusion of a data element
|
||||
image::../images/mbc2_0905.png["merkle_tree_path"]
|
||||
image::images/mbc2_0905.png["merkle_tree_path"]
|
||||
|
||||
The efficiency of merkle trees becomes obvious as the scale increases.
|
||||
The largest possible block can hold almost 16,000 transactions in 4,000,000
|
||||
36
book.adoc
36
book.adoc
@ -1,37 +1,37 @@
|
||||
= 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[]
|
||||
|
||||
@ -399,7 +399,7 @@ Alice uses the _Receive_ button, which displays a QR code, shown in <<wallet_rec
|
||||
|
||||
[[wallet_receive]]
|
||||
.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.
|
||||
|
||||
@ -497,7 +497,7 @@ faster the transaction will be confirmed (see <<confirmations>>).
|
||||
[[wallet-send]]
|
||||
[role="smallereighty"]
|
||||
.Bitcoin wallet send screen
|
||||
image::../images/send.png["Wallet send screen. Image derived from Bitcoin Design Guide CC-BY"]
|
||||
image::images/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
|
||||
amount, because he is about to transmit money and mistakes will soon become
|
||||
@ -20,7 +20,7 @@ that itself commits to Bob's public key and other transaction details.
|
||||
|
||||
[[pay-to-pure-pubkey]]
|
||||
.Transaction chain from original Bitcoin paper
|
||||
image::../images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"]
|
||||
image::images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"]
|
||||
|
||||
We'll examine public keys, private keys, signatures, and hash functions
|
||||
in this chapter, and then use all of them together to describe
|
||||
@ -178,7 +178,7 @@ by Bitcoin.
|
||||
[[ecc-curve]]
|
||||
[role="smallerthirty"]
|
||||
.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
|
||||
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]]
|
||||
[role="smallersixty"]
|
||||
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
|
||||
image::../images/mbc2_0403.png["ecc-over-F17-math"]
|
||||
image::images/mbc2_0403.png["ecc-over-F17-math"]
|
||||
|
||||
So, for example, the following is a point P with coordinates (x,y) that
|
||||
is a point on the +secp256k1+ curve:
|
||||
@ -386,7 +386,7 @@ library] to do the elliptic curve math.
|
||||
|
||||
[[ecc_illustrated]]
|
||||
.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve
|
||||
image::../images/mbc2_0404.png["ecc_illustrated"]
|
||||
image::images/mbc2_0404.png["ecc_illustrated"]
|
||||
|
||||
=== Output and Input Scripts
|
||||
|
||||
@ -428,7 +428,7 @@ Bitcoin protocol.
|
||||
|
||||
[[bitcoin_01_send]]
|
||||
.Early send screen for Bitcoin via https://web.archive.org/web/20090722011820/https://bitcoin.org/[The Internet Archive]
|
||||
image::../images/bitcoin-01-send.png["Early Bitcoin send screen"]
|
||||
image::images/bitcoin-01-send.png["Early Bitcoin send screen"]
|
||||
|
||||
If Alice entered Bob's IP address in Bitcoin 0.1, her full node would
|
||||
establish a connection with his full node and receive a new public key
|
||||
@ -687,7 +687,7 @@ encoding process.
|
||||
|
||||
[[base58check_encoding]]
|
||||
.Base58Check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data
|
||||
image::../images/mbc2_0406.png["Base58CheckEncoding"]
|
||||
image::images/mbc2_0406.png["Base58CheckEncoding"]
|
||||
|
||||
In Bitcoin, other data besides public key commitments are presented to the user in
|
||||
base58check encoding to make that data compact, easy to read, and easy to detect
|
||||
@ -720,7 +720,7 @@ into a Bitcoin address in <<pubkey_to_address>>.
|
||||
|
||||
[[pubkey_to_address]]
|
||||
.Public key to Bitcoin address: conversion of a public key into a Bitcoin address
|
||||
image::../images/mbc2_0405.png["pubkey_to_address"]
|
||||
image::images/mbc2_0405.png["pubkey_to_address"]
|
||||
|
||||
[[comp_pub]]
|
||||
=== Compressed public keys
|
||||
@ -811,7 +811,7 @@ addresses.
|
||||
[[pubkey_compression]]
|
||||
[role="smallerseventy"]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
Christmas and New Year's themes. Others are designed for storage in a
|
||||
@ -1687,7 +1687,7 @@ startref="Wpaper04")))((("", startref="paperw04")))
|
||||
|
||||
[[paper_wallet_spw]]
|
||||
.An example of a paper wallet with additional copies of the keys on a backup "stub"
|
||||
image::../images/mbc2_0412.png[]
|
||||
image::images/mbc2_0412.png[]
|
||||
|
||||
From the original public-key focused design of Bitcoin to modern addresses
|
||||
and scripts like bech32m and pay-to-taproot--and even addresses for
|
||||
@ -126,7 +126,7 @@ time, as the issuance of currency decreases.
|
||||
|
||||
[[bitcoin_money_supply]]
|
||||
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
|
||||
image::../images/mbc2_1001.png["BitcoinMoneySupply"]
|
||||
image::images/mbc2_1001.png["BitcoinMoneySupply"]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@ -145,7 +145,7 @@ bitcoin that will be issued.
|
||||
====
|
||||
[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]]
|
||||
.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,
|
||||
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]]
|
||||
.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+
|
||||
and associated BIPs (68, 112, 113). The proposal named "csv" was
|
||||
@ -123,7 +123,7 @@ miners receive that block.
|
||||
|
||||
[[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
|
||||
_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
|
||||
[[bip152_illustration]]
|
||||
.BIP152 modes compared (from BIP152). They grey bar indicates the time it takes the node to validate the block
|
||||
image::../images/bip152.png["BIP152"]
|
||||
image::images/bip152.png["BIP152"]
|
||||
|
||||
The names of the two methods (which are taken from BIP152) can be a bit
|
||||
confusing. Low-bandwidth mode saves bandwidth by not sending blocks in
|
||||
@ -324,7 +324,7 @@ use the newly discovered peers.
|
||||
|
||||
[[network_handshake]]
|
||||
.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
|
||||
+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 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
|
||||
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]]
|
||||
.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
|
||||
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]]
|
||||
.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.
|
||||
To add a pattern to the bloom filter, the pattern is hashed by each hash
|
||||
@ -704,14 +704,14 @@ less accuracy.
|
||||
|
||||
[[bloom2]]
|
||||
.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]]
|
||||
[role="smallereighty"]
|
||||
.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
|
||||
each hash function and the resulting bit pattern is tested against the
|
||||
@ -728,7 +728,7 @@ pattern is probably a match.
|
||||
[[bloom4]]
|
||||
[role="smallereighty"]
|
||||
.Testing the existence of pattern "X" in the bloom filter. The result is a probabilistic positive match, meaning "Maybe."
|
||||
image::../images/mbc2_0811.png["Bloom4"]
|
||||
image::images/mbc2_0811.png["Bloom4"]
|
||||
|
||||
On the contrary, if a pattern is tested against the bloom filter and any
|
||||
one of the bits is set to +0+, this proves that the pattern was not
|
||||
@ -742,7 +742,7 @@ pattern is definitely not a match.
|
||||
|
||||
[[bloom5]]
|
||||
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
|
||||
image::../images/mbc2_0812.png[]
|
||||
image::images/mbc2_0812.png[]
|
||||
|
||||
=== How Lightweight Clients Use Bloom Filters
|
||||
|
||||
@ -34,7 +34,7 @@ relationships and flows between them.
|
||||
|
||||
[[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:
|
||||
|
||||
@ -99,7 +99,7 @@ TODO: Replace QR code with test-BTC address
|
||||
|
||||
[[invoice-QR]]
|
||||
.Invoice QR code
|
||||
image::../images/mbc2_0202.png["payment-request"]
|
||||
image::images/mbc2_0202.png["payment-request"]
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -190,7 +190,7 @@ transaction over to a new owner identified by a Bitcoin address.
|
||||
|
||||
[[transaction-double-entry]]
|
||||
.Transaction as double-entry bookkeeping
|
||||
image::../images/mbc2_0203.png["Transaction Double-Entry"]
|
||||
image::images/mbc2_0203.png["Transaction Double-Entry"]
|
||||
|
||||
==== Transaction Chains
|
||||
|
||||
@ -236,7 +236,7 @@ change.
|
||||
|
||||
[[transaction-chain]]
|
||||
.A chain of transactions, where the output of one transaction is the input of the next transaction
|
||||
image::../images/transaction-chain.png["Transaction chain"]
|
||||
image::images/transaction-chain.png["Transaction chain"]
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -310,7 +310,7 @@ transaction has one input and two outputs and is shown in
|
||||
|
||||
[[transaction-common]]
|
||||
.Most common transaction
|
||||
image::../images/mbc2_0205.png["Common Transaction"]
|
||||
image::images/mbc2_0205.png["Common Transaction"]
|
||||
|
||||
Another common form of transaction is a _consolidation transaction_ that spends several inputs
|
||||
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]]
|
||||
.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
|
||||
ledger is _payment batching_ that pays to multiple outputs
|
||||
@ -331,7 +331,7 @@ employees.((("", startref="Tover02")))
|
||||
|
||||
[[transaction-distributing]]
|
||||
.Batch transaction distributing funds
|
||||
image::../images/mbc2_0207.png["Distributing Transaction"]
|
||||
image::images/mbc2_0207.png["Distributing Transaction"]
|
||||
|
||||
=== Constructing a Transaction
|
||||
|
||||
@ -653,7 +653,7 @@ startref="MACover02")))
|
||||
|
||||
[[block-alice1]]
|
||||
.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
|
||||
|
||||
@ -681,7 +681,7 @@ look like <<block-alice2>>.
|
||||
|
||||
[[block-alice2]]
|
||||
.Alice's transaction as part of a transaction chain from Joe to Gopesh
|
||||
image::../images/mbc2_0210.png["Alice's transaction as part of a transaction chain"]
|
||||
image::images/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
|
||||
from owner to owner. We also tracked Alice's transaction, from the
|
||||
@ -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
|
||||
|
||||
include::../meta/third_edition_changes.asciidoc[]
|
||||
include::meta/third_edition_changes.asciidoc[]
|
||||
|
||||
=== 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:
|
||||
|
||||
include::../meta/github_contrib.adoc[]
|
||||
include::meta/github_contrib.adoc[]
|
||||
@ -1,5 +1,4 @@
|
||||
#!/bin/bash -eu
|
||||
|
||||
mkdir -p build
|
||||
asciidoctor --failure-level=WARN -v book.adoc -o build/book.html
|
||||
htmlproofer --disable-external build/book.html
|
||||
asciidoctor --failure-level=WARN -v book.adoc -o book.html
|
||||
htmlproofer --disable-external book.html
|
||||
|
||||
@ -84,7 +84,7 @@ in the transaction and describe any additional fields that they contain.
|
||||
|
||||
[[alice_tx_byte_map]]
|
||||
.A byte map of Alice's transaction
|
||||
image::../images/tx-map-1.png["A byte map of Alice's transaction"]
|
||||
image::images/tx-map-1.png["A byte map of Alice's transaction"]
|
||||
|
||||
[[version]]
|
||||
=== Version
|
||||
@ -178,7 +178,7 @@ map of those bytes in <<alice_tx_input_map>>.
|
||||
|
||||
[[alice_tx_input_map]]
|
||||
.Map of bytes in the input field of Alice's transaction
|
||||
image::../images/input-byte-map.png["map of bytes in the input field of Alice's transaction"]
|
||||
image::images/input-byte-map.png["map of bytes in the input field of Alice's transaction"]
|
||||
|
||||
==== Length of transaction input list
|
||||
|
||||
@ -544,7 +544,7 @@ as defined by BIP68.
|
||||
|
||||
[[bip_68_def_of_nseq]]
|
||||
.BIP68 definition of sequence encoding (Source: BIP68)
|
||||
image::../images/mbc2_0701.png["BIP68 definition of sequence encoding"]
|
||||
image::images/mbc2_0701.png["BIP68 definition of sequence encoding"]
|
||||
|
||||
Note that any transaction which sets a relative timelock using sequence
|
||||
also sends the signal for opt-in replace-by-fee as described in
|
||||
@ -560,7 +560,7 @@ a map of those bytes in <<output-byte-map>>.
|
||||
|
||||
[[output-byte-map]]
|
||||
.A byte map of the outputs field from Alice's transaction
|
||||
image::../images/output-byte-map.png["A byte map of the outputs field from Alice's transaction"]
|
||||
image::images/output-byte-map.png["A byte map of the outputs field from Alice's transaction"]
|
||||
|
||||
==== Outputs Count
|
||||
|
||||
@ -970,7 +970,7 @@ Alice's transaction in <<alice_tx_witness_map>>:
|
||||
|
||||
[[alice_tx_witness_map]]
|
||||
.A byte map of the witness structure from Alice's transaction
|
||||
image::../images/witness-byte-map.png["A byte map of the witness from Alice's transaction"]
|
||||
image::images/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
|
||||
start with any indication of the total number of witness stacks it contains.
|
||||
@ -1152,7 +1152,7 @@ the difference in size between the various fields in the two images.
|
||||
|
||||
[[alice_tx_weight_map]]
|
||||
.A byte map of Alice's transaction
|
||||
image::../images/tx-weight-map.png["A weight map of Alice's transaction"]
|
||||
image::images/tx-weight-map.png["A weight map of Alice's transaction"]
|
||||
|
||||
[[legacy_serialization]]
|
||||
=== Legacy Serialization
|
||||
@ -57,7 +57,7 @@ that could only reasonably be backed up using digital media.
|
||||
[[Type0_wallet]]
|
||||
[role="smallersixty"]
|
||||
.Non-deterministic key generation: a collection of independently generated keys stored in a wallet database
|
||||
image::../images/mbc2_0501.png["Non-Deterministic Wallet"]
|
||||
image::images/mbc2_0501.png["Non-Deterministic Wallet"]
|
||||
|
||||
Modern wallet applications don't independently generate keys but instead
|
||||
derive them from a single random seed using a repeatable (deterministic)
|
||||
@ -113,7 +113,7 @@ possible to store private keys more securely than public keys.
|
||||
[[Type1_wallet]]
|
||||
[role="smallersixty"]
|
||||
.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
|
||||
image::../images/mbc2_0502.png["Deterministic Wallet"]
|
||||
image::images/mbc2_0502.png["Deterministic Wallet"]
|
||||
|
||||
[[public_child_key_derivation]]
|
||||
==== Public Child Key Derivation
|
||||
@ -198,7 +198,7 @@ limit on the depth of the tree. This tree structure is illustrated in
|
||||
|
||||
[[Type2_wallet]]
|
||||
.HD wallet: a tree of keys generated from a single seed
|
||||
image::../images/mbc2_0503.png["HD wallet"]
|
||||
image::images/mbc2_0503.png["HD wallet"]
|
||||
|
||||
The tree structure can be used to express additional
|
||||
organizational meaning, such as when a specific branch of subkeys is
|
||||
@ -684,7 +684,7 @@ generate a BIP39 recovery code.
|
||||
[[generating_entropy_and_encoding]]
|
||||
[role="smallerseventy"]
|
||||
.Generating entropy and encoding as a recovery code
|
||||
image::../images/mbc2_0506.png["Generating entropy and encoding as a recovery code"]
|
||||
image::images/mbc2_0506.png["Generating entropy and encoding as a recovery code"]
|
||||
|
||||
<<table_4-5>> shows the relationship between the size of the entropy
|
||||
data and the length of recovery code in words.
|
||||
@ -741,7 +741,7 @@ described previously in <<generating_recovery_words>>:
|
||||
|
||||
[[fig_5_7]]
|
||||
.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]
|
||||
====
|
||||
@ -932,7 +932,7 @@ wallet is shown in <<HDWalletFromSeed>>.
|
||||
|
||||
[[HDWalletFromSeed]]
|
||||
.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
|
||||
hash is used to create a _master private key_ (m) and a _master chain
|
||||
@ -979,7 +979,7 @@ parent.
|
||||
|
||||
[[CKDpriv]]
|
||||
.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
|
||||
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]]
|
||||
.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
|
||||
|
||||
@ -1209,7 +1209,7 @@ never export private keys--those always remain on the device.
|
||||
|
||||
[[export_xpub]]
|
||||
.Exporting an xpub from a Trezor hardware signing device
|
||||
image::../images/mbc2_0512.png["Exporting the xpub from the Trezor"]
|
||||
image::images/mbc2_0512.png["Exporting the xpub from the Trezor"]
|
||||
|
||||
Gabriel copies the xpub to his web store's Bitcoin payment processing
|
||||
software, such as the widely used open source BTCPay Server.
|
||||
@ -1240,7 +1240,7 @@ parent public key, as shown in the diagram in <<CKDprime>>.
|
||||
|
||||
[[CKDprime]]
|
||||
.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"]
|
||||
When the hardened private derivation function is used, the resulting
|
||||
@ -25,7 +25,7 @@ What is needed is an electronic payment system based on cryptographic proof inst
|
||||
==== Transactions
|
||||
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
|
||||
|
||||
image::../images/mbc2_abin01.png["Transactions"]
|
||||
image::images/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.
|
||||
|
||||
@ -34,12 +34,12 @@ We need a way for the payee to know that the previous owners did not sign any ea
|
||||
==== Timestamp Server
|
||||
The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
|
||||
|
||||
image::../images/mbc2_abin02.png["timestamp server"]
|
||||
image::images/mbc2_abin02.png["timestamp server"]
|
||||
|
||||
==== Proof-of-Work
|
||||
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
|
||||
|
||||
image::../images/mbc2_abin03.png["pow"]
|
||||
image::images/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.
|
||||
|
||||
@ -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>
|
||||
++++
|
||||
|
||||
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.
|
||||
|
||||
==== Simplified Payment Verification
|
||||
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
|
||||
|
||||
image::../images/mbc2_abin05.png["spv"]
|
||||
image::images/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.
|
||||
|
||||
==== Combining and Splitting Value
|
||||
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
|
||||
|
||||
image::../images/mbc2_abin06.png["combining-splitting"]
|
||||
image::images/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.
|
||||
|
||||
==== Privacy
|
||||
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.
|
||||
|
||||
image::../images/mbc2_abin07.png["privacy"]
|
||||
image::images/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.
|
||||
|
||||
@ -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
|
||||
|
||||
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.
|
||||
|
||||
@ -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:
|
||||
|
||||
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:
|
||||
|
||||
image::../images/mbc2_abin10.png["eq3"]
|
||||
image::images/mbc2_abin10.png["eq3"]
|
||||
|
||||
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...
|
||||
|
||||
Loading…
Reference in New Issue
Block a user