The most important part of this screen is Alice's ((("bitcoin address")))_bitcoin address_. On the screen it appears as a long string of letters and numbers: +1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+. Next to the wallet's bitcoin address is a QR code, a form of barcode that contains the same information in a format that can be scanned by a smartphone camera. The QR code is the square with a pattern of black and white dots. Alice can copy the bitcoin address or the QR code onto her clipboard by tapping on the QR code, or on the +Receive+ button. In most wallets, clicking on the QR code will also magnify it, so that it can be more easily scanned by a smartphone camera.
@ -193,7 +193,7 @@ Joe now has Alice's bitcoin address set as the recipient. Joe enters the amount
[[airbitz-mobile-send]]
.Airbitz mobile bitcoin wallet send screen
image::images/airbitz-mobile-send-msbt_0102.png["airbitz mobile send screen"]
image::images/mbc2_0102.png["airbitz mobile send screen"]
Joe then carefully checks to make sure he has entered the correct amount, because he is about to transmit money and mistakes are irreversible. After double checking the address and amount, he presses +Send+ to transmit the transaction. Joe's mobile bitcoin wallet constructs a transaction that assigns 0.10 bitcoin to the address provided by Alice, sourcing the funds from Joe's wallet and signing the transaction with Joe's private keys. This tells the bitcoin network that Joe has authorized a transfer of value to Alice's new address. As the transaction is transmitted via the peer-to-peer protocol, it quickly propagates across the bitcoin network. In less than a second, most of the well-connected nodes in the network receive the transaction and see Alice's address for the first time.
@ -11,7 +11,7 @@ In the overview diagram shown in <<bitcoin-overview>>, we see that the bitcoin s
[[bitcoin-overview]]
.Bitcoin overview
image::images/msbt_0201.png["Bitcoin Overview"]
image::images/mbc2_0201.png["Bitcoin Overview"]
Each example in this chapter is based on an actual transaction made on the bitcoin network, simulating the interactions between the users (Joe, Alice, Bob and Gopesh) by sending funds from one wallet to another. While tracking a transaction through the bitcoin network to the blockchain, we will use a((("blockchain explorer websites"))) _blockchain explorer_ site to visualize each step. A blockchain explorer is a web application that operates as a bitcoin search engine, in that it allows you to search for addresses, transactions, and blocks and see the relationships and flows between them.
@ -49,7 +49,7 @@ Bob's point-of-sale system will also automatically create a special QR code cont
[[payment-request-QR]]
.Payment request QR code
image::images/msbt_0202.png["payment-request"]
image::images/mbc2_0202.png["payment-request"]
[TIP]
====
@ -101,7 +101,7 @@ The transaction also contains proof of ownership for each amount of bitcoin (inp
@ -109,7 +109,7 @@ Alice's payment to Bob's Cafe uses a previous transaction's output as its input.
[[blockchain-mnemonic]]
.A chain of transactions, where the output of one transaction is the input of the next transaction
image::images/msbt_0204.png["Transaction chain"]
image::images/mbc2_0204.png["Transaction chain"]
==== Making Change
@ -125,19 +125,19 @@ In summary, _transactions_ move value from _transaction inputs_ to _transaction
[[transaction-common]]
.Most common transaction
image::images/msbt_0205.png["Common Transaction"]
image::images/mbc2_0205.png["Common Transaction"]
Another common form of transaction is one that aggregates several inputs into a single output (see <<transaction-aggregating>>). 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.
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 (see <<transaction-distributing>>). This type of transaction is sometimes used by commercial entities to distribute funds, such as when processing payroll payments to multiple employees.(((range="endofrange", startref="ix_ch02-asciidoc3")))
@ -269,7 +269,7 @@ In the diagram in <<block-alice1>> we can see block #277316, which contains Ali
[[block-alice1]]
.Alice's transaction included in block #277316
image::images/msbt_0209.png["Alice's transaction included in a block"]
image::images/mbc2_0209.png["Alice's transaction included in a block"]
=== Spending the Transaction
@ -281,6 +281,6 @@ As Bob spends the payments received from Alice and other customers, he extends t
[[block-alice2]]
.Alice's transaction as part of a transaction chain from Joe to Gopesh
image::images/msbt_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 moment it was created in her wallet, through the bitcoin network and to the miners who recorded it on the blockchain. In the next few chapters we will examine the specific technologies behind wallets, addresses, signatures, transactions, the network and finally mining.
.Why use asymmetric cryptography (public/private keys)?
****
@ -121,7 +121,7 @@ Elliptic curve multiplication is a type of function which cryptographers call a
[[ecc-curve]]
.An elliptic curve
image::images/msbt_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 curve standard"))) +secp256k1+, established by the((("National Institute of Standards and Technology (NIST)"))) National Institute of Standards and Technology (NIST). The +secp256k1+ curve is defined by the following function, which produces an elliptic curve:
[latexmath]
@ -146,7 +146,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/msbt_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. You can check this yourself using Python:
----
@ -232,7 +232,7 @@ Most bitcoin implementations use the((("OpenSSL cryptographic library"))) http:/
[[ecc_illustrated]]
.Elliptic curve cryptography: Visualizing the multiplication of a point G by an integer k on an elliptic curve
image::images/msbt_0404.png["ecc_illustrated"]
image::images/mbc2_0404.png["ecc_illustrated"]
=== Bitcoin Addresses
@ -266,7 +266,7 @@ Bitcoin addresses are almost always presented to users in an encoding called((("
[[pubkey_to_address]]
.Public key to bitcoin address: conversion of a public key into a bitcoin address
image::images/msbt_0405.png["pubkey_to_address"]
image::images/mbc2_0405.png["pubkey_to_address"]
[[base58]]
==== Base58 and Base58Check Encoding
@ -298,7 +298,7 @@ The result is composed of three items: a prefix, the data, and a checksum. This
[[base58check_encoding]]
.Base58Check encoding: a Base58, versioned, and checksummed format for unambiguously encoding bitcoin data
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 Base58 contain specific characters at the beginning of the Base58Check-encoded payload. These characters make 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 Base58 characters are shown in <<base58check_versions>>.((("Base58Check encoding","prefixes, listed")))
@ -465,7 +465,7 @@ Whereas uncompressed public keys have a prefix of +04+, ((("Wallet Import Format
[[pubkey_compression]]
.Public key compression
image::images/msbt_0407.png["pubkey_compression"]
image::images/mbc2_0407.png["pubkey_compression"]
((("public keys","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:
@ -780,13 +780,13 @@ Paper wallets come in many shapes, sizes, and designs, but at a very basic level
[[paper_wallet_simple]]
.An example of a simple paper wallet from bitaddress.org
image::images/msbt_0414.png[]
image::images/mbc2_0408.png[]
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 bitcoin locked with those keys. A more sophisticated paper wallet storage system uses BIP-38 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. <<paper_wallet_encrypted>> shows a paper wallet with an encrypted private key (BIP-38) created on the bitaddress.org site.
[[paper_wallet_encrypted]]
.An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test."
image::images/msbt_0415.png[]
image::images/mbc2_0409.png[]
[WARNING]
====
@ -797,17 +797,17 @@ Paper wallets come in many designs and sizes, with many different features. Some
[[paper_wallet_bpw]]
.An example of a paper wallet from bitcoinpaperwallet.com with the private key on a folding flap.
image::images/msbt_0416.png[]
image::images/mbc2_0410.png[]
[[paper_wallet_bpw_folded]]
.The bitcoinpaperwallet.com paper wallet with the private key concealed.
image::images/msbt_0417.png[]
image::images/mbc2_0411.png[]
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.(((range="endofrange", startref="ix_ch04-asciidoc32")))(((range="endofrange", startref="ix_ch04-asciidoc31")))(((range="endofrange", startref="ix_ch04-asciidoc30")))(((range="endofrange", startref="ix_ch04-asciidoc29")))
[[paper_wallet_spw]]
.An example of a paper wallet with additional copies of the keys on a backup "stub."
.Type-2 hierarchical deterministic wallet: a tree of keys generated from a single seed
image::images/msbt_0409.png["HD wallet"]
image::images/mbc2_0503.png["HD wallet"]
HD wallets offer two major advantages over random (nondeterministic) keys. First, the tree structure can be used to express additional organizational meaning, such as when a specific branch of subkeys is used to receive incoming payments and a different branch is used to receive change from outgoing payments. Branches of keys can also be used in a corporate setting, allocating different branches to departments, subsidiaries, specific functions, or accounting categories.
@ -111,13 +111,13 @@ In <<user-stories>> we introduced Gabriel, an enterprising young teenager in Rio
Gabriel uses a Trezor bitcoin hardware wallet, to securely manage his bitcoin. The Trezor is a simple USB device with two buttons that stores keys (in the form of an HD wallet) and signs transactions. Trezor wallets implement all the industry standards discussed in this chapter, so Gabriel is not reliant on any proprietary technology or single vendor solution.
.A Trezor device: a bitcoin HD-wallet in hardware
image::images/trezor-grey-medium.png[alt]
image::images/mbc2_0504.png[alt]
When Gabriel used the Trezor for the first time, the device generated a mnemonic and seed from a built-in hardware random number generator. During this initialization phase, the wallet displayed a numbered sequence of words, one by one, on the screen (see <<trezor_mnemonic_display>>).
[[trezor_mnemonic_display]]
.Trezor displaying one of the mnemonic words
image::images/trezor-seed-display.png["Trezor wallet display of mnemonic word"]
image::images/mbc2_0505.png["Trezor wallet display of mnemonic word"]
By writing down this mnemonic, Gabriel created a backup (see <<mnemonic_paper_backup>>) that can be used for recovery in the case of loss or damage to the Trezor device. This mnemonic can be used for recovery in a new Trezor or in any one of the many compatible software or hardware wallets. Note that the sequence of words is important, so mnemonic paper backups have numbered spaces for each word. Gabriel had to carefully record each word in the numbered space to preserve the correct sequence.
@ -171,7 +171,7 @@ Mnemonic words are generated automatically by the wallet, using a standardized p
6. The mnemonic code is the sequence of words.
+
.Generating entropy and encoding as mnemonic words
image::images/Mnemonic_Words.png["Generating entropy and encoding as mnemonic words"]
image::images/mbc2_0506.png["Generating entropy and encoding as mnemonic words"]
+
The table <<table_4-5>>, shows the relationship between the size of entropy data and the length of mnemonic codes in words.
+
@ -201,7 +201,7 @@ The process described in steps 7 through 9 below continues from the process desc
9. PBKDF2 stretches the mnemonic and salt parameters using 2048 rounds of hashing with the HMAC-SHA512 algorithm, producing a 512-bit value as its final output. That 512-bit value is the seed.
.From mnemonic to seed
image::images/Mnemonic_to_seed.png["From mnemonic to seed"]
image::images/mbc2_0507.png["From mnemonic to seed"]
[TIP]
====
@ -281,7 +281,7 @@ libbitcoin/mnemonic:: An implementation of BIP-39, as part of the popular Libbit
There is also a BIP-39 generator implemented in a standalone web-page, which is extremely useful for testing and experimentation.
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_ (c).
@ -322,7 +322,7 @@ The parent public key, chain code, and the index number are combined and hashed
[[CKDpriv]]
.Extending a parent private key to create a child private key
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,147,483,647 (2^31^) children (2^31^ is half of the entire 2^32^ range available because the other half is reserved for a special type of derivation we will talk about later in this chapter)
@ -381,7 +381,7 @@ An extended public key can be used, therefore, to derive all of the _public_ key
[[CKDpub]]
.Extending a parent public key to create a child public key
@ -401,7 +401,7 @@ To export the extended public key, Gabriel uses the web-based software in conjun
[[export_xpub]]
.Exporting an extended public key (xpub) from a Trezor hardware wallet.
image::images/trezor_xpub_export.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 shop software. He uses _Mycelium Gear_, which is an open source web-store plugin for a variety of web hosting and content platforms. Mycelium gear uses the xpub to generate a unique address for every purchase.
@ -413,7 +413,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
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 that are not vulnerable, because 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.
The block explorer application shows a transaction from Alice's "address" to Bob's "address". This is a much simplified view of what is contained in a transaction. In fact, as we will see in this chapter, much of the information shown above is constructed by the block explorer and is not actually in the transaction.
@ -303,7 +303,7 @@ Static fees are no longer viable on the bitcoin network. Wallets that set static
[[bitcoinfees21co]]
.Fee Estimation Service bitcoinfees.21.co
image::images/bitcoinfees21co.png[Fee Estimation Service bitcoinfees.21.co]
image::images/mbc2_0602.png[Fee Estimation Service bitcoinfees.21.co]
The chart in <<bitcoinfees21co>> shows the real-time estimate of fees in 10 satoshi/byte increments and the expected confirmation time (in minutes and number of blocks) for transactions with fees in each range. For each fee range (eg. 61-70 satoshi/byte), two horizontal bars show the number of unconfirmed transactions (1405) and total number of transactions in the past 24 hours (102975), with fees in that range. Based on the graph, the recommended high-priority fee at this time was 80 satoshi/byte, a fee likely to result in the transaction being mined in the very next block (zero block delay). For perspective, the median transaction size is 226 bytes, so the recommended fee for a transaction size would be 18,080 satoshis (0.00018080 BTC).
@ -387,7 +387,7 @@ Note that the UTXO is permanently recorded in the blockchain, and therefore is i
[[scriptSig_and_scriptPubKey]]
.Combining scriptSig and scriptPubKey to evaluate a transaction script
On the left side of the transaction, the blockchain explorer shows Alice's bitcoin address as the "sender". In fact, this information is not in the transaction itself. When the blockchain explorer retrieved the transaction it also retrieved the previous transaction referenced in the input and extracted the first output from that older transaction. Within that output is a locking script that locks the UTXO to Alice's public key hash (a P2PKH script). The blockchain explorer extracted the public key hash and encoded it using Base58Check encoding to produce and display the bitcoin address that represents that public key.
@ -696,7 +696,7 @@ Similarly, on the right side, the blockchain explorer shows the two outputs, the
If you were to click on Bob's bitcoin address, the blockchain explorer would show you this view:
.The balance of Bob's bitcoin address
image::images/bobs_address.png["The balance of Bob's bitcoin address"]
image::images/mbc2_0608.png["The balance of Bob's bitcoin address"]
The blockchain explorer displays the balance of Bob's bitcoin address. But nowhere in the bitcoin system is there a concept of a "balance". Rather, the values displayed here are constructed by the blockchain explorer as follows:
All nodes include the routing function to participate in the network and might include other functionality. All nodes validate and propagate transactions and blocks, and discover and maintain connections to peers. In the full-node example in <<full_node_reference>>, the routing function is indicated by an orange circle named "Network Routing Node.", or with the letter "N".
@ -39,11 +39,11 @@ The extended bitcoin network includes the network running the bitcoin P2P protoc
[[node_type_ledgend]]
.Different types of nodes on the extended bitcoin network
image::images/msbt_0602.png["BitcoinNodeTypes"]
image::images/mbc2_0802.png["BitcoinNodeTypes"]
[[bitcoin_network]]
.The extended bitcoin network showing various node types, gateways, and protocols
image::images/msbt_0603.png["BitcoinNetwork"]
image::images/mbc2_0803.png["BitcoinNetwork"]
=== Bitcoin Relay Networks
@ -83,14 +83,14 @@ Alternatively, a bootstrapping node that knows nothing of the network must be gi
Once one or more connections are established, the new node will send an((("addr message"))) +addr+ message containing its own IP address to its neighbors. The neighbors will, in turn, forward the +addr+ message to their neighbors, ensuring that the newly connected node becomes well known and better connected. Additionally, the newly connected node can send +getaddr+ to the neighbors, asking them to return a list of IP addresses of other peers. That way, a node can find peers to connect to and advertise its existence on the network for other nodes to find it. <<address_propagation>> shows the address discovery protocol.
[[address_propagation]]
.Address propagation and discovery
image::images/msbt_0605.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 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, because 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.
@ -173,7 +173,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
As an analogy, a full node is like a tourist in a strange city, equipped with a detailed map of every street and every address. By comparison, an SPV node is like a tourist in a strange city asking random strangers for turn-by-turn directions while knowing only one main avenue. Although both tourists can verify the existence of a street by visiting it, the tourist without a map doesn't know what lies down any of the side streets and doesn't know what other streets exist. Positioned in front of 23 Church Street, the tourist without a map cannot know if there are a dozen other "23 Church Street" addresses in the city and whether this is the right one. The mapless tourist's best chance is to ask enough people and hope some of them are not trying to mug him.
@ -194,7 +194,7 @@ For most practical purposes, well-connected SPV nodes are secure enough, strikin
[[spv_synchronization]]
.SPV node synchronizing the block headers
image::images/msbt_0607.png["SPVSynchronization"]
image::images/mbc2_0807.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.
@ -217,7 +217,7 @@ In <<bloom1>>, we use a very small array of 16 bits and a set of three hash func
[[bloom1]]
.An example of a simplistic bloom filter, with a 16-bit field and three hash functions
image::images/msbt_0608.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 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. Once all M hash functions have been applied, the search pattern will be "recorded" in the bloom filter as M bits that have been changed from +0+ to +1+.
@ -227,13 +227,13 @@ Adding a second pattern is as simple as repeating this process. The pattern is h
[[bloom2]]
.Adding a pattern "A" to our simple bloom filter
image::images/msbt_0609.png["Bloom2"]
image::images/mbc2_0809.png["Bloom2"]
<<bloom3>> 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/msbt_0610.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 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. Because 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."
@ -241,7 +241,7 @@ To test if a pattern is part of a bloom filter, the pattern is hashed by each ha
[[bloom4]]
.Testing the existence of pattern "X" in the bloom filter. The result is probabilistic positive match, meaning "Maybe."
image::images/msbt_0611.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 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 Not!"
@ -249,7 +249,7 @@ On the contrary, if a pattern is tested against the bloom filter and any one of
[[bloom5]]
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
@ -155,7 +155,7 @@ A _merkle tree_, also known as a((("binary hash tree"))) _binary hash tree_, is
[[chain_of_blocks]]
.Blocks linked in a chain, by reference to the previous block header hash
image::images/msbt_0701.png[]
image::images/mbc2_0901.png[]
Merkle trees are used in bitcoin to summarize all the transactions in a block, producing an overall digital fingerprint of the entire set of transactions, providing a very efficient process to verify whether a transaction is included in a block. A((("Merkle trees","constructing"))) Merkle tree is constructed by recursively hashing pairs of nodes until there is only one hash, called the _root_, or _merkle root_. The cryptographic hash algorithm used in bitcoin's merkle trees is SHA256 applied twice, also known as double-SHA256.
@ -177,13 +177,13 @@ 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/msbt_0702.png["merkle_tree"]
image::images/mbc2_0902.png["merkle_tree"]
Because the merkle tree is a binary tree, it needs an even number of leaf nodes. If there is an odd number of transactions to summarize, the last transaction hash will be duplicated to create an even number of leaf nodes, also known as a((("balanced trees"))) _balanced tree_. This is shown in <<merkle_tree_odd>>, where transaction C is duplicated.
[[merkle_tree_odd]]
.Duplicating one data element achieves an even number of data elements
image::images/msbt_0703.png["merkle_tree_odd"]
image::images/mbc2_0903.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 <<merkle_tree_large>>, you will see a tree built from 16 transactions. Note that although 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.
@ -191,13 +191,13 @@ To prove that a specific transaction is included in a block, a node only needs t
[[merkle_tree_large]]
.A merkle tree summarizing many data elements
image::images/msbt_0704.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 32-byte hashes long (128 bytes total). The path consists of the four hashes (noted in blue in <<merkle_tree_path>>) 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) is included in the merkle root by computing four additional pair-wise hashes H~KL~, H~IJKL~, H~IJKLMNOP~, and the merkle tree root (outlined in a dotted line in the diagram).
[[merkle_tree_path]]
.A merkle path used to prove inclusion of a data element
image::images/msbt_0705.png["merkle_tree_path"]
image::images/mbc2_0905.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.
@ -33,7 +33,7 @@ In November 2012, the new bitcoin issuance rate was decreased to 25 bitcoin per
[[bitcoin_money_supply]]
.Supply of bitcoin currency over time based on a geometrically decreasing issuance rate
image::images/msbt_0801.png["BitcoinMoneySupply"]
image::images/mbc2_1001.png["BitcoinMoneySupply"]
[NOTE]
====
@ -758,7 +758,7 @@ In the first diagram (<<fork1>>), the network has a unified perspective of the b
[[fork1]]
.Before the fork - all nodes have the same perspective
image::images/fork1.png["Before the fork - all nodes have the same perspective"]
image::images/mbc2_1002.png["Before the fork - all nodes have the same perspective"]
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 its blockchain, extending the blockchain by one block. If that node later sees another candidate block extending the same parent, it connects 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.
@ -768,7 +768,7 @@ Let's assume, for example, that a miner Node A finds a proof-of-work solution fo
[[fork2]]
.Visualization of a blockchain fork event: two blocks found simultaneously
image::images/fork2.png["Visualization of a blockchain fork event: two blocks found simultaneously"]
image::images/mbc2_1003.png["Visualization of a blockchain fork event: two blocks found simultaneously"]
As the two blocks propagate, some nodes receive block "triangle" first and some receive block "upside-down black triangle" first. As shown in <<fork3>>, the network splits into two different perspectives of the blockchain, one side topped with a triangle block, the other with the upside-down-triangle block.
@ -780,7 +780,7 @@ Neither side is "correct," or "incorrect". Both are valid perspectives of the bl
[[fork3]]
.Visualization of a blockchain fork event: two blocks propagate, splitting the network
image::images/fork3.png["Visualization of a blockchain fork event: two blocks propagate, splitting the network"]
image::images/mbc2_1004.png["Visualization of a blockchain fork event: two blocks propagate, splitting the network"]
Mining nodes whose perspective resembles Node X will immediately begin mining a candidate block that extends the chain with "triangle" as its tip. By linking "triangle" as the parent of their candidate block, they are voting with their hashing power. Their vote supports the chain that they have elected as the main chain.
@ -790,13 +790,13 @@ Forks are almost always resolved within one block. While part of the network's h
[[fork4]]
.Visualization of a blockchain fork event: a new block extends one fork, reconverging the network
image::images/fork4.png["Visualization of a blockchain fork event: a new block extends one fork"]
image::images/mbc2_1005.png["Visualization of a blockchain fork event: a new block extends one fork"]
All nodes that had chosen "triangle" as the winner in the previous round will simply extend the chain one more block. The nodes that chose "upside-down black triangle" as the winner, however, will now see two chains: star-triangle-rhombus and star-upside-down-black-triangle. The chain star-triangle-rhombus is now longer (more cumulative work) than the other chain. As a result, those nodes will set the chain star-triangle-rhombus as main chain and change the star-upside-down-black-triangle chain to being a secondary chain, as shown in <<fork4>>. This is a chain reconvergence, because 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 star-upside-down-black-triangle will now stop that work because their candidate block is an "orphan," as its parent "upside-down-black-triangle" is no longer on the longest chain. The transactions within "upside-down-black-triangle" are re-inserted in the mempool for inclusion in the next block, because the block they were in is no longer in the main chain. The entire network re-converges on a single blockchain star-triangle-rhombus, with "rhombus" as the last block in the chain. All miners immediately start working on candidate blocks that reference "rhombus" as their parent to extend the star-triangle-rhombus chain.
[[fork5]]
.Visualization of a blockchain fork event: the network reconverges on a new longest chain
image::images/fork5.png["Visualization of a blockchain fork event: the network reconverges on a new longest chain"]
image::images/mbc2_1006.png["Visualization of a blockchain fork event: the network reconverges on a new longest chain"]
It is theoretically possible for a fork to extend to two blocks, if two blocks are found almost simultaneously by miners on opposite "sides" of a previous fork. However, the chance of that happening is very low. Whereas a one-block fork might occur every day, a two-block fork occurs once every few weeks.
@ -821,13 +821,13 @@ In the chart in <<network_hashing_power>>, we see the bitcoin network's hashing
[[network_hashing_power]]
.Total hashing power, terahashes per second (TH/sec)
image::images/hash-rate.png["NetworkHashingRate"]
image::images/mbc2_1007.png["NetworkHashingRate"]
((("proof-of-work target","hashing power and")))As the amount of hashing power applied to mining bitcoin has exploded, the difficulty has risen to match it. The difficulty metric in the chart shown in <<bitcoin_difficulty>> is measured as a ratio of current difficulty over minimum difficulty (the difficulty of the first block).
[[bitcoin_difficulty]]
.Bitcoin's mining difficulty metric
image::images/difficulty.png["BitcoinDifficulty"]
image::images/mbc2_1008.png["BitcoinDifficulty"]
In the last two years, the ASIC mining chips have become increasingly denser, approaching the cutting edge of silicon fabrication with a feature size (resolution) of 16 nanometers (nm). Currently, ASIC manufacturers are aiming to overtake general-purpose CPU chip manufacturers, designing chips with a feature size of 14nm, 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"))) Moore's Law, which stipulates that computing density will double approximately every 18 months. Still, the mining power of the network continues to advance at an exponential pace as the race for higher density chips is matched ((("data centers, mining with")))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.
@ -919,7 +919,7 @@ Let's examine the mechanics of a hard fork with a specific example:
[[blockchainwithforks]]
.A blockchain with forks
image::images/blockchainwithforks.png[A blockchain with forks]
image::images/mbc2_1009.png[A blockchain with forks]
In the diagram <<blockchainwithforks>> we see a blockchain that contains two forks. At block height 4, a one-block fork occurs. This is the type of spontaneous fork we saw in <<forks>>. With the mining of block 5, the network reconverges on one chain and the fork is resolved.
@ -1069,7 +1069,7 @@ BIP-9 offers a proposal state diagram to illustrate the various stages and trans
[[bip9states]]
.BIP-9 Proposal State Transition Diagram
image::images/bip-9-states.png[BIP-9 Proposal State Transition Diagram]
image::images/mbc2_1010.png[BIP-9 Proposal State Transition Diagram]
Proposals start in the DEFINED state, once their parameters are known (defined) in the bitcoin software. For blocks with MTP after the start time, the proposal state transitions to STARTED. If the voting threshold is exceeded within a retarget period and the timeout has not been exceeded, the proposal state transitions to LOCKED_IN. One retarget period later, the proposal becomes ACTIVE. Proposals remain in the ACTIVE state perpetually once they reach that state. If the timeout is elapsed before the voting threshold has been reached, the proposal state changes to FAILED, indicating a rejected proposal. REJECTED proposals remain in that state perpetually.
.The Issuance Transaction - as viewed on coinprism.info
image::images/coinprism_issuance.png[The Issuance Transaction - as viewed on coinprism.info]
image::images/mbc2_1201.png[The Issuance Transaction - as viewed on coinprism.info]
As you can see, coinprism shows the issuance of 20 units of "Free copy of Mastering Bitcoin", the MasterBTC asset, to a special colored coin address +akTnsDt5uzpioRST76VFRQM8q8sBFnQiwcx+
@ -137,14 +137,14 @@ The transaction ID of the issuance transaction is a "normal" bitcoin transaction
.The Issuance Transaction - on a block explorer that doesn't decode colored coins
image::images/coloredcoins_tx.png[The Issuance Transaction - on a block explorer that doesn't decode colored coins]
image::images/mbc2_1202.png[The Issuance Transaction - on a block explorer that doesn't decode colored coins]
As you can see, blockchain.info doesn't recognize this as a colored coins transaction. In fact, it marks the second output with "Unable to decode output address" in red letters.
If you select "Show scripts & coinbase" on that screen, you can see more detail about the transaction:
.The scripts in the Issuance Transaction
image::images/coloredcoins_tx_scripts.png[The scripts in the Issuance Transaction]
image::images/mbc2_1203.png[The scripts in the Issuance Transaction]
Once again, blockchain.info doesn't understand the second output. It marks it with "Strange" in red letters. However, we can see some of the metadata in the marker output is human-readable:
Matthew Hacker
7 years ago