Mastering Bitcoin

Errata for Mastering Bitcoin

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 8
Independent Verification of Transactions

"By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid new transactions (the transaction pool), roughly in the same order." This is certainly not the case. The chaotic flood system and the lack of any synchronicity in transaction broadcasts means that nodes will almost never have identical memory pools. In private testing it was found that there was next to no consistency even in two nodes running on the same machine. The entire reason for the orphan pool existing is to attempt to mitigate this problem.

Note from the Author or Editor:
Changed to: "By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid new transactions (the transaction pool)." Ordering of transactions and set overlap are covered correctly and in more detail elsewhere in the chapter

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 8
Bitcoin Economics and Currency Creation

"Finally, after 13.44 million blocks, in approximately 2140, all 2,099,999,997,690,000 satoshis, or almost 21 million bitcoins, will be issued. " This is the maximum amount possible, not the actual amount. Not all blocks need to take the full reward, and in the past some blocks have taken less than the full reward intentionally. Therefor the quoted number will never be true.

Note from the Author or Editor:
Changed "all" to "almost" and added a note to clarify below: "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"

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 6
Introduction

"A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes, thereby adding those transactions to the blockchain." Ten minutes on average when viewed with a 2015 block sliding window.

Note from the Author or Editor:
Added "on average" to be strictly correct: Now reads: "A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes on average, thereby adding those transactions to the blockchain."

Anonymous  Dec 30, 2014  Mar 06, 2015
Other Digital Version
Chapter 5
Introduction

"A few thousand blocks back (a month) and the blockchain is settled history. It will never change." It is an imperative part of the Bitcoin system that this can change. There's no technical reason why a the entire chain couldn't be rewritten back to genesis. It's unlikely, but not impossible.

Note from the Author or Editor:
This had been corrected elsewhere but missed in this section. Now corrected to read: "A few thousand blocks back (a month) and the blockchain is settled history, for all practical purposes. While the protocol always allows a chain to be undone by a longer chain and while the possibility of any block being reversed always exists, the probability of such an event decreases as time passes until it becomes infinitesimal."

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 8
Difficulty Target and Retargeting

"The equation for retargeting difficulty measures the time it took to find the last 2,016 blocks and compares that to the expected time of 20,160 minutes (two weeks based upon a desired 10-minute block time)." Only 2015 blocks are observed, due to an off by one error in the original client.

Note from the Author or Editor:
Added a note to clarify: While the difficulty calibration happens every 2,016 blocks, due to an off-by-one error in the original Bitcoin Core client the retargeting is based on the total time of the previous 2,015 blocks (not 2,016 as it should be), resulting in a retargeting bias towards higher difficulty by 0.05%.

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 5
Network Discovery

"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." Nodes use DNS seeds, not fixed seeds wherever possible. They make an outgoing DNS request to a list of domains, which return known good addresses. The hardcoded seeds are only used if DNS fails.

Note from the Author or Editor:
This is in chapter 6, not chapter 5. Corrected this section and added more detail: 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.

Anonymous  Dec 30, 2014  Mar 06, 2015
Other Digital Version
Chapter 5
Benefits of Pay-to-Script-Hash

"P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set and therefore impacts memory) to the input (only stored on the blockchain)" The UTXO is not and has never been kept in memory. It's stored on disk in LevelDB.

Note from the Author or Editor:
Change language to omit the implementation-dependent storage issue: * P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set) to the input (stored on the blockchain).

Anonymous  Dec 30, 2014  Mar 06, 2015
Other Digital Version
Chapter 5
Transaction Structure

"If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not included in the blockchain prior to the specified time. " It is critical to understanding transactions that it is known that nLockTime is a validity rule not an inclusion one. A transaction attempted to be relayed before it's lock time has expired will be rejected, otherwise the memory pools of all nodes could be spammed full of transactions that won't be confirmed for years. This is a very common misunderstanding of how nLockTime works.

Note from the Author or Editor:
Additional language added to clarify the nLockTime effect on validity and propagation of transactions: ((("locktime")))((("transactions","locktime")))Locktime, also known as nLockTime from the variable name used in the reference client, defines the earliest time that a transaction is valid and can be relayed on the network or added to the blockchain. It is set to zero in most transactions to indicate immediate propagation and execution. If locktime is nonzero and below 500 million, it is interpreted as a block height, meaning the transaction is not valid and is not relayed or included in the blockchain prior to the specified block height. If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not valid prior to the specified time. Transactions with locktime specifying a future block or time must be held by the originating system and transmitted to the bitcoin network only after they become valid. The use of locktime is equivalent to postdating a paper check.

Anonymous  Dec 29, 2014  Mar 06, 2015
Other Digital Version
Chapter 5
Transaction Outputs

"UTXO are tracked by every full node bitcoin client in a database held in memory, called the UTXO set or UTXO pool. New transactions consume (spend) one or more of these outputs from the UTXO set." The UTXO is not and has never been kept in memory. It's stored on disk in LevelDB.

Note from the Author or Editor:
Where the UTXO set is held is dependent on the specific implementation. Language clarified to indicate that in the reference client the UTXO is held in a database: UTXO are tracked by every full-node bitcoin client as a data set called the((("UTXO pool")))((("UTXO set"))) _UTXO set_ or _UTXO pool_, held in a database. New transactions consume (spend) one or more of these outputs from the UTXO set.

Anonymous  Dec 30, 2014  Mar 06, 2015
Other Digital Version
N/A
Example 4-6

The example code given by the book in Example 4-6 for making vanity Bitcoin addresses uses a non-cryptographically secure RNG. All keys made with it can be broken by a third party with no further knowledge with a very low total complexity. Copying this example or using it in the real world to make a private key will certainly result in the loss of money. random_char = lambda: chr(random.randint(0, 255))

Note from the Author or Editor:
Replaced the use of Python's "random" library with os.urandom which uses the operating system's cryptographically secure RNG.

Anonymous  Dec 29, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page N/A
Example 4-9

Example 4-9 describes a vanity generator written in CPP. This code uses a non cryptographically secure random number generator with low total complexity. All keys made in the real world based on this code can be easily compromised by a remote attacker with no further information. To quote the book: "Do not write your own code to create a random number or use a "simple" random number generator offered by your programming language." To quote the CPP reference on the function used in the example: "It is the library implementation's selection of a generator that provides at least acceptable engine behavior for relatively casual, inexpert, and/or lightweight use." Any money sent to Bitcoin addresses made with this example code will be stolen.

Note from the Author or Editor:
Depending on the OS, random_device may use /dev/urandom or another source. Added a NOTE under the code section and a comment in the code to warn that this is for example use only and not a secure implementation: The example above uses +std::random_device+. Depending on the implementation it may reflect 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+. 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.

Anonymous  Dec 29, 2014  Mar 06, 2015
Other Digital Version
Chapter 5
Propagating Transactions on the Bitcoin Network

"A new validated transaction injected into any node on the network will be sent to 3 to 4 of the neighboring nodes, each of which will send it to 3 to 4 more nodes and so on" This is entirely incorrect. The Bitcoin network is a flood system, every peer broadcasts a valid message to all of their peers, not just three or four. All nodes have at minimum 8 peers (outgoing) and up to 118 incoming connections to the network. There is no basis for the number "3 to 4".

Note from the Author or Editor:
Corrected language (including paragraph with context): 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 all of the nodes connected to it (neighbors), each of which will send the transaction 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.

Anonymous  Dec 29, 2014  Mar 06, 2015
Other Digital Version
Chapter 4
Paper Wallets

"This is because in the process of unlocking and spending funds you expose the private key and because some wallets may generate a change address if you spend less than the whole amount. " Uh, no. By spending you most certainly do not expose the private key to anybody. The system would be entirely broken if this were the case, it would just be a race to re-spend every transaction as soon as it was broadcast.

Note from the Author or Editor:
The risk of private key exposure is due to the possibility that the computer used to generate the withdrawal transaction is compromised. Re-introducing the key to a computer system increases the risk of exposure. The relevant passage of the book has been clarified to avoid confusion: ((("paper wallets","spending")))((("private keys","exposing with paper wallets")))Although you can deposit funds into a paper wallet several times, you should withdraw all funds only once, spending everything. This is because in the process of unlocking and spending funds some wallets might generate a change address if you spend less than the whole amount. Additionally, if the computer you use to sign the transaction is compromised, you risk exposing the private key. By spending the entire balance of a paper wallet only once, you reduce the risk of key compromise. If you need only a small amount, send any remaining funds to a new paper wallet in the same transaction.

Anonymous  Dec 29, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 8
Consensus Attacks

"The massive increase of total hashing power has arguably made bitcoin impervious to attacks by a single miner. There is no possible way for a solo miner to control even 1% of the total mining power. " There's farms bigger than 3PH/s, saying that nobody can do it is completely insane. BitMainTech, Bitfury, KNC, and a number of private farms all own single and double digit percentages of the network. Some pools have controlled over 40% in the past, which has the same effect with little effort.

Note from the Author or Editor:
Pools are covered elsewhere, this refers to single miners. Corrected text for accuracy: "There is no possible way for a solo miner to control more than a small percentage of the total mining power"

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 8
Consensus Attacks

"Recent advancements in bitcoin, such as P2Pool mining, aim to further decentralize mining control, making bitcoin consensus even harder to attack." P2Pool actually makes attacks easier. You can do an internal attack on the share chain, meaning that if you have more than 50% of the P2Pool hash power you can receive 100% of the income of the pool. For this reason it's existence is very fragile and not really a solution, it is however extremely neat.

Note from the Author or Editor:
Removed that sentence, added more info in the P2Pool section "Even though P2Pool reduces the concentration of power by mining pool operators, it is conceivably vulnerable to 51% attacks against the share chain itself. A much broader adoption of P2Pool does not solve the 51% attack problem for bitcoin itself. Rather, P2Pool makes bitcoin more robust overall, as part of a diversified mining ecosystem."

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 9
Bitmessage

"Bitmessage is a bitcoin alt chain" Bitmessage is not a currency, or even a fork of Bitcoin. It does not have a block chain at all. It has no technical resemblance to Bitcoin other than it's name and it's use of Hashcash.

Note from the Author or Editor:
This section on Bitmessage has been removed from the book, as it is of little relevance

Anonymous  Dec 30, 2014  Mar 06, 2015
ePub, Mobi, Safari Books Online, Other Digital Version
Page Chapter 10
Balancing Risk

"In the summer of 2010" The earth has two hemispheres, saying "summer" is all but meaningless to an international audience.

Note from the Author or Editor:
Date corrected and converted to a global context: "In July of 2011"

Anonymous  Dec 30, 2014  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Chapter 5, following table 4-9

"$ bx seed | bx hd-seed > m ..." returns: The 'hd-seed' command has been replaced by 'hd-new'. Self-explanatory, but an easy fix.

Note from the Author or Editor:
The error is in Chapter 4, not Chapter 5. bx command hd-seed has now been renamed to hd-new. Corrected line reads: $ bx seed | bx hd-new > m # create a new master private key from a seed and store in file "m" This correction has been added to the second print edition

Samuel Atwood  Mar 02, 2015  Mar 06, 2015
PDF
Page 3
Uruguay

There are 3 quotations. In the first 2 it states the role and the organization. For Balaji it only says he's General Partner but doesn't mention A16Z.

Note from the Author or Editor:
In the section "Praise for this book" on the first page: Balaji S. Srinivasan's title should read "General Partner, Andreessen Horowitz (a16z.com)". It currently reads "General Partner" with no company affiliation

Sebastian Gonzalez  Dec 02, 2014  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 45
5th Paragraph

Instead of this: $ bitcoin-cli getrawtransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae30100000001d717279515f88e2f56ce4e8a31e2ae3e9f00ba1d0add648e80c480ea22e0c7d3000000008b483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5ceaffffffff02404b4c00000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac1f312906000000001976a914107b7086b31518935c8d28703d66d09b3623134388ac00000000 it should be as following: $ bitcoin-cli getrawtransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3 [SPACE] 0100000001d717279515f88e2f56ce4e8a31e2ae3e9f00ba1d0add648e80c480ea22e0c7d3000000008b483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5ceaffffffff02404b4c00000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac1f312906000000001976a914107b7086b31518935c8d28703d66d09b3623134388ac00000000

Note from the Author or Editor:
There is a missing space as a result of a pagination error, as this errata report indicates. Fixed in second print.

Shayan Eskandari  Feb 17, 2015  Mar 06, 2015
PDF
Page 49
3rd paragraph

$ bitcoin-cli getblockhash 0000000000019d6689c085ae165831e934ff763ae46a2a6c17↵ 2b3f1b60a8ce26f should be $ bitcoin-cli getblockhash 0

Note from the Author or Editor:
This should be corrected as follows - The first zero is on the same line as the command, the rest of the long number is the "result" and should appear on the next line. Somehow the two lines got joined together. Should look like this: $ bitcoin-cli getblockhash 0 000000000019d6689c085ae165831e934ff763ae46a2a6c17↵ 2b3f1b60a8ce26f

Anonymous  Dec 11, 2014  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 55
3rd paragraph

instead of this: $ bitcoin-cli sendrawtransaction0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346 It should be this: $ bitcoin-cli sendrawtransaction[SPACE] 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346 [SPACE] : just a space character is missing here

Note from the Author or Editor:
There is a pagination/spacing error as indicated here. It has been fixed in the second print.

Shayan Eskandari  Feb 17, 2015  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 68
7th Paragraph

There is a typo (minor technical issue) on this line: "It turns out that + is associative, which means that (A+B)C = A(B+C). That means we can write A+B+C without parentheses without any ambiguity." However this is wrong, it should be corrected to this: ( A + B ) + C = A + ( B + C )

Note from the Author or Editor:
The plus signs missing in the text were "swallowed" by the post-processing engine. This has been fixed in the next print. Should read: ( A + B ) + C = A + ( B + C )

Shayan Eskandari  Feb 17, 2015  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 75
Example 4-2

Seems that API of libbitcoin has been changed. The following line produces an error bc::ec_secret secret = bc::decode_hash("038109007313a5807b2eccc082c8c3fbb988a973cacf1a7df9ce725c31b14776"); The program builds, if above line changed as follows bc::ec_secret secret; bc::decode_hash(secret, "038109007313a5807b2eccc082c8c3fbb988a973cacf1a7df9ce725c31b14776"); However, generated public key and address do not match those shown in example 4-3.

Note from the Author or Editor:
Several changes throughout the book for the second print, to update for libbitcoin2. The example code here only works with libbitcoin1

Artem Lenskiy  Feb 15, 2015  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 82
third full "code paragraph" down, about 1/3 of the way down the page

The following line will throw an error due to the removal of the "base10_multiply()" function from pybitcointools: public_key = bitcoin.base10_multiply(bitcoin.G, decoded_private_key) The function "fast_multiply()" appears to be its replacement: public_key = bitcoin.fast_multiply(bitcoin.G, decoded_private_key)

Note from the Author or Editor:
pybitcointools has been updated. As the submission indicates, the equivalent function is now fast_multiply() The line in the code: public_key = bitcoin.base10_multiply(bitcoin.G, decoded_private_key) now becomes: public_key = bitcoin.fast_multiply(bitcoin.G, decoded_private_key) This change has been included in the second print on March 6th

Samuel Atwood  Mar 02, 2015  Mar 06, 2015
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page 131
2nd and 3rd full paragraphs

"OP_RETURN allows developers to add 40 bytes of non-payment data..." "The data portion is limited to 40 bytes..." The default maximum size of the OP_RETURN payload has recently been increased to 80 bytes: https://github.com/bitcoin/bitcoin/pull/5286

Note from the Author or Editor:
Changed to 80 bytes in text and added: Two new command line options have been added in Bitcoin Core as of version 0.10. The option +datacarrier+ controls relay and mining of OP_RETURN transactions, with the default set to "1" (allowing OP_RETURN). The option +datacarriersize+ takes a numeric argument specifying the maximum size in bytes of the OP_RETURN data, 80 bytes by default. [NOTE] ==== OP_RETURN was initially proposed with a limit of 80 bytes, but was further restricted to 40 bytes when released. In February 2015, in version 0.10 of Bitcoin Core, the limit was raised back to 80 bytes. Nodes may choose not to relay or mine OP_RETURN, or only relay and mine OP_RETURN containing less than 80 bytes of data. ====

Samuel Atwood  Mar 03, 2015  Mar 06, 2015
Printed
Page 146
2nd from last paragraph

Formatting typo: "Peered nodes will exchange a%605.420%%% getblocks message..."

Note from the Author or Editor:
Corrected to remove "junk" from text

Samuel Atwood  Mar 04, 2015  Mar 06, 2015