mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-22 22:58:09 +00:00
pagebreak tweaks and formatting check
This commit is contained in:
Kristen Brown
parent
7b3540f499
commit
d6fc910df7
@ -119,7 +119,7 @@ $ bx ec-to-address < public_key
|
||||
17re1S4Q8ZHyCP8Kw7xQad1Lr6XUzWUnkG
|
||||
----
|
||||
|
||||
Keys generated in this manner produce a type-0 nondeterministic wallet. That means that each key is generated from an independent seed. Bitcoin Explorer commands can also generate keys deterministically, in accordance with BIP0032. In this case a "master" key is created from a seed and then extended deterministically to produce a tree of subkeys, resulting in a type-2 deterministic wallet.
|
||||
Keys generated in this manner produce a type-0 nondeterministic wallet. That means that each key is generated from an independent seed. Bitcoin Explorer commands can also generate keys deterministically, in accordance with BIP0032. In this case, a "master" key is created from a seed and then extended deterministically to produce a tree of subkeys, resulting in a type-2 deterministic wallet.
|
||||
|
||||
First, we we use the((("Bitcoin Explorer","seed command")))((("seed command (bx)"))) +seed+ and((("Bitcoin Explorer","hd-new command")))((("hd-new command (bx)"))) +hd-new+ commands to generate a master key that will be used as the basis to derive a hierarchy of keys.
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
|
||||
<para>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and co-taught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</para>
|
||||
|
||||
<para>As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</para></authorblurb></author><editor><firstname>Mike</firstname><surname>Loukides</surname></editor><editor><firstname>Allyson</firstname><surname>MacDonald</surname></editor><copyright><year>2015</year><holder>Andreas M. Antonopoulos LLC</holder></copyright><editor role="production"><firstname>Melanie</firstname><surname>Yarbrough</surname></editor><editor role="copy"><firstname>Kim</firstname><surname>Cofer</surname></editor><othercredit role="indexer"><firstname>WordCo</firstname><surname>Indexing Services</surname></othercredit><othercredit role="coverdesigner"><firstname>Karen</firstname><surname>Montgomery</surname></othercredit><othercredit role="interiordesigner"><firstname>David</firstname><surname>Futato</surname></othercredit><printhistory><formalpara><title>First Edition</title><para>December, 2014</para></formalpara></printhistory><revhistory><revision><date>2014-12-01</date><revremark>First release</revremark></revision></revhistory>
|
||||
<para>As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</para></authorblurb></author><editor><firstname>Mike</firstname><surname>Loukides</surname></editor><editor><firstname>Allyson</firstname><surname>MacDonald</surname></editor><copyright><year>2015</year><holder>Andreas M. Antonopoulos LLC</holder></copyright><editor role="production"><firstname>Melanie</firstname><surname>Yarbrough</surname></editor><editor role="copy"><firstname>Kim</firstname><surname>Cofer</surname></editor><othercredit role="indexer"><firstname>WordCo</firstname><surname>Indexing Services</surname></othercredit><othercredit role="coverdesigner"><firstname>Karen</firstname><surname>Montgomery</surname></othercredit><othercredit role="interiordesigner"><firstname>David</firstname><surname>Futato</surname></othercredit><printhistory><formalpara><title>First Edition</title><para>December, 2014</para></formalpara></printhistory><revhistory><revision><date>2014-12-01</date><revremark>First release</revremark></revision><revision><date>2015-03-06</date><revremark>Second release</revremark></revision></revhistory>
|
||||
<mediaobject role="cover"> <!-- source in the cover -->
|
||||
<imageobject role="front-large" remap="lrg">
|
||||
<imagedata format="PNG" fileref="images/cover.png"/>
|
||||
|
||||
@ -1149,17 +1149,17 @@ Many more libraries exist in a variety of other programming languages and more a
|
||||
|
||||
The ((("libbitcoin library")))((("libraries, alternative","libbitcoin library")))libbitcoin library is a cross-platform C++ development toolkit that supports the ((("Bitcoin Server")))((("libraries, alternative","Bitcoin Server")))libbitcoin-server full node and the ((("Bitcoin Explorer")))((("libraries, alternative","Bitcoin Explorer")))Bitcoin Explorer (bx) command line tool.
|
||||
|
||||
The bx commands offer many of the same capabilities as the bitcoind client commands we illustrated in this chapter. The bx commands also offer some key management and manipulation tools that are not offered by bitcoind, including type-2 deterministic keys and mnemonic key encoding, as well as stealth address, payment and query support.
|
||||
The bx commands offer many of the same capabilities as the bitcoind client commands we illustrated in this chapter. The bx commands also offer some key management and manipulation tools that are not offered by bitcoind, including type-2 deterministic keys and mnemonic key encoding, as well as stealth address, payment, and query support.
|
||||
|
||||
===== Installing Bitcoin Explorer
|
||||
|
||||
((("Bitcoin Explorer","installing")))To use Bitcoin Explorer simply download the signed executable for your operating system. Builds are available for mainnet and testnet for Linux, OSX and Windows.
|
||||
((("Bitcoin Explorer","installing")))To use Bitcoin Explorer, simply download the signed executable for your operating system. Builds are available for mainnet and testnet for Linux, OS X, and Windows.
|
||||
|
||||
https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download
|
||||
|
||||
Type +bx+ with no parameters to display the list of all available commands (see <<appdx_bx>>).
|
||||
|
||||
Bitcoin Explorer also provides an installer for building from sources on Linux and OSX as well as Visual Studio projects for Windows. Sources can also be built manually using Autotools. These also install the ((("libbitcoin library","installing")))libbitcoin library dependency.
|
||||
Bitcoin Explorer also provides an installer for building from sources on Linux and OS X, as well as Visual Studio projects for Windows. Sources can also be built manually using Autotools. These also install the ((("libbitcoin library","installing")))libbitcoin library dependency.
|
||||
|
||||
https://github.com/libbitcoin/libbitcoin-explorer/wiki/Build
|
||||
|
||||
@ -1170,13 +1170,13 @@ Bitcoin Explorer offers many useful commands for encoding and decoding addresses
|
||||
|
||||
===== Installing Libbitcoin
|
||||
|
||||
((("libbitcoin library","installing")))The libbitcoin library provides an installer for building from sources on Linux and OSX as well as Visual Studio projects for Windows. Sources can also be built manually using Autotools.
|
||||
((("libbitcoin library","installing")))The libbitcoin library provides an installer for building from sources on Linux and OS X, as well as Visual Studio projects for Windows. Sources can also be built manually using Autotools.
|
||||
|
||||
https://github.com/libbitcoin/libbitcoin/wiki/Build
|
||||
|
||||
[TIP]
|
||||
====
|
||||
The Bitcoin Explorer installer installs both bx and the libbitcoin library, so if you have built bx from sources you can skip this step.
|
||||
The Bitcoin Explorer installer installs both bx and the libbitcoin library, so if you have built bx from sources, you can skip this step.
|
||||
====
|
||||
|
||||
==== pycoin
|
||||
|
||||
@ -292,6 +292,10 @@ 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 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")))
|
||||
|
||||
++++
|
||||
<?hard-pagebreak?>
|
||||
++++
|
||||
|
||||
[[base58check_versions]]
|
||||
.Base58Check version prefix and encoded result examples
|
||||
[options="header"]
|
||||
@ -354,6 +358,10 @@ Address: 1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK
|
||||
|
||||
<<table_4-3>> shows the private key generated in these three formats.
|
||||
|
||||
++++
|
||||
<?hard-pagebreak?>
|
||||
++++
|
||||
|
||||
[[table_4-3]]
|
||||
.Example: Same key, different formats
|
||||
[options="header"]
|
||||
@ -443,7 +451,7 @@ K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A<?pdf-cr?>
|
||||
[[comp_pub]]
|
||||
===== Compressed public keys
|
||||
|
||||
((("compressed public keys", id="ix_ch04-asciidoc16", range="startofrange")))((("public keys","compressed", id="ix_ch04-asciidoc17", range="startofrange")))Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 520 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain.
|
||||
pass:[<?dbhtml orphans="4"?>]Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database. Most transactions include the public key, required to validate the owner's credentials and spend the bitcoin. Each public key requires 520 bits (prefix \+ x \+ y), which when multiplied by several hundred transactions per block, or tens of thousands of transactions per day, adds a significant amount of data to the blockchain.((("compressed public keys", id="ix_ch04-asciidoc16", range="startofrange")))((("public keys","compressed", id="ix_ch04-asciidoc17", range="startofrange")))
|
||||
|
||||
As we saw in the section <<pubkey>>, a public key is a point (x,y) on an elliptic curve. Because the curve expresses a mathematical function, a point on the curve represents a solution to the equation and, therefore, if we know the _x_ coordinate we can calculate the _y_ coordinate by solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to store only the _x_ coordinate of the public key point, omitting the _y_ coordinate and reducing the size of the key and the space required to store it by 256 bits. An almost 50% reduction in size in every transaction adds up to a lot of data saved over time!
|
||||
|
||||
@ -555,7 +563,7 @@ include::code/ec-math.py[]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The example above uses +os.urandom+ which reflects a cryptographically secure random number generator (CSRNG) provided by the underlying operating system. In the case of UNIX-like operating system such as Linux, it draws from +/dev/urandom+ and in the case of Windows calls +CryptGenRandom()+. If a suitable randomness source is not found, +NotImplementedError+ will be raised. While the random number generator used here is for demonstration purposes, it is _not_ appropriate for generating production-quality bitcoin keys as it is not implemented with sufficient security.
|
||||
The example above uses +os.urandom+, which reflects a cryptographically secure random number generator (CSRNG) provided by the underlying operating system. In the case of an UNIX-like operating system such as Linux, it draws from +/dev/urandom+; and in the case of Windows, calls +CryptGenRandom()+. If a suitable randomness source is not found, +NotImplementedError+ will be raised. While the random number generator used here is for demonstration purposes, it is _not_ appropriate for generating production-quality bitcoin keys as it is not implemented with sufficient security.
|
||||
====
|
||||
|
||||
[[ec_math_run]]
|
||||
@ -887,7 +895,7 @@ A pay-to-script hash address is created from a transaction script, which defines
|
||||
script hash = RIPEMD160(SHA256(script))
|
||||
----
|
||||
|
||||
((("script hashes")))The resulting "script hash" is encoded with Base58Check with a version prefix of 5, which results in an encoded address starting with a +3+. An example of a P2SH address is +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the Bitcoin Explorer commands((("Bitcoin Explorer","script-encode command")))((("script-encode command (bx)"))) +script-encode+,((("Bitcoin Explorer","sha256 command")))((("sha256 command (bx)"))) +sha256+,((("Bitcoin Explorer","ripemd160 command")))((("ripemd160 command (bx)"))) +ripemd160+ and((("Bitcoin Explorer","base58check-encode command")))((("base58check-encode command (bx)"))) +base58check-encode+ (see <<libbitcoin>>) as follows:
|
||||
((("script hashes")))The resulting "script hash" is encoded with Base58Check with a version prefix of 5, which results in an encoded address starting with a +3+. An example of a P2SH address is +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the Bitcoin Explorer commands((("Bitcoin Explorer","script-encode command")))((("script-encode command (bx)"))) +script-encode+,((("Bitcoin Explorer","sha256 command")))((("sha256 command (bx)"))) +sha256+,((("Bitcoin Explorer","ripemd160 command")))((("ripemd160 command (bx)"))) +ripemd160+, and((("Bitcoin Explorer","base58check-encode command")))((("base58check-encode command (bx)"))) +base58check-encode+ (see <<libbitcoin>>) as follows:
|
||||
|
||||
----
|
||||
$ echo dup hash160 [ 89abcdefabbaabbaabbaabbaabbaabbaabbaabba ] equalverify checksig > script
|
||||
|
||||
@ -37,7 +37,7 @@ Once a transaction has been created, it is signed by the owner (or owners) of th
|
||||
|
||||
((("bitcoin network","propagating transactions on")))((("transactions","propagating")))Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is connected, and a success message will be returned synchronously to the originator. If the transaction is invalid, the node will reject it and synchronously return a rejection message to the originator.
|
||||
|
||||
The bitcoin network is a peer-to-peer network, meaning that each bitcoin node is connected to a few other bitcoin nodes that it discovers during startup through the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed topology or any structure, making all nodes equal peers. Messages, including transactions and blocks, are propagated from each node to all the peers to which it is connected, a process called "flooding". A new validated transaction injected into any node on the network will be sent to all of the nodes connected to it (neighbors), each of which will send the transaction to all its neighbors, and so on. In this way, within a few seconds a valid transaction will propagate in an exponentially expanding ripple across the network until all nodes in the network have received it.
|
||||
The bitcoin network is a peer-to-peer network, meaning that each bitcoin node is connected to a few other bitcoin nodes that it discovers during startup through the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed topology or any structure, making all nodes equal peers. Messages, including transactions and blocks, are propagated from each node to all the peers to which it is connected, a process called "flooding." A new validated transaction injected into any node on the network will be sent to all of the nodes connected to it (neighbors), each of which will send the transaction to all its neighbors, and so on. In this way, within a few seconds a valid transaction will propagate in an exponentially expanding ripple across the network until all nodes in the network have received it.
|
||||
|
||||
The bitcoin network is designed to propagate transactions and blocks to all nodes in an efficient and resilient manner that is resistant to attacks. To prevent spamming, denial-of-service attacks, or other nuisance attacks against the bitcoin system, every node independently validates every transaction before propagating it further. A malformed transaction will not get beyond one node. The rules by which transactions are validated are explained in more detail in <<tx_verification>>.(((range="endofrange", startref="ix_ch05-asciidoc1")))
|
||||
|
||||
@ -457,7 +457,7 @@ When executed, this combined script will evaluate to TRUE if, and only if, the u
|
||||
|
||||
((("ledger, storing unrelated information in")))((("OP_RETURN operator")))((("transactions","storing unrelated information in")))Bitcoin's distributed and timestamped ledger, the blockchain, has potential uses far beyond payments. Many developers have tried to use the transaction scripting language to take advantage of the security and resilience of the system for applications such as((("digital notary services")))((("smart contracts")))((("stock certificates"))) digital notary services, stock certificates, and smart contracts. Early attempts to use bitcoin's script language for these purposes involved creating transaction outputs that recorded data on the blockchain; for example, to record a digital fingerprint of a file in such a way that anyone could establish proof-of-existence of that file on a specific date by reference to that transaction.
|
||||
|
||||
((("blockchains","storing unrelated information in")))The use of bitcoin's blockchain to store data unrelated to bitcoin payments is a controversial subject. Many developers consider such use abusive and want to discourage it. Others view it as a demonstration of the powerful capabilities of blockchain technology and want to encourage such experimentation. Those who object to the inclusion of non-payment data argue that it causes "blockchain bloat," burdening those running full bitcoin nodes with carrying the cost of disk storage for data that the blockchain was not intended to carry. Moreover, such transactions create UTXO that cannot be spent, using the destination bitcoin address as a free-form 20-byte field. Because the address is used for data, it doesn't correspond to a private key and the resulting UTXO can _never_ be spent; it's a fake payment. These transactions that can never be spent are therefore never removed from the UTXO set and cause the size of the UTXO database to forever increase, or "bloat".
|
||||
((("blockchains","storing unrelated information in")))The use of bitcoin's blockchain to store data unrelated to bitcoin payments is a controversial subject. Many developers consider such use abusive and want to discourage it. Others view it as a demonstration of the powerful capabilities of blockchain technology and want to encourage such experimentation. Those who object to the inclusion of non-payment data argue that it causes "blockchain bloat," burdening those running full bitcoin nodes with carrying the cost of disk storage for data that the blockchain was not intended to carry. Moreover, such transactions create UTXO that cannot be spent, using the destination bitcoin address as a free-form 20-byte field. Because the address is used for data, it doesn't correspond to a private key and the resulting UTXO can _never_ be spent; it's a fake payment. These transactions that can never be spent are therefore never removed from the UTXO set and cause the size of the UTXO database to forever increase, or "bloat."
|
||||
|
||||
In version 0.9 of the Bitcoin Core client, a compromise was reached with the introduction of the +OP_RETURN+ operator. +OP_RETURN+ allows developers to add 40 bytes of nonpayment data to a transaction output. However, unlike the use of "fake" UTXO, the +OP_RETURN+ operator creates an explicitly _provably unspendable_ output, which does not need to be stored in the UTXO set. +OP_RETURN+ outputs are recorded on the blockchain, so they consume disk space and contribute to the increase in the blockchain's size, but they are not stored in the UTXO set and therefore do not bloat the UTXO memory pool and burden full nodes with the cost of more expensive RAM.
|
||||
|
||||
|
||||
@ -63,7 +63,7 @@ image::images/msbt_0603.png["BitcoinNetwork"]
|
||||
|
||||
The peer node responds with +verack+ to acknowledge and establish a connection, and optionally sends its own +version+ message if it wishes to reciprocate the connection and connect back as a peer.
|
||||
|
||||
How does a new node find peers? The first method is to query DNS using a number of ((("nodes","seed")))((("DNS seed")))"DNS seeds", which are DNS servers that provide a list of IP addresses of bitcoin nodes. Some of those DNS seeds provide a static list of IP addresses of stable bitcoin listening nodes. Some of the DNS seeds are custom implementations of BIND (Berkeley Internet Name Daemon) that return a random subset from a list of bitcoin node addresses collected by a crawler or a long-running bitcoin node. The Bitcoin Core client contains the names of five different DNS seeds. The diversity of ownership and diversity of implementation of the different DNS seeds offers a high level or reliability for the initial bootstrapping process. In the Bitcoin Core client, the option to use the DNS seeds is controlled by the option switch +-dnsseed+, which is set to 1, to use the DNS seed, by default.
|
||||
How does a new node find peers? The first method is to query DNS using a number of ((("nodes","seed")))((("DNS seed")))"DNS seeds," which are DNS servers that provide a list of IP addresses of bitcoin nodes. Some of those DNS seeds provide a static list of IP addresses of stable bitcoin listening nodes. Some of the DNS seeds are custom implementations of BIND (Berkeley Internet Name Daemon) that return a random subset from a list of bitcoin node addresses collected by a crawler or a long-running bitcoin node. The Bitcoin Core client contains the names of five different DNS seeds. The diversity of ownership and diversity of implementation of the different DNS seeds offers a high level or reliability for the initial bootstrapping process. In the Bitcoin Core client, the option to use the DNS seeds is controlled by the option switch +-dnsseed+, which is set to 1, to use the DNS seed, 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 seed. After the initial seed node is used to form introductions, the client will disconnect from it and use the newly discovered peers.
|
||||
|
||||
|
||||
@ -153,14 +153,14 @@ Looking at this new block, the node finds the +previousblockhash+ field, which c
|
||||
|
||||
A _merkle tree_, also known as a((("binary hash tree"))) _binary hash tree_, is a data structure used for efficiently summarizing and verifying the integrity of large sets of data. Merkle trees are binary trees containing cryptographic hashes. The term "tree" is used in computer science to describe a branching data structure, but these trees are usually displayed upside down with the "root" at the top and the "leaves" at the bottom of a diagram, as you will see in the examples that follow.
|
||||
|
||||
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.
|
||||
|
||||
When N data elements are hashed and summarized in a merkle tree, you can check to see if any one data element is included in the tree with at most +2*log~2~(N)+ calculations, making this a very efficient data structure.
|
||||
|
||||
[[chain_of_blocks]]
|
||||
.Blocks linked in a chain, by reference to the previous block header hash
|
||||
image::images/msbt_0701.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.
|
||||
|
||||
When N data elements are hashed and summarized in a merkle tree, you can check to see if any one data element is included in the tree with at most +2*log~2~(N)+ calculations, making this a very efficient data structure.
|
||||
|
||||
The merkle tree is constructed bottom-up. In the following example, we start with four transactions, A, B, C and D, which form the _leaves_ of the Merkle tree, as shown in <<simple_merkle>>. The transactions are not stored in the merkle tree; rather, their data is hashed and the resulting hash is stored in each leaf node as H~A~, H~B~, H~C~, and H~D~:
|
||||
|
||||
----
|
||||
@ -187,12 +187,12 @@ 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 <<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.
|
||||
|
||||
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")))((("merkle path"))) _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 10 or 12 hashes (320–384 bytes), which can provide proof of a single transaction out of more than a thousand transactions in a megabyte-size block.
|
||||
|
||||
[[merkle_tree_large]]
|
||||
.A merkle tree summarizing many data elements
|
||||
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")))((("merkle path"))) _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 10 or 12 hashes (320–384 bytes), which can provide proof of a single transaction out of more than a thousand transactions in a megabyte-size block.
|
||||
|
||||
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]]
|
||||
@ -202,6 +202,10 @@ 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.
|
||||
|
||||
++++
|
||||
<?hard-pagebreak?>
|
||||
++++
|
||||
|
||||
[[merkle_example]]
|
||||
.Building a merkle tree
|
||||
====
|
||||
|
||||
@ -26,9 +26,13 @@ In this chapter, we will first examine mining as a monetary supply mechanism and
|
||||
|
||||
In November 2012, the new bitcoin issuance rate was decreased to 25 bitcoins per block and it will decrease again to 12.5 bitcoins at block 420,000, which will be mined sometime in 2016. The rate of new coins decreases like this exponentially over 64 "halvings" until block 13,230,000 (mined approximately in year 2137), when it reaches the minimum currency unit of 1 satoshi. Finally, after 13.44 million blocks, in approximately 2140, almost 2,099,999,997,690,000 satoshis, or almost 21 million bitcoins, will be issued. Thereafter, blocks will contain no new bitcoins, and miners will be rewarded solely through the transaction fees. <<bitcoin_money_supply>> shows the total bitcoin in circulation over 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/msbt_0801.png["BitcoinMoneySupply"]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The maximum number of coins mined is the _upper limit_ of possible mining rewards for bitcoin. In practice, a miner may intentionally mine a block taking less than the full reward. Such blocks have already been mined and more may be mined in the future resulting in a lower total issuance of the currency
|
||||
The maximum number of coins mined is the _upper limit_ of possible mining rewards for bitcoin. In practice, a miner may intentionally mine a block taking less than the full reward. Such blocks have already been mined and more may be mined in the future, resulting in a lower total issuance of the currency.
|
||||
====
|
||||
|
||||
In the example code in <<max_money>>, we calculate the total amount of bitcoin that will be issued.
|
||||
@ -54,10 +58,6 @@ 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/msbt_0801.png["BitcoinMoneySupply"]
|
||||
|
||||
((("inflation, resisting")))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.
|
||||
|
||||
.Deflationary Money
|
||||
@ -518,10 +518,6 @@ include::code/proof-of-work-example.py[]
|
||||
|
||||
Running this code, you can set the desired difficulty (in bits, how many of the leading bits must be zero) and see how long it takes for your computer to find a solution. In <<pow_example_outputs>>, you can see how it works on an average laptop.
|
||||
|
||||
++++
|
||||
<?hard-pagebreak?>
|
||||
++++
|
||||
|
||||
[[pow_example_outputs]]
|
||||
.Running the proof of work example for various difficulties
|
||||
====
|
||||
@ -767,12 +763,12 @@ A "fork" occurs whenever there are two candidate blocks competing to form the lo
|
||||
|
||||
In <<fork2>>, we see two miners who mine two different blocks almost simultaneously. Both of these blocks are children of the blue block, meant to extend the chain by building on top of the blue block. To help us track it, one is visualized as a red block originating from Canada, and the other is marked as a green block originating from Australia.
|
||||
|
||||
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," his 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, and 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.
|
||||
|
||||
[[fork2]]
|
||||
.Visualization of a blockchain fork event: two blocks found simultaneously
|
||||
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," his 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, and 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.
|
||||
|
||||
As the two blocks propagate, some nodes receive block "red" first and some receive block "green" first. As shown in <<fork3>>, the network splits into two different perspectives of the blockchain, one side topped with a red block, the other with a green block.
|
||||
|
||||
[[fork3]]
|
||||
|
||||
@ -13,11 +13,11 @@ With new coins introduced every day, it would be impossible not to miss some imp
|
||||
|
||||
((("chains, alternative")))((("currencies, alternative")))Bitcoin is an open source project, and its code has been used as the basis for many other software projects. The most common form of software spawned from bitcoin's source code are alternative decentralized currencies, or _alt coins_, which use the same basic building blocks to implement digital currencies.
|
||||
|
||||
There are a number of protocol layers implemented on top of bitcoin's blockchain. These((("blockchain apps")))((("meta chains")))((("meta coin platforms"))) _meta coins_, _meta chains_, or _blockchain apps_ use the blockchain as an application platform or extend the bitcoin protocol by adding protocol layers. Examples include Colored Coins, Mastercoin, NXT and Counterparty.
|
||||
There are a number of protocol layers implemented on top of bitcoin's blockchain. These((("blockchain apps")))((("meta chains")))((("meta coin platforms"))) _meta coins_, _meta chains_, or _blockchain apps_ use the blockchain as an application platform or extend the bitcoin protocol by adding protocol layers. Examples include Colored Coins, Mastercoin, NXT, and Counterparty.
|
||||
|
||||
In the next section we will examine a few notable alt coins, such as Litecoin, Dogecoin, Freicoin, Primecoin, Peercoin, Darkcoin, and Zerocoin. These alt coins are notable for historical reasons or because they are good examples for a specific type of alt coin innovation, not because they are the most valuable or "best" alt coins.
|
||||
|
||||
In addition to the alt coins, there are also a number of alternative blockchain implementations that are not really "coins," which I call((("alt chains"))) _alt chains_. These alt chains implement a consensus algorithm and distributed ledger as a platform for contracts, name registration, or other applications. Alt chains use the same basic building blocks and sometimes also use a currency or token as a payment mechanism, but their primary purpose is not currency. We will look at Namecoin and Ethereum, as examples of alt chains.
|
||||
In addition to the alt coins, there are also a number of alternative blockchain implementations that are not really "coins," which I call((("alt chains"))) _alt chains_. These alt chains implement a consensus algorithm and distributed ledger as a platform for contracts, name registration, or other applications. Alt chains use the same basic building blocks and sometimes also use a currency or token as a payment mechanism, but their primary purpose is not currency. We will look at Namecoin and Ethereum as examples of alt chains.
|
||||
|
||||
Finally, there are a number of bitcoin contenders that offer digital currency or digital payment networks, but without using a decentralized ledger or consensus mechanism based on proof of work, such as Ripple and others. These non–blockchain technologies are outside the scope of this book and will not be covered in this chapter.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user