mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-22 16:18:11 +00:00
Renaming figure filerefs
This commit is contained in:
Chris Pappas
parent
7a8a50c975
commit
c44017a5ee
@ -116,12 +116,12 @@ Once Alice has downloaded and installed the Multibit application, she runs it an
|
||||
|
||||
[[multibit-welcome]]
|
||||
.The Multibit Bitcoin Client - Welcome Screen
|
||||
image::images/MultibitWelcome.png["MultibitWelcome"]
|
||||
image::images/msbt_0101.png["MultibitWelcome"]
|
||||
|
||||
Multibit automatically creates a wallet and a new bitcoin address for Alice, which Alice can see by clicking on the "Request" tab:
|
||||
[[multibit-request]]
|
||||
.Alice's new bitcoin address, in the "Request" tab of the Multibit client
|
||||
image::images/MultibitReceive.png["MultibitReceive"]
|
||||
image::images/msbt_0102.png["MultibitReceive"]
|
||||
|
||||
The most important part of this screen is Alice's _bitcoin address_. Like an email address, Alice can share this address and anyone can use it to send money directly to her new wallet. On the screen it appears as a long string of letters and numbers: +1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+. Next to the wallet's bitcoin address, there is a QR code, a form of barcode that contains the same information in a format that can be easily scanned by a smartphone's camera. The QR code is the black and white square on the right side of the window. Alice can copy the bitcoin address or the QR code onto her clipboard by clicking on the copy button adjacent to each of them. Clicking on the QR code itself will magnify it, so that it can be easily scanned by a smartphone camera.
|
||||
|
||||
@ -173,7 +173,7 @@ Next, Joe has to figure out the exchange rate so that he can give the correct am
|
||||
|
||||
[[zeroblock-android]]
|
||||
.ZeroBlock - A bitcoin market-rate application for Android and iOS
|
||||
image::images/zeroblock.png["zeroblock screenshot"]
|
||||
image::images/msbt_0103.png["zeroblock screenshot"]
|
||||
|
||||
Using one of the applications or websites above, Joe determines the price of bitcoin to be approximately $100 US dollars per bitcoin. At that rate he should give Alice 0.10 bitcoin, also known as 100 milliBits, in return for the $10 US dollars she gave him.
|
||||
|
||||
@ -184,7 +184,7 @@ Once Joe has established a fair exchange price, he opens his mobile wallet appli
|
||||
|
||||
[[blockchain-mobile-send]]
|
||||
.Bitcoin mobile wallet - Send bitcoin screen
|
||||
image::images/blockchain-mobile-send.png["blockchain mobile send screen"]
|
||||
image::images/msbt_0104.png["blockchain mobile send screen"]
|
||||
|
||||
In the input field for the bitcoin address, there is a small icon that looks like a QR code. This allows Joe to scan the barcode with his smartphone camera so that he doesn't have to type in Alice's bitcoin address (+1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+), which is quite long and difficult to type. Joe taps on the QR code icon and activates the smartphone camera, scanning the QR code from Alice's printed wallet that she brought with her. The mobile wallet application fills in the bitcoin address and Joe can check that it scanned correctly by comparing a few digits from the address with the address printed by Alice.
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ In the overview diagram below, we see that the bitcoin system consists of users
|
||||
|
||||
[[bitcoin-overview]]
|
||||
.Bitcoin Overview
|
||||
image::images/Bitcoin_Overview.png["Bitcoin Overview"]
|
||||
image::images/msbt_0201.png["Bitcoin Overview"]
|
||||
|
||||
[[cup_of_coffee]]
|
||||
==== Buying a cup of coffee
|
||||
@ -39,7 +39,7 @@ $1.50 USD
|
||||
|
||||
[[payment-request-QR]]
|
||||
.Payment Request QR Code - Hint: Try to scan this!
|
||||
image::images/payment-request-qr.png["payment-request"]
|
||||
image::images/msbt_0202.png["payment-request"]
|
||||
|
||||
[[payment-request-URL]]
|
||||
.The payment request QR code above encodes the following URL, defined in BIP0021
|
||||
@ -83,7 +83,7 @@ Transactions are like lines in a double-entry bookkeeping ledger. In simple term
|
||||
|
||||
[[transaction-double-entry]]
|
||||
.Transaction as Double-Entry Bookkeeping
|
||||
image::images/Transaction_Double_Entry.png["Transaction Double-Entry"]
|
||||
image::images/msbt_0203.png["Transaction Double-Entry"]
|
||||
|
||||
The transaction also contains proof of ownership for each amount of bitcoin (inputs) whose value is transferred, in the form of a digital signature from the owner, which can be independently validated by anyone. In bitcoin terms, "spending" is signing a transaction which transfers value from a previous transaction over to a new owner identified by a bitcoin address.
|
||||
|
||||
@ -96,7 +96,7 @@ _Transactions_ move value *from* _transaction inputs_ *to* _transaction outputs_
|
||||
|
||||
[[blockchain-mnemonic]]
|
||||
.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/msbt_0204.png["Transaction chain"]
|
||||
|
||||
Alice's payment to Bob's Cafe utilizes a previous transaction as its input. In the previous chapter Alice received bitcoin from her friend Joe in return for cash. That transaction has a number of bitcoins locked (encumbered) against Alice's key. Her new transaction to Bob's Cafe references the previous transaction as an input and creates new outputs to pay for the cup of coffee and receive change. The transactions form a chain, where the inputs from the latest transaction correspond to outputs from previous transactions. Alice's key provides the signature which unlocks those previous transaction outputs, thereby proving to the bitcoin network that she owns the funds. She attaches the payment for coffee to Bob's address, thereby "encumbering" that output with the requirement that Bob produces a signature in order to spend that amount. This represents a transfer of value between Alice and Bob.
|
||||
|
||||
@ -106,19 +106,19 @@ The most common form of transaction is a simple payment from one address to anot
|
||||
|
||||
[[transaction-common]]
|
||||
.Most Common Transaction
|
||||
image::images/Bitcoin_Transaction_Structure_Common.png["Common Transaction"]
|
||||
image::images/msbt_0205.png["Common Transaction"]
|
||||
|
||||
Another common form of transaction is a transaction that aggregates several inputs into a single output. This represents the real-world equivalent of exchanging a pile of coins and currency notes for a single larger note. Transactions like these are sometimes generated by wallet applications to clean up lots of smaller amounts that were received as change for payments.
|
||||
|
||||
[[transaction-aggregating]]
|
||||
.Transaction Aggregating Funds
|
||||
image::images/Bitcoin_Transaction_Structure_Aggregating.png["Aggregating Transaction"]
|
||||
image::images/msbt_0206.png["Aggregating Transaction"]
|
||||
|
||||
Finally, another transaction form that is seen often on the bitcoin ledger is a transaction that distributes one input to multiple outputs representing multiple recipients. This type of transaction is sometimes used by commercial entities to distribute funds, such as when processing payroll payments to multiple employees.
|
||||
|
||||
[[transaction-distributing]]
|
||||
.Transaction Distributing Funds
|
||||
image::images/Bitcoin_Transaction_Structure_Distribution.png["Distributing Transaction"]
|
||||
image::images/msbt_0207.png["Distributing Transaction"]
|
||||
|
||||
=== Constructing a Transaction
|
||||
|
||||
@ -179,7 +179,7 @@ The resulting transaction can be seen using a blockchain explorer web applicatio
|
||||
|
||||
[[transaction-alice]]
|
||||
.Alice's transaction to Bob's Cafe
|
||||
image::images/AliceCoffeeTransaction.png["Alice Coffee Transaction"]
|
||||
image::images/msbt_0208.png["Alice Coffee Transaction"]
|
||||
|
||||
[[transaction-alice-url]]
|
||||
[TIP]
|
||||
@ -242,7 +242,7 @@ In the diagram below we can see block #277316, which contains Alice's transactio
|
||||
|
||||
[[block-alice]]
|
||||
.Alice's transaction included in block #277,316
|
||||
image::images/Blockchain_height_and_depth.png["Alice's transaction included in a block"]
|
||||
image::images/msbt_0209.png["Alice's transaction included in a block"]
|
||||
|
||||
=== Spending the transaction
|
||||
|
||||
@ -254,7 +254,7 @@ As Bob spends the payments received from Alice and other customers, he extends t
|
||||
|
||||
[[block-alice]]
|
||||
.Alice's transaction as part of a transaction chain from Joe to Gopesh
|
||||
image::images/Alices_Transaction_Chain.png["Alice's transaction as part of a transaction chain"]
|
||||
image::images/msbt_0210.png["Alice's transaction as part of a transaction chain"]
|
||||
|
||||
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Go to http://bitcoin.org/en/choose-your-wallet and select "Bitcoin Core" to down
|
||||
|
||||
[[bitcoin-choose-client]]
|
||||
.Bitcoin - Choose A Bitcoin Client
|
||||
image::images/bitcoin-choose-client.png["bitcoin choose client"]
|
||||
image::images/msbt_0301.png["bitcoin choose client"]
|
||||
|
||||
==== Running Bitcoin Core for the first time
|
||||
|
||||
@ -24,7 +24,7 @@ Bitcoin Core keeps a full copy of the transaction ledger (blockchain), with ever
|
||||
|
||||
[[bitcoin-qt-firstload]]
|
||||
.Bitcoin Core - The Graphical User Interface, during the blockchain initialization
|
||||
image::images/bitcoin-qt-firstload.png["bitcoin-qt first run"]
|
||||
image::images/msbt_0302.png["bitcoin-qt first run"]
|
||||
|
||||
|
||||
==== Compiling Bitcoin Core from the source code
|
||||
|
||||
@ -38,7 +38,7 @@ A bitcoin wallet contains a collection of key pairs, each consisting of a privat
|
||||
|
||||
[[k_to_K_to_A]]
|
||||
.Private Key, Public Key and Bitcoin Address
|
||||
image::images/privk_to_pubK_to_addressA.png["privk_to_pubK_to_addressA"]
|
||||
image::images/msbt_0401.png["privk_to_pubK_to_addressA"]
|
||||
|
||||
[[private_keys]]
|
||||
==== Private Keys
|
||||
@ -108,7 +108,7 @@ Below we see an example of an elliptic curve, similar to that used by bitcoin:
|
||||
|
||||
[[ecc-curve]]
|
||||
.An Elliptic Curve
|
||||
image::images/ecc-curve.png["ecc-curve"]
|
||||
image::images/msbt_0402.png["ecc-curve"]
|
||||
|
||||
Bitcoin uses a specific elliptic curve and set of mathematical constants, as defined in a standard called +secp256k1+, established by the National Institute of Standards and Technology (NIST). The +secp256k1+ curve is defined by the following function, which produces an elliptic curve:
|
||||
|
||||
@ -134,7 +134,7 @@ Because this curve is defined over a finite field of prime order instead of over
|
||||
|
||||
[[ecc-over-F17-math]]
|
||||
.Elliptic Curve Cryptography: Visualizing an elliptic curve over F(p), with p=17
|
||||
image::images/ecc-over-F17-math.png["ecc-over-F17-math"]
|
||||
image::images/msbt_0403.png["ecc-over-F17-math"]
|
||||
|
||||
So for example, below is a point P with coordinates (x,y) that is a point on the secp256k1 curve. You can check this yourself using Python:
|
||||
----
|
||||
@ -215,7 +215,7 @@ The diagram below shows the process for deriving G, 2G, 4G, as a geometric opera
|
||||
|
||||
[[ecc_illustrated]]
|
||||
.Elliptic Curve Cryptography: Visualizing the multiplication of a point G by an integer k on an elliptic curve
|
||||
image::images/ecc_illustrated.png["ecc_illustrated"]
|
||||
image::images/msbt_0404.png["ecc_illustrated"]
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -254,7 +254,7 @@ Bitcoin addresses are almost always presented to users in an encoding called "Ba
|
||||
|
||||
[[pubkey_to_adddress]]
|
||||
.Public Key to Bitcoin Address: Conversion of a public key into a bitcoin address
|
||||
image::images/PubKey_to_Bitcoin_Address.png["pubkey_to_address"]
|
||||
image::images/msbt_0405.png["pubkey_to_address"]
|
||||
|
||||
==== Base58 and Base58Check Encoding
|
||||
|
||||
@ -288,7 +288,7 @@ The result of the above is now a prefix, the data and a checksum. This result is
|
||||
|
||||
[[base58check_encoding]]
|
||||
.Base58Check Encoding: A base-58, versioned and checksummed format for unambiguously encoding bitcoin data
|
||||
image::images/Base58CheckEncoding.png["Base58CheckEncoding"]
|
||||
image::images/msbt_0406.png["Base58CheckEncoding"]
|
||||
|
||||
In bitcoin, most of the data presented to the user is Base58Check encoded to make it compact, easy to read and easy to detect errors. The version prefix in Base58Check encoding is used to create easily distinguishable formats, which when encoded in Base-58 contain specific characters at the beginning of the Base58Check encoded payload, making it easy for humans to identify the type of data that is encoded and how to use it. This is what differentiates, for example, a Base58Check encoded bitcoin address that starts with a "1" from a Base58Check encoded private key WIF format that starts with a "5". Some example version prefixes and the resulting Base-58 characters are shown below:
|
||||
|
||||
@ -425,7 +425,7 @@ Whereas uncompressed public keys have a prefix of +04+, compressed public keys s
|
||||
|
||||
[[pubkey_compression]]
|
||||
.Public Key Compression
|
||||
image::images/pubkey_compression.png["pubkey_compression"]
|
||||
image::images/msbt_0407.png["pubkey_compression"]
|
||||
|
||||
Here's the same public key generated previously, shown as a +compressed public key+ stored in 264-bits (66 hex digits) with the prefix +03+ indicating the +y+ coordinate is odd:
|
||||
|
||||
@ -562,7 +562,7 @@ In the first implementations of bitcoin clients, wallets were simply collections
|
||||
|
||||
[[Type0_wallet]]
|
||||
.Type-0 Non-Deterministic (Random) Wallet: A Collection of Randomly Generated Keys
|
||||
image::images/non-deterministic_wallet.png["non-deterministic wallet"]
|
||||
image::images/msbt_0408.png["non-deterministic wallet"]
|
||||
|
||||
==== Deterministic (Seeded) Wallets
|
||||
|
||||
@ -623,7 +623,7 @@ Deterministic wallets were developed to make it easy to derive many keys from a
|
||||
|
||||
[[Type2_wallet]]
|
||||
.Type-2 Hierarchical Deterministic Wallet: A Tree of Keys Generated from a Seed
|
||||
image::images/HD_wallet.png["HD wallet"]
|
||||
image::images/msbt_0409.png["HD wallet"]
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -642,7 +642,7 @@ The process of creating the master keys and master chain code for an HD wallet i
|
||||
|
||||
[[HDWalletFromSeed]]
|
||||
.Creating master keys and chain code from a root seed
|
||||
image::images/HDWalletFromRootSeed.png["HDWalletFromRootSeed"]
|
||||
image::images/msbt_0410.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 code_. The master private key (m) then generates a corresponding master public key (M), using the normal elliptic curve multiplication process +m * G+ that we saw previously in this chapter. The chain code is used to introduce entropy in the function that creates child keys from parent keys, as we will see in the next section.
|
||||
|
||||
@ -664,7 +664,7 @@ The parent public key, chain code and the index number are combined and hashed w
|
||||
|
||||
[[CKDpriv]]
|
||||
.Extending a parent private key to create a child private key
|
||||
image::images/ChildPrivateDerivation.png["ChildPrivateDerivation"]
|
||||
image::images/msbt_0411.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 parent key can have 2 billion children keys.
|
||||
|
||||
@ -722,7 +722,7 @@ Another common application of this solution is for cold-storage or hardware wall
|
||||
|
||||
[[CKDpub]]
|
||||
.Extending a parent public key to create a child public key
|
||||
image::images/ChildPublicDerivation.png["ChildPublicDerivation"]
|
||||
image::images/msbt_0412.png["ChildPublicDerivation"]
|
||||
|
||||
===== Hardened child key derivation
|
||||
|
||||
@ -732,7 +732,7 @@ To counter this risk, HD wallets use an alternative derivation function called _
|
||||
|
||||
[[CKDprime]]
|
||||
.Hardened derivation of a child key, omits the parent public key
|
||||
image::images/ChildHardPrivateDerivation.png["ChildHardPrivateDerivation"]
|
||||
image::images/msbt_0413.png["ChildHardPrivateDerivation"]
|
||||
|
||||
When the hardened private derivation function is used, the resulting child private key and chain code are completely different from what would result from the normal derivation function. The resulting "branch" of keys can be used to produce extended public keys which are not vulnerable, since the chain code they contain cannot be exploited to reveal any private keys. Hardened derivation is therefore used to create a "gap" in the tree above the level where extended public keys are used.
|
||||
|
||||
@ -978,12 +978,12 @@ Paper wallets come in many shapes, sizes and designs, but at a very basic level
|
||||
Paper wallets can be generated easily using a tool such as the client-side Javascript generator at bitaddress.org. This page contains all the code necessary to generate keys and paper wallets, even while completely disconnected from the Internet. To use it, save the HTML page on your local drive or on an external USB flash drive. Disconnect from the Internet and open the file in a browser. Even better, boot your computer using a pristine operating system, such as a CDROM bootable Linux OS. Any keys generated with this tool while offline can be printed on a local printer over a USB cable (not wirelessly), thereby creating paper wallets whose keys exist only on the paper and have never been stored on any online system. Put these paper wallets in a fire-proof safe and "send" bitcoin to their bitcoin address, to implement a simple yet highly effective "cold storage" solution.
|
||||
|
||||
.An example of a simple paper wallet from bitaddress.org
|
||||
image::images/paper_wallet_simple.png["paper_wallet_simple"]
|
||||
image::images/msbt_0414.png["paper_wallet_simple"]
|
||||
|
||||
The disadvantage of the simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoins locked with those keys. A more sophisticated paper wallet storage system uses BIP0038 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage.
|
||||
|
||||
.An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test"
|
||||
image::images/paper_wallet_encrypted.png["paper_wallet_encrypted"]
|
||||
image::images/msbt_0415.png["paper_wallet_encrypted"]
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
@ -993,15 +993,15 @@ While you can deposit funds into a paper wallet several times, you should withdr
|
||||
Paper wallets come in many designs and sizes, with many different features. 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 bank vault or safe with the private key hidden in some way, either with opaque scratch-off stickers, or folded and sealed with tamper-proof adhesive foil.
|
||||
|
||||
.An example of a paper wallet from bitcoinpaperwallet.com with the private key on a folding flap.
|
||||
image::images/paper_wallet_bpw.png["paper_wallet_bpw"]
|
||||
image::images/msbt_0416.png["paper_wallet_bpw"]
|
||||
|
||||
.The bitcoinpaperwallet.com paper wallet with the private key concealed.
|
||||
image::images/paper_wallet_bpw_folded.jpg["paper_wallet_bpw_folded"]
|
||||
image::images/msbt_0417.png["paper_wallet_bpw_folded"]
|
||||
|
||||
Other designs feature additional copies of the key and address, in the form of detachable stubs similar to ticket stubs, allowing you to store multiple copies to protect against fire, flood or other natural disasters.
|
||||
|
||||
.An example of a paper wallet with additional copies of the keys on a backup "stub"
|
||||
image::images/paper_wallet_spw.png["paper_wallet_spw"]
|
||||
image::images/msbt_0418.png["paper_wallet_spw"]
|
||||
|
||||
|
||||
|
||||
|
||||
@ -279,7 +279,7 @@ Below is an example of the unlocking and locking scripts for the most common typ
|
||||
|
||||
[[scriptSig and scriptPubKey]]
|
||||
.Combining scriptSig and scriptPubKey to evaluate a transaction script
|
||||
image::images/scriptSig_and_scriptPubKey.png["scriptSig_and_scriptPubKey"]
|
||||
image::images/msbt_0501.png["scriptSig_and_scriptPubKey"]
|
||||
|
||||
|
||||
[[tx_script_language]]
|
||||
@ -297,7 +297,7 @@ In the following example, the script +2 3 OP_ADD 5 OP_EQUAL+ demonstrates the ar
|
||||
|
||||
[[simplemath_script]]
|
||||
.Bitcoin's script validation doing simple math
|
||||
image::images/TxScriptSimpleMathExample.png["TxScriptSimpleMathExample"]
|
||||
image::images/msbt_0502.png["TxScriptSimpleMathExample"]
|
||||
|
||||
Below is a slightly more complex script, which calculates +((2 + 3) * 2) + 1+. Notice that when the script contains several operators in a row, the stack allows the results of one operator to be acted upon by the next operator:
|
||||
|
||||
@ -379,11 +379,11 @@ Here's a step-by-step execution of the combined script, which will prove this is
|
||||
|
||||
[[P2PubKHash1]]
|
||||
.Evaluating a script for a Pay-to-Public-Key-Hash transaction (Part 1 of 2)
|
||||
image::images/Tx_Script_P2PubKeyHash_1.png["Tx_Script_P2PubKeyHash_1"]
|
||||
image::images/msbt_0503.png["Tx_Script_P2PubKeyHash_1"]
|
||||
|
||||
[[P2PubKHash2]]
|
||||
.Evaluating a script for a Pay-to-Public-Key-Hash transaction (Part 2 of 2)
|
||||
image::images/Tx_Script_P2PubKeyHash_2.png["Tx_Script_P2PubKeyHash_2"]
|
||||
image::images/msbt_0504.png["Tx_Script_P2PubKeyHash_2"]
|
||||
|
||||
[[p2pk]]
|
||||
==== Pay-to-Public-Key
|
||||
|
||||
@ -16,7 +16,7 @@ While nodes in the bitcoin P2P network are equal, they may take on different "ro
|
||||
|
||||
[[full_node_reference]]
|
||||
.A bitcoin network node with all four functions: Wallet, Miner, full Blockchain database, and Network routing
|
||||
image::images/FullNodeReferenceClient_Small.png["FullNodeReferenceClient_Small"]
|
||||
image::images/msbt_0601.png["FullNodeReferenceClient_Small"]
|
||||
|
||||
All nodes include the routing function to participate in the network and may include other functionality. All nodes validate and propagate transactions and blocks, and discover and maintain connections to peers. In the full node example above, the routing function is indicated by an orange circle named "Network Routing Node".
|
||||
|
||||
@ -32,7 +32,7 @@ Here are the most common node types on the extended bitcoin network:
|
||||
|
||||
[[node_type_ledgend]]
|
||||
.Different types of nodes on the extended bitcoin network
|
||||
image::images/BitcoinNodeTypes.png["BitcoinNodeTypes"]
|
||||
image::images/msbt_0602.png["BitcoinNodeTypes"]
|
||||
|
||||
=== The Extended Bitcoin Network
|
||||
|
||||
@ -44,7 +44,7 @@ The diagram below shows the extended bitcoin network with the various types of n
|
||||
|
||||
[[bitcoin_network]]
|
||||
.The extended bitcoin network showing various node types, gateways and protocols
|
||||
image::images/BitcoinNetwork.png["BitcoinNetwork"]
|
||||
image::images/msbt_0603.png["BitcoinNetwork"]
|
||||
|
||||
=== Network Discovery
|
||||
|
||||
@ -66,7 +66,7 @@ The peer node responds with +verack+ to acknowledge and establish a connection,
|
||||
|
||||
[[network_handshake]]
|
||||
.The initial handshake between peers
|
||||
image::images/NetworkHandshake.png["NetworkHandshake"]
|
||||
image::images/msbt_0604.png["NetworkHandshake"]
|
||||
|
||||
How does a new node find peers? While there are no special nodes in bitcoin, there are some long running stable nodes that are listed in the client as _seed nodes_. While a new node does not have to connect with the seed nodes, it can use them to quickly discover other nodes in the network. In the Bitcoin Core client, the option to use the seed nodes is controlled by the option switch +-dnsseed+, which is set to 1, to use the seed nodes, by default. Alternatively, a bootstrapping node that knows nothing of the network must be given the IP address of at least one bitcoin node after which it can establish connections through further introductions. The command line argument +-seednode+ can be used to connect to one node just for introductions, using it as a DNS seed. After the initial seed node is used to form introductions, the client will disconnect from it and use the newly discovered peers.
|
||||
|
||||
@ -75,7 +75,7 @@ Once one or more connections are established, the new node will send an +addr+ m
|
||||
|
||||
[[address_propagation]]
|
||||
.Address Propagation and Discovery
|
||||
image::images/AddressPropagation.png["AddressPropagation"]
|
||||
image::images/msbt_0605.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 come and go, and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap. Only one connection is needed to bootstrap, as the first node can offer introductions to its peer nodes and those peers can offer further introductions. It's also unnecessary and wasteful of network resources to connect to more than a handful of nodes. After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
|
||||
|
||||
@ -151,7 +151,7 @@ This process of comparing the local blockchain with the peers and retrieving any
|
||||
|
||||
[[inventory_synchronization]]
|
||||
.Node synchronizing the blockchain by retrieving blocks from a peer
|
||||
image::images/InventorySynchronization.png["InventorySynchronization"]
|
||||
image::images/msbt_0606.png["InventorySynchronization"]
|
||||
|
||||
[[spv_nodes]]
|
||||
=== Simplified Payment Verification (SPV) Nodes
|
||||
@ -179,7 +179,7 @@ To get the block headers, SPV nodes use a +getheaders+ message instead of +getbl
|
||||
|
||||
[[spv_synchronization]]
|
||||
.SPV Node synchronizing the block headers
|
||||
image::images/SPVSynchronization.png["SPVSynchronization"]
|
||||
image::images/msbt_0607.png["SPVSynchronization"]
|
||||
|
||||
Because SPV nodes need to retrieve specific transactions in order to selectively verify them, they also create a privacy risk. Unlike full-blockchain nodes, which collect all transactions within each block, the SPV node's requests for specific data can inadvertently reveal the addresses in their wallet. For example, a third party monitoring a network could keep track of all the transactions requested by a wallet on an SPV node and use those to associate bitcoin addresses with the user of that wallet, destroying the user's privacy.
|
||||
|
||||
@ -201,7 +201,7 @@ In the example below, we use a very small array of 16 bits and a set of 3 hash f
|
||||
|
||||
[[bloom1]]
|
||||
.An example of a simplistic bloom filter, with 16 bit field and 3 hash functions
|
||||
image::images/Bloom1.png["Bloom1"]
|
||||
image::images/msbt_0608.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 function in turn. Applying the first hash function to the input results in a number between 1 and N. The corresponding bit in the array (indexed from 1 to N) is found and set to +1+, thereby recording the output of the hash function. Then, the next hash function is used to set another bit and so on and so forth. Once all M hash functions have been applied, the search pattern will be "recorded" in the bloom filter as M bits have been changed from +0+ to +1+.
|
||||
|
||||
@ -209,7 +209,7 @@ Here's an example of adding a pattern "A" to the simple bloom filter shown above
|
||||
|
||||
[[bloom2]]
|
||||
.Adding a pattern "A" to our simple bloom filter
|
||||
image::images/Bloom2.png["Bloom2"]
|
||||
image::images/msbt_0609.png["Bloom2"]
|
||||
|
||||
Adding a second pattern is as simple as repeating this process. The pattern is hashed by each hash function in turn and the result is recorded by setting the bits to +1+. Note that as a bloom filter is filled with more patterns, a hash function result may coincide with a bit that is already set to +1+ in which case the bit is not changed. In essence, as more patterns record on overlapping bits, the bloom filter starts to become saturated with more bits set to +1+ and the accuracy of the filter decreases. This is why the filter is a probabilistic data structure -- it gets less accurate as more patterns are added. The accuracy depends on the number of patterns added versus the size of the bit array (N) and number of hash functions (M). A larger bit array and more hash functions can record more patterns with higher accuracy. A smaller bit array or fewer hash functions will record fewer patterns and produce less accuracy.
|
||||
|
||||
@ -217,7 +217,7 @@ Below is an example of adding a second pattern "B" to the simple bloom filter:
|
||||
|
||||
[[bloom3]]
|
||||
.Adding a second pattern "B" to our simple bloom filter
|
||||
image::images/Bloom3.png["Bloom3"]
|
||||
image::images/msbt_0610.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 bit array. If all the bits indexed by the hash functions are set to +1+, then the pattern is _probably_ recorded in the bloom filter. Since the bits may be set because of overlap from multiple patterns, the answer is not certain, but is rather probabilistic. In simple terms, a bloom filter positive match is a "Maybe, Yes".
|
||||
|
||||
@ -225,7 +225,7 @@ Below is an example of testing the existence of pattern "X" in the simple bloom
|
||||
|
||||
[[bloom4]]
|
||||
.Testing the existence of pattern "X" in the bloom filter. The result is probabilistic positive match, meaning "Maybe"
|
||||
image::images/Bloom4.png["Bloom4"]
|
||||
image::images/msbt_0611.png["Bloom4"]
|
||||
|
||||
On the contrary, if a pattern is tested against the bloom filter and any one of the bits is set to +0+, then this proves that the pattern was not recorded in the bloom filter. A negative result is not a probability, it is a certainty. In simple terms, a negative match on a bloom filter is a "Definitely No".
|
||||
|
||||
@ -233,7 +233,7 @@ Below is an example of testing the existence of pattern "Y" in the simple bloom
|
||||
|
||||
[[bloom5]]
|
||||
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely No"
|
||||
image::images/Bloom5.png["Bloom5"]
|
||||
image::images/msbt_0612.png["Bloom5"]
|
||||
|
||||
Bitcoin's implementation of bloom filters is described in Bitcoin Improvement Proposal 37 (BIP0037). See <<bip0037>> or visit:
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki.
|
||||
|
||||
@ -144,7 +144,7 @@ Looking at this new block, the node finds the "previousblockhash" field, which c
|
||||
|
||||
[[chain_of_blocks]]
|
||||
.Blocks linked in a chain, by reference to the previous block header hash
|
||||
image::images/ChainOfBlocks.png["chain_of_blocks"]
|
||||
image::images/msbt_0701.png["chain_of_blocks"]
|
||||
|
||||
[[merkle_trees]]
|
||||
=== Merkle Trees
|
||||
@ -169,25 +169,25 @@ The process continues until there is only one node at the top, the node known as
|
||||
|
||||
[[simple_merkle]]
|
||||
.Calculating the nodes in a Merkle Tree
|
||||
image::images/MerkleTree.png["merkle_tree"]
|
||||
image::images/msbt_0702.png["merkle_tree"]
|
||||
|
||||
Since the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash will be duplicated to create an even number of leaf nodes, also known as a _balanced tree_. This is shown in the example below, where transaction C is duplicated:
|
||||
|
||||
[[merkle_tree_odd]]
|
||||
.An even number of data elements, by duplicating one data element
|
||||
image::images/MerkleTreeOdd.png["merkle_tree_odd"]
|
||||
image::images/msbt_0703.png["merkle_tree_odd"]
|
||||
|
||||
The same method for constructing a tree from four transactions can be generalized to construct trees of any size. In bitcoin it is common to have several hundred to more than a thousand transactions in a single block, which are summarized in exactly the same way producing just 32 bytes of data as the single merkle root. In the diagram below, you will see a tree built from 16 transactions. Note that while the root looks bigger than the leaf nodes in the diagram, it is the exact same size, just 32 bytes. Whether there is one transaction or a hundred thousand transactions in the block, the merkle root always summarizes them into 32 bytes:
|
||||
|
||||
[[merkle_tree_large]]
|
||||
.A Merkle Tree summarizing many data elements
|
||||
image::images/MerkleTreeLarge.png["merkle_tree_large"]
|
||||
image::images/msbt_0704.png["merkle_tree_large"]
|
||||
|
||||
To prove that a specific transaction is included in a block, a node only needs to produce +log~2~(N)+ 32-byte hashes, constituting an _authentication path_ or _merkle path_ connecting the specific transaction to the root of the tree. This is especially important as the number of transactions increases, because the base-2 logarithm of the number of transactions increases much more slowly. This allows bitcoin nodes to efficiently produce paths of ten or twelve hashes (320-384 bytes) which can provide proof of a single transaction out of more than a thousand transactions in a megabyte sized block. In the example below, a node can prove that a transaction K is included in the block by producing a merkle path that is only four 32-byte hashes long (128 bytes total). The path consists of the four hashes (noted in blue in the diagram below) H~L~, H~IJ~, H~MNOP~ and H~ABCDEFGH~. With those four hashes provided as an authentication path, any node can prove that H~K~ (noted in green in the diagram below) is included in the merkle root by computing four additional pair-wise hashes H~KL~, H~IJKL~ and H~IJKLMNOP~ (outlined in a dotted line in the diagram below) that lead to the merkle root.
|
||||
|
||||
[[merkle_tree_path]]
|
||||
.A Merkle Path used to prove inclusion of a data element
|
||||
image::images/MerkleTreePathToK.png["merkle_tree_path"]
|
||||
image::images/msbt_0705.png["merkle_tree_path"]
|
||||
|
||||
|
||||
The code in <<merkle_example>> demonstrates the process of creating a merkle tree from the leaf-node hashes up to the root, using the libbitcoin library for some helper functions:
|
||||
|
||||
@ -51,7 +51,7 @@ Total BTC to ever be created: 2099999997690000 Satoshis
|
||||
|
||||
[[bitcoin_money_supply]]
|
||||
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
|
||||
image::images/BitcoinMoneySupply.png["BitcoinMoneySupply"]
|
||||
image::images/msbt_0801.png["BitcoinMoneySupply"]
|
||||
|
||||
The finite and diminishing issuance creates a fixed monetary supply that resists inflation. Unlike a fiat currency, which can be printed in infinite numbers by a central bank, bitcoin can never be inflated by printing.
|
||||
|
||||
@ -724,7 +724,7 @@ In the first diagram below, the network has a unified perspective of the blockch
|
||||
|
||||
[[fork1]]
|
||||
.Visualization of a blockchain fork event - Before the Fork
|
||||
image::images/GlobalFork1.png["globalfork1"]
|
||||
image::images/msbt_0802.png["globalfork1"]
|
||||
|
||||
A "fork" occurs whenever there are two candidate blocks competing to form the longest blockchain. This occurs under normal conditions whenever two miners solve the Proof-of-Work algorithm within a short period of time from each other. As both miners discover a solution for their respective candidate blocks, they immediately broadcast their own "winning" block to their immediate neighbors who begin propagating the block across the network. Each node that receives a valid block will incorporate it into their blockchain, extending the blockchain by one block. If that node later sees another candidate block extending the same parent, they connect the second candidate on a secondary chain. As a result, some nodes will "see" one candidate block first, while other nodes will see the other candidate block and two competing versions of the blockchain will emerge.
|
||||
|
||||
@ -732,7 +732,7 @@ In the diagram below, we see two miners who mine two different blocks almost sim
|
||||
|
||||
[[fork2]]
|
||||
.Visualization of a blockchain fork event - Two blocks found simultaneously
|
||||
image::images/GlobalFork2.png["globalfork2"]
|
||||
image::images/msbt_0803.png["globalfork2"]
|
||||
|
||||
Let's assume for example that a miner in Canada finds a Proof-of-Work solution for a block "red" that extends the blockchain, building on top of the parent block "blue". Almost simultaneously, an Australian miner who was also extending block "blue", finds a solution for block "green", their candidate block. Now, there are two possible blocks, one we call "red", originating in Canada and one we call "green", originating in Australia. Both blocks are valid, both blocks contain a valid solution to the proof of work, both blocks extend the same parent. Both blocks likely contain most of the same transactions, with only perhaps a few differences in the order of transactions.
|
||||
|
||||
@ -740,19 +740,19 @@ As the two blocks propagate, some nodes receive block "red" first and some recei
|
||||
|
||||
[[fork2]]
|
||||
.Visualization of a blockchain fork event - Two blocks propagate, splitting the network
|
||||
image::images/GlobalFork3.png["globalfork3"]
|
||||
image::images/msbt_0804.png["globalfork3"]
|
||||
|
||||
From that moment, the bitcoin network nodes closest (topologically, not geographically) to the Canadian node will hear about block "red" first and will create a new greatest-cumulative-difficulty blockchain with "red" as the last block in the chain (e.g. blue-red), ignoring the candidate block "green" that arrives a bit later. Meanwhile, nodes closer to the Australian node will take that block as the winner and extend the blockchain with "green" as the last block (e.g. blue-green), ignoring "red" when it arrives a few seconds later. Any miners that saw "red" first will immediately build candidate blocks that reference "red" as the parent and start trying to solve the PoW for these candidate blocks. The miners that accepted "green" instead, will start building on top of "green" and extending that chain.
|
||||
|
||||
[[fork4]]
|
||||
.Visualization of a blockchain fork event - A new block extends one fork
|
||||
image::images/GlobalFork4.png["globalfork4"]
|
||||
image::images/msbt_0805.png["globalfork4"]
|
||||
|
||||
Forks are almost always resolved within one block. As part of the network's hashing power is dedicated to building on top of "red" as the parent, another part of the hashing power is focused on building on top of "green". Even if the hashing power is almost evenly split, it is likely that one set of miners will find a solution and propagate it before the other set of miners have found any solutions. Let's say for example that the miners building on top of "green" find a new block "pink" that extends the chain (e.g. blue-green-pink). They immediately propagate this new block and the entire network sees it as a valid solution.
|
||||
|
||||
[[fork5]]
|
||||
.Visualization of a blockchain fork event - The network re-converges on a new longest chain
|
||||
image::images/GlobalFork5.png["globalfork5"]
|
||||
image::images/msbt_0806.png["globalfork5"]
|
||||
|
||||
All nodes that had chosen "green" as the winner in the previous round will simply extend the chain one more block. The nodes that chose "red" as the winner, however, will now see two chains: blue-green-pink and blue-red. The chain blue-green-pink is now longer (more cumulative difficulty) than the chain blue-red. As a result, those nodes will set the chain blue-green-pink as main chain and change the blue-red chain to being a secondary chain. This is a chain re-convergence, as those nodes are forced to revise their view of the blockchain to incorporate the new evidence of a longer chain. Any miners working on extending the chain blue-red will now stop that work because their candidate block is an "orphan", as its parent "red" is no longer on the longest chain. The transactions within "red" are queued up again for processing in the next block, as that block is no longer in the main chain. The entire network re-converges on a single blockchain blue-green-pink, with "pink" as the last block in the chain. All miners immediately start working on candidate blocks that reference "pink" as their parent to extend the blue-green-pink chain.
|
||||
|
||||
@ -775,13 +775,13 @@ In the chart below, we see the bitcoin network's hashing power increase over the
|
||||
|
||||
[[network_hashing_power]]
|
||||
.Total hashing power, giga-hashes per second, over two years
|
||||
image::images/NetworkHashingRate.png["NetworkHashingRate"]
|
||||
image::images/msbt_0807.png["NetworkHashingRate"]
|
||||
|
||||
As the amount of hashing power applied to mining bitcoin has exploded, the difficulty has risen to match it. The difficulty metric in the following chart is measured as a ratio of current difficulty over minimum difficulty (the difficulty of the first block):
|
||||
|
||||
[[bitcoin_difficulty]]
|
||||
.Bitcoin's mining difficulty metric, over two years
|
||||
image::images/BitcoinDifficulty.png["BitcoinDifficulty"]
|
||||
image::images/msbt_0808.png["BitcoinDifficulty"]
|
||||
|
||||
In the last two years, the ASIC mining chips have become denser and denser, approaching the cutting edge of silicon fabrication with a feature size (resolution) of 22 nanometers (nm). Currently, ASIC manufacturers are aiming to overtake general purpose CPU chip manufacturers, designing chips with a feature size of 16nm, because the profitability of mining is driving this industry even faster than general computing. There are no more giant leaps left in bitcoin mining, because the industry has reached the forefront of "Moore's Law". Still, the mining power of the network continues to advance at an exponential pace as the race for higher density chips is matched with a race for higher density data centers where thousands of these chips can be deployed. It's no longer about how much mining can be done with one chip but how many chips can be squeezed into a building, while still dissipating the heat and providing adequate power.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user