bitcoinbook / bitcoinbook

Mastering Bitcoin 3rd Edition - Programming the Open Blockchain

Mastering Bitcoin

Mastering Bitcoin is a technical book that explains what Bitcoin is and how it works.

This repository contains the complete text of three editions of the book Mastering Bitcoin as published in paperback and ebook formats by O'Reilly Media. Different editions of this book are covered by different open licenses (see LICENSE). The three editions are:

• The first edition, second print, published in December 2014
• The second edition, third print, published in March 2018
• The third edition, first print, published in December 2023

Reading This Book

To read this book for free, see BOOK.md. Click on each of the chapters to read in your browser.

Please note that some of the links in each chapter do not work when reading the book on Github. This is because those links are intended for the print and ebook editions of the book and only work when all the chapters are rendered together. Unfortunatelly, Github does not have the ability to render the complete book at once.

Where is the PDF?

The current edition is not available as a PDF, deliberately. Why? Because the publisher (O'Reilly Media) is a for-profit publisher who puts considerable resources behind producing, editing and distributing this book. The third edition of "Mastering Bitcoin" is available under a CC-BY-NC-ND license, not a CC-BY-SA license. The book will eventually (within a year of publication) be released under a CC-BY-SA license, at which point PDF copies and translations will be allowed (a PDF is a "derivative" product, which is what the "ND-NoDerivatives" part of the license prohibits).

Making PDF copies violates the license and interferes with the publisher's and the authors' ability to earn from their work. Furthermore, if you make it so the publisher can't recoup their investment, they may delay the release into CC-BY-SA. A beautifully rendered PDF or epub version of this book is offered for sale by the publisher. Convenient packaging is the for-profit product, whereas the version available here is slightly less convenient but entirely free for personal and non-commercial use. If you want convenience and nice packaging, buy the book!

Please don't create or distribute PDFs until the license is changed to CC-BY-SA. It is rare for a publisher to even agree to a CC-BY-NC-ND license. Don't make it harder for free culture by violating even that, already generous, license.

Mastering Bitcoin Third Edition

"Mastering Bitcoin: Programming the Open Blockchain (3rd Edition)" is now available in paperback and ebook formats by many booksellers worldwide, such as:

• EBooks.com
• Amazon
• Barnes and Noble

The tag third_edition_print_1 corresponds to the first print of the third edition of Mastering Bitcoin as published in paperback and ebook by O'Reilly Media in December 2023.

Mastering Bitcoin: Programming the Open Blockchain (Third Edition) by Andreas M. Antonopoulos, David A. Harding is licensed under Attribution-NonCommercial-NoDerivatives 4.0 International

Other Editions and Languages

Mastering Bitcoin - First Edition

The tags Edition1Print1, Edition1Print2 correspond to the two existing prints of Mastering Bitcoin (First Edition) as published by O'Reilly Media.

Mastering Bitcoin - First Edition by aantonop Books LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Mastering Bitcoin - Second Edition

The tags, second_edition_print_1 second_edition_print2, second_edition_print3, correspond to the first (June 8th, 2017), second (July 20th, 2017) and third (March 23rd, 2018) print of Mastering Bitcoin (Second Edition), as published by O'Reilly Media.

Mastering Bitcoin - Second Edition by aantonop Books LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Mastering Bitcoin (Open Second Edition), based on the Seond Edition, is also available in English and Spanish at https://aantonop.com. Mastering Bitcoin 2nd Edition is also published in German, Polish, Japanese, Korean, Chinese and other languages by publishers in the respective countries.

Issues, Errors, Comments, Contributions

To contribute to this book, see CONTRIBUTING.md. All contributions must be your original work and contributed under a public domain (CC0), or attribution (CC-BY) license. You must include your own attribution in the pull request, as an edit to the github_contrib.asciidoc file.

If you know how to make a pull request to contribute a fix, please write the correction and use a pull request to submit it for consideration against the develop branch. If you are making several changes, please use a separate commit for each to make it easier to cherry-pick or resolve conflicts. Otherwise, please submit an issue, explaining the error or comment. If you would like to contribute extensive changes or new material, please coordinate with the author first; contact information can be found on his website: https://aantonop.com/

Translations

If you are interested in translating this book, please join our team of volunteers at: https://www.transifex.com/bitcoinbook/mastering-bitcoin/

bitcoinbook's Issues

Chapter 4: Incorrect elliptical curve addition graph

The graph showing G + G = 2G derived from a tangent line from the point G continues the pattern of addition of 2G + 2G as a tangent but calls the result 3G instead of 4G. This pattern continues.

My understanding the tangent of G derives 2G. 2G is used to derive 4G, etc which is done 256 times to create the terms which should be added together (by drawing a line between points) based on each bit of the private key.

This shows how the public key could be derived in approximately 512 addition processes or less. The way it is currently displayed leads the reader to think it requires a lot more addition processes to calculate (in my opinion)

Now including comments on chap 2

Hi, Have just reviewed chap 2 and tried to put some comments in there. Again, review is from a beginner's perspective. Regards, James

Chapter 1

"be they are legitimate governments or criminal elements, "
correct:
"be they legitimate governments or criminal elements, "

"Using one of the applications or websites above, Joe determines the price of bitcoin to be approximately $100 US dollars per bitcoin. At that rate he should give Alice 0.10 bitcoin, also known as 100 millibits, in return for the $10 US dollars she gave him."
may be more correct:
"Using one of the applications or websites above, Joe determines the price of bitcoin to be approximately $500 US dollars per bitcoin. At that rate he should give Alice 0.02 bitcoin, also known as 20 millibitcoins or 20 000 bits in return for the $10 US dollars she gave him."

Chapter 9: Suggestion to Mention Coinye

http://en.wikipedia.org/wiki/Coinye
Probably the first coin that was abandoned due to filing of a trademark infringement lawsuit against its creators.

Chapter 8 - code example missing?

Following the paragraph "With these calculations, Jing's node then constructs the generation transaction to pay himself 25.09094928 bitcoin. The generation transaction is the first transaction in the block, so we can see it in more detail using the Bitcoin Core command-line interface:"

is there supposed to be sample code?

Chapter 8 - Aggregating Transactions into Blocks

In 4th paragraph:
"...Jing’s node has assembled a chain of 277,314 blocks. Jing’s node is listening for transactions, trying to mine a new block and also listening for blocks discovered by other nodes. As Jing’s node is mining, it receives block 277,315 through the bitcoin network."

If there are 277,314 blocks in the chain (including the genesis block on height 0), the last block would have block height 277,313 .Thus, the next block received would be 277,314 - Not 277.315.
To fix this, I would suggest changing the paragraph to:
"...Jing’s node has assembled a chain of 277,315 blocks...."

Double-spending problem

The way I have started to talk about the double-spending problem (which I've also renamed "transaction reversal attacks") is:

Suppose that I have 100 BTC, and I sign a transaction sending the 100 BTC to you. Then, the next day, I also sign a transaction sending the same 100 BTC to my friend George. Both of those transactions cannot happen at the same time, so which one succeeds? The answer is, the one that came first. However, there is no way to cryptographically look at a piece of data and see when it was produced. Thus, there needs to be some kind of external mechanism that exists in order to keep time.

Feel free to use something like this.

Ch 05 - Script Construction (Lock + Unlock)

In the third paragraph under Script Construction (Lock + Unlock):
“In this book we refer to it as an "unlocking script" to acknowledge the much broader range of locking script requirements, as not all unlocking scripts must contain signatures.”

Perhaps “locking script requirements” should be “unlocking script requirements" ?

Chapter 4: Suggestion to add Swift/RIPEMD implementation/code of Elliptic Curve cryptography

I implemented Elliptic Curve cryptography from scratch in Swift. Perhaps some of the code might be useful in chapter 4?

For example multiplication is implemented here in terms of addition and doubling. Here I'm converting a public key point into an address.

Chapter 9 commentary

Thank you for the opportunity to provide feedback on your work!

I might add a little more information regarding the algorithms used and how they impact the networks. ASICs play a large factor in the long term viability of a coin as it drastically increases the efficiency and decreases power consumption. There's a point at which the adoption of an algorithm reaches a critical mass and the ability to develop and mass produce ASICs becomes profitable. While Bitcoin was all that was necessary for SHA-256, hashrates for coins shown on liteshack.com shows that the ecosystem of Scrypt coins in circulation represents a siginficant portion of the financial drive for Scrypt ASICs not just Litecoin.

At this point it should be said that the speculation on altcoins, even Litecoin, is that they will fulfill their stated use case and many coins launched this year have already had all of their available wealth extracted and have already died (the blockchains have stopped moving).

If blockchain technology isn't already in use "behind the scenes" in many applications it may very well be in the next few months. The ability for a decentralized ledger with triple entry accounting has value outside of simple currencies. When it comes to non-currency applications, the Cambrian explosion in the altmarket has created several valuable new technologies, such as the various methods for difficulty regulation, and maintained several older technologies that are not really popular with Bitcoin, such as merged mining. These sorts of "experiments" are invaluable when leveraged against the development of things such as non-monetized blockchains for elections or access control.

Chapter 3: gettransaction example only works with indexing turned on

seems that this command: "bitcoind gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3" doesn't work anymore. Probably is for this reason
http://bitcoin.stackexchange.com/questions/9147/getrawtransaction-error-code-5

But I'm a noob in the Bitcoindev ecosystem, let me know what's the problem if not that!

Chapter 8 - Difficulty Representation

"...
⇒ target = 238,348 * 2^176
⇒ target = 9,223,372,036,854,775,807"

Where did "9,223,372,036,854,775,807" come from?

I get: 238,348 * 2^176 =
22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328

Chapter 4: Figure 7

The text under the figure is:
“Type-1 Deterministic Wallet: A Chain of Keys Generated from a Seed”

Not totally sure about this, but I think that should be Type-2.

Ch 1 Grammar and clarification

specific suggestions forthcoming

A few useful pictures that I made

http://vitalik.ca/files/address.png
http://vitalik.ca/files/fraud.png
http://vitalik.ca/files/nuhuh.png
http://vitalik.ca/files/sybil.png
http://vitalik.ca/files/spv.png

Fee free to modify or use at will.

Chapter 4

Hi, Andreeas,

"and check that it is less than n-1"
correct:
"and check that it is less than n"

I think that instead of bitcoind now bitcoin-cli should be used

Elliptic addition of two points would be also useful to see, and augment explanation that after "computing" G, 2G, 4G, 8G, 16G, etc the appropriate terms can be added.

public key for k = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD is incorrect, bitaddress.org says 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB

"Each public key requires 513 bytes"
correct:
"Each public key requires 65 bytes"

Comments and Corrections from Minh

In chapter 1, "Getting started" you write

"Conversely, if a user has a full client without adequate backups, they may lose their funds through a computer mishap. "

I suggest changing "they" into "he or she", since in the first sentence you used the singular form of "user".

In chapter 1, "Quick Start", you write

"she opens the blockchain.info wallet page at https://blockchain.info/wallet and selects "Start a New Wallet""

Note that on the actual blockchain.info/wallet page, the A in "Start A New Wallet" is capitalized, whereas in your book it's not. I suggest actually fixing the website button for consistency.

In chapter 2, "Buying a cup of coffee", you write

a "payment request" is a QR encoded URL that contains a destination address, a payment amount and a generic description such as "Bob's Cafe"

In your payment URL example it actually has four things. Do you want to mention that recipient label as well?

In chapter 2, "Bitcoin mining", you write

"as this book is written, by 2014, the difficulty is so high that it is only profitable to mine with Application Specific Integrated Circuits, essentially hundreds of mining algorithms printed in hardware"

I recommend putting the abbreviation (ASIC) after you use the word Application Specific Integrated Circuits for the first time here, especially because you use the abbreviation later in the paragraph.

In chapter 3, at the end of the "Compiling the client from the source code" chapter you used a different password in the bitcoin configuration file than the one that bitcoind recommended.

Bitcoind suggested

rpcuser=bitcoinrpc
rpcpassword=2XA4DuKNCbtZXsBQRRNDEwEY2nM6M4H9Tx5dFjoAVVbK

but the bitcoin.conf you created has

rpcuser=bitcoinrpc
rpcpassword=7p687uGU8wMyBprB2aQrnt72r9Lh6jZy

Why? I understand we don't want the reader to actually use that specific password as printed in this book, but the example should be coherent.

In chapter 3, you write

"Since the transaction sending this bitcoin was only sent in the last few seconds, it has still not confirmed and therefore we will see it list a zero balance:"

This is the example you written about calling "getreceivedbyaddress" without the second parameter, pointing out that it uses the minconf in the configuration. You should point out the default value of this configuration, and that it is not zero, which is why you don't see the balance yet.

In chapter 3, in the tip about transaction malleability, you should say how many confirmations are required until the txid can be considered final. Is it only 1?

In chapter 3, you write the nth block usually with an apostrophe like 286384'th block or 0'th block. I don't think that's grammatically correct. It should be 286384th block or 0th block, the same reason why we say 5th amendment and not 5'th amendment.

In chapter 3, you write

First, we generate a "seed" that will be used as the basis to derive a chain of keys, compatible with the Electrum wallet and other similar implementations.

This is the first time you mentioned Electrum to the user, so I think it deserves some explanation of what Electrum is (or maybe just use the generic term of deterministic wallets?).

In chapter 4, you have this tip listed twice:

The bitcoin private key is just a number. A public key can be generated from any private key. Therefore, a public key can be generated from any number, up to 256-bits long. You can pick your keys randomly using a method as simple as dice, pencil and paper.

In chapter 4, you mention this sentence twice:

Many software implementations of bitcoin use the OpenSSL library, specifically the Elliptic Curve library.

In chapter 4, you have this tip listed twice:

The size of bitcoin's private key, 2^256^ is a truly unfathomable number. It is equal to approximately 10^77^ in decimal. The visible universe contains approximately 10^80^ atoms.

In chapter 4, Figure 1 displays addresses in a Type-0 non-deterministic wallet. However, in there you have four addresses that actually have the same 256-bit random number and bitcoin address. Instead, you should have four different random numbers and addresses.

The same problem applies to the figure for Type-2 chained deterministic keys.

In Chapter 4, Figure 6, you have a graph of Elliptic Curve Cryptography and describe that "Elliptic curve multiplication can be visualized geometrically as drawing a line connecting two points on the curve (G and kG) to produce a third point (K)".

However, the graph that you have uses the points P, Q, R and -R. Instead can you have a graph using the G, kG and K points instead?

Minor Typos

"frequency hoping"

Chapter 4: Wallet images should use different bitcoin addresses

In chapter 4, Figure 1 (https://github.com/aantonop/bitcoinbook/blob/develop/images/type0_chain.png) displays addresses in a Type-0 non-deterministic wallet. However, in there you have four addresses that actually have the same 256-bit random number and bitcoin address. Instead, you should have four different random numbers and addresses.

The same problem applies to the figure for Type-2 chained deterministic keys (https://github.com/aantonop/bitcoinbook/blob/develop/images/type2_chain.png)

Chapter 4 – ”Generating a private key from a random number”

The paragraph (last part) under this headline states that:
"If the result is less than n - 1, we have a suitable private key. If it is greater than n - 1, we simply try again with another random number."

But how about the case when the result equals n - 1 ? To be consistent with the rest of the paragraph, perhaps it should say:

"If the result is less than n - 1, we have a suitable private key. Otherwise, we simply try again with another random number."

Chapter 3: We should point out default value of minconf when calling getreceivedbyaddress without second parameter

In chapter 3, you write

"Since the transaction sending this bitcoin was only sent in the last few seconds, it has still not confirmed and therefore we will see it list a zero balance:"

This is the example you written about calling "getreceivedbyaddress" without the second parameter, pointing out that it uses the minconf in the configuration. You should point out the default value of this configuration, and that it is not zero, which is why you don't see the balance yet.

Chapter 4: Multiple sentences and tips are repeated twice

In chapter 4, you have this tip listed twice:

The bitcoin private key is just a number. A public key can be generated from any private key. Therefore, a public key can be generated from any number, up to 256-bits long. You can pick your keys randomly using a method as simple as dice, pencil and paper

In chapter 4, you mention this sentence twice:

Many software implementations of bitcoin use the OpenSSL library, specifically the Elliptic Curve library.

In chapter 4, you have this tip listed twice:

The size of bitcoin's private key, 2^256^ is a truly unfathomable number. It is equal to approximately 10^77^ in decimal. The visible universe contains approximately 10^80^ atoms.

Chapter 4: Example graph about Elliptic Curve Cryptography should use the same point labels as expressed in the text

In Chapter 4, Figure 6, you have a graph of Elliptic Curve Cryptography and describe that "Elliptic curve multiplication can be visualized geometrically as drawing a line connecting two points on the curve (G and kG) to produce a third point (K)".

However, the graph that you have uses the points P, Q, R and -R. Instead can you have a graph using the G, kG and K points instead?

Chapter 8 - example paragraph order

In the text:
"In the example above, the winning "nonce" is 13 and this result can be confirmed by anyone independently."

This actually is not referring to an example (analogy) immediately above, but the example a few paragraphs before that. Consider changing the paragraph order.

Chapter 9: use of alt-coin before its definition / add premining?

I have two small considerations for Chapter 9:

The third paragraph has a disclaimer that reads "For every alt-coin mentioned in this chapter, 50 or more will go unmentioned,...". That paragraph uses the word alt-coin three times, but the reader might not yet understand what alt-coin means. The term alt-coin isn't defined until a few paragraphs later.

Secondly, maybe also mention pre-mining. At least define what it is or maybe mention it in the "Here are some of the key financial and market metrics to examine:" list.

Chapter 6 (The Bitcoin Network) is missing Introduction text

Chapter 2: Description of number of confirmations seems incorrect

In Chapter 2, Andreas writes

"A few minutes later, a new block, #277317 is mined by another miner. As this new block is based on the previous block (#277316) that contained Alice's transaction, it added even more computation on top of that block, thereby strengthening the trust in those transactions. One block mined on top of the one containing the transaction is called "one confirmation" for that transaction. As the blocks pile on top of each other, it becomes exponentially harder to reverse the transaction, thereby making it more and more trusted by the network."

This could be a misleading, because once a transaction is included in a block, it would be considered to have 1 confirmation. In Andreas' example block #277317 actually makes up the second confirmation.

This was reported by erikwam's comment in pull request
erikwam@80c0b6a, though I have not accepted his commit, and leave this up to Andreas.

Chapter 4: Older and new client support for compressed keys sentence is fragmented

In chapter 4, Andreas writes

"Newer clients that support compressed public keys have to account for transactions and older clients which do not support compressed public keys"

The second sentence is missing a verb and noun. Not sure what you meant to say about what older clients have to do.

Or did you mean to say "from" instead of "and"?

Chapter 2

Bob says "That’s one-dollar-fifty, or fifteen millibits".
correct 1:
Bob says "That’s one-dollar-fifty, or fifteen thousand bits".
correct 2:
Bob says "That’s one-dollar-fifty, or fifteen millibitcoins".

15 mBTC for a cup of coffee seems too much (approx. 10 USD)

Also, transaction fee is 0.0001 BTC now, former it was 0.0005 BTC

"essentially hundreds of mining algorithms printed in hardware, running in parallel on a single silicon chip. "
correct:
"essentially hundreds of mining programs printed in hardware, running in parallel on a single silicon chip. "

Figure 9. Alice’s transaction included in block #277,317
correct:
Figure 9. Alice’s transaction included in block #277,316

Chapter 2: Figure 4: The output transaction of value 0.0805 should actually be value 0.0850

The output for transaction 82 is 0.0805 but should probably be 0.085 (or perhaps 0.0845 if a transaction fee should be included).

Chapter 2 - Risk of a merchant to accept unconfirmed transaction

" While confirmations ensure the transaction has been accepted by the whole network, for small value items like a cup of coffee, such a delay is unecessary. A merchant may accept a valid small-value transaction with no confirmations, with no more risk than a credit card payment made without ID or a signature, as many do today"

It is against current merchant agreements to accept credit cards without a signature, and in some cases for some values, without ID. Some stores do such anyway, knowing that for some values of chargebacks that they will be protected by their bank or creditcard processor. They buy insurance to avoid this as part of their service agreeement.

Sites like Bitundo and others allow bad faith actors to undo these transactions within minutes, and there are already people experimenting with "BadFaith" wallet applications that can do the same "double spend" type transaction.

Should this about box be reworded to indicate the real risk or is it okay as it stands? I feel this does not detail the risk that bad actors are starting to play on the bitcoin network and have already seen a few POC apps out there that do "Undo Transaction" wallets.

Should digital signatures be explained in their own section in ch 4?

Might make a nice section to add before discussing transactions.

Here are some graphics I've made a while ago to explain this concept. Feel free to use them:

https://www.dropbox.com/s/33l2botzmtce5k4/EncryptLoop.svg
https://www.dropbox.com/s/4ew1dbsh1qb2ifg/SignLoop.svg

Ch06 - Transaction Pools

4th paragraph - Second sentence:
"Any orphans found are pulled from the orphan pool and validated using the above checklist."

I don't see any checklist.

Chapter 2: Payment request URL has four fields, but only three are described

In chapter 2, "Buying a cup of coffee", you write

a "payment request" is a QR encoded URL that contains a destination address, a payment amount and a generic description such as "Bob's Cafe"

In your payment URL example it actually has four things. Do you want to mention that recipient label as well?

Chapter 2 description of transaction debits and credits analogy is backwards

In the text:
"Transactions are like lines in a double-entry bookkeeping ledger. In simple terms, each transaction contains one or more "inputs", which are debits against a bitcoin account. On the other side of the transaction, there are one or more "outputs", which are credits added to a bitcoin account. The inputs and outputs (debits and credits) do not necessarily add up to the same amount. Instead, outputs add up to slightly less than inputs and the difference represents an implied "transaction fee", a small payment collected by the miner who includes the transaction in the ledger. "

... debits and credits are backwards. Although debits are on the left in T accounting, reductions to asset accounts are credits, not debits. My suggested rewording, below, was rejected, so this section still needs to be addressed somehow.

Suggested text:
"-Transactions are like a journal entry record in a double-entry bookkeeping ledger. Each transaction contains:

-* a set of one or more "inputs", each with an input address and value
-* a set of one or more "outputs", each with an output address and value

-The inputs are to become the reductions to bitcoin addresses, and the outputs increases to other bitcoin addresses. The net inputs and net outputs must balance, with the exception of an optional implicit "transaction fee", a small output payment collected by the miner. Similar to debits and credits in an accounting journal entry, the net amount (input values less output values less fee) must be zero."

Chapter 8 - Proof-of-Work Algorithm

"The key characteristic of a cryptographic hash algorithm is that it is impossible to find two different inputs that produce the same fingerprint."

I would change "impossible" to something like "virtually impossible", or "extremely unlikely".

Because:
The number of unique fingerprints are limited by their length. For example: If 2^256+1 different inputs are fed to a SHA-256 algorithm, it must produce - at least - two identical fingerprints.

Furthermore, is it really proven that any 2^256 different inputs will produce 2^256 different fingerprints in SHA-256?

Chapter 1: Getting your first bitcoins - No mention of ATMs

Bitcoin ATMs are a way to get bitcoins and are popping up all over the place. They deserve a mention.

Ch 5 – Transaction LifeCycle

”Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. ”

The same problem here as discussed in issue #18. The text gives the impression that subsequent blocks are needed before a transaction is confirmed.

Chapter 6 and 7: Bloom filters seem to be introduced too early

In chapter 6 (The Bitcoin Network) it is difficult to grok how SPV wallets work and the motivation and description for bloom filters without the full understanding of the blockchain and merkle root described in Chapter 7 (The BlockChain). I suggest that lightweight clients still be introduced in Chapter 6, but not fully explained along with bloom filters until after the blockchain is fully described.

Suggestion to add Ruby code for Transactions processing

About a year ago I gave a presentation about bitcoin transactions. It came with a Ruby gist that takes basic information from blockchain.info, constructs a transaction and prints out the hex for the user to copy paste and submit.

Figure 6-6 question

In https://github.com/aantonop/bitcoinbook/blob/develop/images/InventorySynchronization.png when Node B sends the getblocks request to Node A does Node A ever send back some sort of acknowledgement to Node B? Or is a lack of a response to a getblocks request normal?

I'm also a little confused on the timing of those initial messages. It looks like Node A actually sends a getblocks request right before it hears the first getblocks from Node B. Does this illustrate a point in the text that I maybe missed?

Chapter 2: Total number of BTC will be less then 21 million.

It may be a good idea to mention somewhere that the total number of 21 million Bitcoins is just an approximate number. The exact number is 20.9999999769 (million).
(source https://en.bitcoin.it/wiki/Controlled_supply - See table with headline "Projected Bitcoins Long Term").

Chapter 8 checklists should follow parallel construction

In the sections "Independent Verification of Transactions" and "Validating a New Block" the checklists would read better if they were worded similarly. I suggest prefacing the checklist with "Each node verified every transaction against a long checklist of criteria that must all evaluate true; otherwise, the transaction is rejected:".

Then, each criteria would be re-worded. E.g., instead of "Check the syntactic correctness of the transaction's data structure" say "The transaction's syntax and data structure is correct."

Chapter 4 - there's a small mistake

"It turns out that + is commutative, which means that (A+B)+C = A+(B+C). That means we can write A+B+C without parentheses without any ambiguity."

I think it should be "associative" instead of "commutative".

Incorrect address in Figure 3, Chapter 4.

In "Figure 3 Type-2 Chained Deterministic Keys..." :
The same 256-bit hash and bitcoin address is shown for both index 0 and index 1.

Bitcoin vs. bitcoin & Blockchain vs. blockchain

Not sure whether to discuss this as an issue or to do it via pull request (submitted)...but here goes:

Minor points, but, this book will probably set the standards.

Issue 1) Bitcoin vs. bitcoin
I think many people use the capital "B" Bitcoin to refer to the Bitcoin network, protocol, concept, etc while lower case "b" bitcoin refers to the currency units.

For example, I sent 2 bitcoins to Bob over the Bitcoin Network.

There are some problems though: Bitcoin user or bitcoin user? Bitcoin address or bitcoin address? Bitcoin wallet or bitcoin wallet? Bitcoin client or bitcoin client?

Issue 2) Blockchain vs. block chain
The original Bitcoin paper never puts the two words in sequence. Satoshi's forum posts use "block chain". Blockchain as one word is the name of a company. I think we should stick with the "block chain" referring to the proof of work chain in Bitcoin and Blockchain to refer to the company.

Chapter 4: Generating Vanity Addresses

First paragraph, last sentence: "There are approximately 58^31...."

Shouldn't that be approximately 58^29 ?
There are 29 symbols after "1Kids" in "1Kids11111111111111111111111111111".

Ch06 - Figure 2.

Text under Solo Miner: "Contains a mining functions with..."
should be changed to: "Contains a mining function with..."

Ch 4 - Compressed Public Keys

Second paragraph, last sentence:
"A 50% reduction in size in every transaction adds up to a lot of data saved over time!"
I would suggest changing that to something like: "An almost 50% reduction in size..."

Because the public key is 520 bits when uncompressed and 264 when compressed - which is about 50.77% of the uncompressed key.

Chapter 4: Figure 6 Base58Check Encoding has misleading SHA256 input

The diagram in Chapter 4, Figure 6:
https://github.com/aantonop/bitcoinbook/blob/develop/images/Base58CheckEncoding.png
can be misleading, because it shows that the input of the double SHA256 function is just the number.

In reality, the input of the double SHA256 is the (prefix + number).

Not sure how to best fix this in the graphic (maybe just duplicating the version box to the top row as well? Or get rid of the top row altogether and make the green arrow come straight out of the middle row?

Assigning to Andreas for now.