Grokking Bitcoin

Grokking Bitcoin opens in an office cafe where coworkers pay for cookies with cookie tokens, and a trusted colleague named Lisa records every transfer in a spreadsheet everyone else can only view. From that setup Kalle Rosenbaum builds a long, illustrated explanation of Bitcoin, from hash functions to changes in consensus rules. David A. Harding's foreword argues that Bitcoin arranges incentives so cheating becomes impractical or unprofitable, shrinking the role a centralized authority has to play. Rosenbaum keeps the text in an open repository, and the version at this pinned commit may differ from the printed edition.

As Harding observes, each part starts from a centralized system anyone can picture and transforms it step by step. The cookie economy is a fictional teaching path that becomes Bitcoin by chapter 8, making no claim about how Bitcoin was historically designed. In our reading, every fix relocates trust, and a careful reader learns to ask where it went. That habit is the book's best gift, because it trains a user to separate two jobs that casual talk blurs together. Keys authorize payments, while validating nodes decide whether those payments follow the rules.

Chapter 2 makes the first repair, against impostors. John gives Lisa his public key in advance and later emails a signed request to move 10 CT to the cafe, which Lisa checks against the stored key before appending the row. If someone edited the request to pay Mallory, John's signature would fail verification against the altered text, and a valid signature for the new version would require John's private key. Yet anyone who has copied that key signs just as validly as John, so verification establishes, under the scheme's assumptions, which key authorized a message and says nothing about the person holding it or about legal title. Lisa also still controls the spreadsheet, and abuses such as resubmitting an old signed message remain open at this stage.

In chapter 4, Rita learns that randomly generated keys can outgrow a backup, depending on how many her wallet created ahead of time. Rosenbaum's answer is a deterministic tree grown from one random seed, with each child key addressed by a path such as m/1/0. His teaching example renders a 128-bit random seed as twelve English words. Under BIP39, which real wallets commonly follow, 128 random bits count as entropy that the twelve words encode with a short checksum. The seed feeding the key tree is a separate 512-bit value, stretched from those words plus an optional passphrase. A margin note states that restoring keys also requires knowing their paths, naming BIP44 as one standard for structuring them. Readers can extend the point: a seed recreates its own keys along known paths, and rebuilding a full wallet may also need script types or cosigners' public keys where applicable. Keys imported from elsewhere sit outside that tree.

An online shop's server can derive receiving addresses from an extended public key, and that xpub alone grants no power to spend. The xpub still lets the server link the shop's payments together. A compromised server could also show customers an attacker's addresses, or go dark when payments are due. A leaked ordinary child private key combined with its parent xpub can expose the parent; hardened derivation blocks that route, though a hardened account gives its own ordinary descendants no shelter once the account xpub and one child key both escape. Older password-protected backup files raise a parallel caveat: re-encrypting one's own copy never revokes a stolen copy, which stays open to offline guessing.

Chapter 11 shows the method at full stretch. Rosenbaum defines a fork as a change to consensus rules, which leaves copies of a code repository outside the term. Relay policy and compact blocks likewise fall outside it. A vegetarian restaurant carries the core intuition: a vegan menu still feeds every regular, while adding meat drives them away. In a soft fork, old nodes accept blocks from upgraded miners without enforcing the new restriction themselves, so an old node's acceptance tells its operator less than it seems. The tour of signaling methods, ending at BIP9 version bits, adds a second caution: a signal bit announces support and proves nothing about what a miner's software enforces.

Rosenbaum's account of the 2017 segwit activation, including the BIP148 and BIP91 proposals, reads best as history, illustrating how miner signaling and node enforcement can diverge. His closing description of user-activated deployment as a work in progress dates from 2019. What endures is independent validation: a node keeps its own rules, and no hashrate majority can make a block valid to a node that judges it invalid. Rosenbaum's fictional standoff, where exchanges and even the electricity company refuse miners' blocks, models economic weight and coordination, though no formal vote or guaranteed outcome stands behind it. Readers finish able to reason about adopting or deferring an upgrade and about whose attestations they rely on.

Two explanations need correcting against primary sources. Chapter 2 repeatedly calls a signature a hash encrypted with the private key, verified by decrypting with the public key. Bitcoin's ECDSA, as the secp256k1 library implements it, encrypts nothing: signing uses the private key and a fresh secret nonce to produce two numbers tied to the message hash, and verification checks an elliptic curve equation against the public key. Chapter 4 states that child private keys come from addition modulo 2^256, while BIP32 reduces modulo the group order n and skips rare invalid children. Manning's January 2020 errata correct other passages without listing these.

The errors bear most on implementers, who need exact algorithms and should work from the BIPs and maintained code. A reader building a mental model can keep the central lessons of chapters 2 and 4 with the corrections noted, since a signature still binds one key to one message and child keys still descend from their parent. The introductory pages promise a book free of programming code and mark the math as optional, though a few Linux commands appear later. That suits patient nonprogrammers willing to follow one running example for hundreds of pages. Readers needing current custody advice should treat this 2019 snapshot as background. For readers who want to judge claims about self-custody and rule changes on their own terms, the cookie office is a sound way in, available from Manning and as open text from the author.