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
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

Anonymous  Dec 30, 2014 
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.

Anonymous  Dec 29, 2014 
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.

Anonymous  Dec 30, 2014 
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 
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.

Anonymous  Dec 29, 2014 
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 
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