Errata

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

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

"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).

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

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

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

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

"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

"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%.

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

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

"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

Output #1 in the last transaction in the Figure shows Bob receiving 0.0845 BTC. I believe this should be 0.0045 BTC.

Note from the Author or Editor:
Corrected in second edition.

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

The Byzantine General's problem wasn't unsolved before the invention of Bitcoin - see Byzantine Paxos.

Furthermore, it didn't solve the Byzantine General's problem as it was originally stated. In fact, according to http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf: "using only oral (unreliable, forgable) messages, the problem is solvable if and only if more than two-thirds of the generals are loyal."

Bitcoin *was* an innovation in the field of distributed systems but I think this paragraph overstates the case.

Note from the Author or Editor:
Text changed to "Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem.""

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.

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.

The line:
"For examples using the command-line utilities ku and tx, see Appendix B"
this should in fact state and link to "Appendix C"

Note from the Author or Editor:
Corrected in second edition

[Resubmitted because the last one didn't have a page number]

The RPC client functionality has been removed from bitcoind, so instead of "$ bitcoind getblock..." it should now be: "$bitcoin-cli getblock..."

Note from the Author or Editor:
Corrected in latest edition

In the first command on page 181, there is a space missing between the block number and its resulting hash:

"$ bitcoin-cli getblockhash 2773160000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4"

Copying the command from the ebook version and pasting into the command line will throw an error.

It should instead read:

"$ bitcoin-cli getblockhash 277316 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4

Note from the Author or Editor:
The command is
bitcoin-cli getblockhash 277316
and the output of this command is
0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4

There should indeed be a space after 277316

Corrected in latest edition

The code for retargeting the proof-of-work difficulty has been significantly refactored:

https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp

Note from the Author or Editor:
Updated to reflect the new code in CalculateNextWorkRequired

"For high-value items, payment by bitcoin will still be convenient and efficient even if the buyer has to wait 24 hours for delivery, which would ensure 144 confirmations."

While 24 hours certainly ensures a sufficient number of confirmations for a transaction of almost any value, it doesn't necessarily ensure 144 (or more) confirmations.

Note from the Author or Editor:
Changed to "which would correspond to approximately 144 confirmations"

It is now:
"For example, the Proof of Existence digital notarization service uses the 8-byte prefix “DOCPROOF,” which is ASCII encoded as 44f4350524f4f46 in hexadecimal."

I think it should be:
"For example, the Proof of Existence digital notarization service uses the 8-byte prefix “DOCPROOF”, which is ASCII encoded as 444f4350524f4f46 in hexadecimal."

Changes:
- "DOCPROOF," to "DOCPROOF",
- "44f4350524f4f46" to "444f4350524f4f46"

Note from the Author or Editor:
Corrected to "44 4f 43 50 52 4f 4f 46" in second edition.