This book is not for the faint-hearted: if you don’t already have a rough idea of what Bitcoin is, you won’t learn it here. Nor is it easy reading if you do have a rough idea: the book is poorly edited and has several inconsistencies; for example, the field known as “nBits” in Table 3.4 morphs into “Difficulty” in Table 3.5, and, although described as 4 bytes in Table 3.4, is represented in Table 3.5 with a value that does not sensibly fit in 4 bytes. The reader should also apply a large dose of common sense to the statements made in the book; for example, 2.3.3 introduces various payment systems, including PayPal, IBM Micropayments, and Peppercoin, but does not indicate that only PayPal is significant, and indeed Peppercoin is described as “another prominent” system. I am unable to make sense of the statement (page 25) “Micropayment schemes adopt the principle that not all payments need to be processed - but only a representative sample of those payments.” On page 69, the authors misquote their own paper [3] (δ should be 120 seconds not 60), and the statistics here are dubious: a geometric distribution should have standard deviation almost equal to the mean, not twice it.

Having given those warnings, the astute reader who wants to learn more about Bitcoin and related objects, and to appreciate some of the subtler weaknesses, would do well to read this: I certainly learned a good deal.

Chapter 4 looks at the “double-spending” problem. A particular feature of Bitcoin, and indeed blockchains in general, is the “longest chain wins” philosophy. Hence, it is possible for a transaction to be included in a block, but for that block not to be in the longest chain, and so “written out of history.” The original, commonsense, view was that, as long as more than 50 percent of the mining power was honest, the longest chain would be honest and double-spending would be prevented. This is incorrect [1], and the authors discuss this and their own more recent work.

The advice (and implementation in standard clients) is to wait for six confirmations, which may well be 100 seconds, before believing that one has “the longest chain.” This has led to advice for “fast payments,” that is, not waiting in cases where the value is small compared to the cost of manipulating the blockchain (the authors cite https://en.bitcoin.it/wiki/Myths for this, but the Internet Archive doesn’t justify this: rather, see https://bits.media/en/bitcoin-myths/#23, which is a very similar site, differing only in adding this item and dropping a bizarre AI claim). The authors discuss their attacks on this approach and partial solutions.

But what if there isn’t a “longest chain” (that is, a fork has occurred), or if the longest chain is “wrong” (as also happened in Ethereum: https://blog.ethereum.org/2016/07/26/onward_from_the_hard_fork/). Here, it turns out, the Bitcoin developers can, and have, stepped in and overridden the usual mechanism. As the authors point out (see also [2]), this power of the developers fundamentally negates the claim of many (including bitcoin.org) that there is no central authority.

Chapter 5 notes that there are also problems over privacy in Bitcoin, stemming from two issues. The first is that “Bitcoin” is a poor analogy: “Bitnote” is a better one because each bitcoin, like a banknote, has essentially a serial number (known, confusingly, as an address), which is visible in every transaction. The second set of vulnerabilities lies in the Bitcoin network. The authors describe these weaknesses well and also show various research “solutions,” all of which have a price, at least in complexity.

The authors then (chapter 6) point out that a full Bitcoin client requires 70 GB of disc space (today’s figure would be 100 GB) and considerable computer power. In fact, substantial, always-on bandwidth is required as well. Hence, from the beginning, a simple payment verification (SPV) client was envisaged that is not a full player in the Bitcoin system, merely verifying its own transactions and blocks, and relying on the four full nodes it is connected to for full functionality. One of these, but in fact only one, must be honest for the SPV client to function correctly. The outsourcing method requires the SPV client to transmit Bloom filters implementing the “its own transactions” aspect just mentioned to the full nodes. This leaks a lot of information: this and countermeasures are discussed here.

Remaining chapters in this book discuss the Bitcoin ecosystem (payment processors, wallets, and so on), other digital currencies, and more general use of blockchains. Again, these chapters are not necessarily easy, and the assertions need checking, but they are a lot better than starting with a blank search engine.