Mastering Bitcoin: Programming the Open Blockchain, by Andreas M. Antonopoulos and David A. Harding, is a technical reference that teaches programmers how Bitcoin's keys, transactions, signatures, fees and payment channels work. This 2023 third edition adds Harding as coauthor and covers schnorr signatures, taproot, wallet descriptors and fee bumping. The authors publish the source text under a Creative Commons Attribution-ShareAlike 4.0 license in the author repository at the pinned commit, and O'Reilly publishes the edition, listed on its publisher page.
The book earns a place in a liberty library because it trains developers to keep the authority to spend separate from the conditions that let a wallet recover, a transaction relay and a payment settle. Self-custody depends on software implementing those mechanisms together. A user can hold a private key and still find that a backup restores less than it promised, or that a channel deadline passed while a fee bump failed to relay.
The wallets chapter opens by correcting a common picture: a wallet holds keys, while the bitcoins exist as outputs recorded on the blockchain. Early applications generated each key independently, so if a newly generated key was missing from the last backup, coins sent to it could become inaccessible. Deriving every key from one seed removed the need to back up each new key separately, although restoring even a single-signature wallet also depends on knowing its derivation paths and script types, and labels sit outside the seed. Multisignature needs more. To find and spend its outputs, a wallet needs the co-signers' public keys and the script conditions, and a seed reproduces only one signer's private keys. Descriptors record scripts and keys, but restoring them still requires compatible software. A backup that leaves out those public keys and scripts can keep funds safe from thieves and also out of their owners' reach.
Elsewhere in the chapter, a web store example installs an extended public key on a merchant's server, which generates a fresh receiving address for each order without holding spending keys. The authors call this a security feature and concede that a hacked server can redirect future payments. A developer should add that anyone who copies the xpub can also read that account's address history. Hardened derivation shows where to draw the line, because an xpub combined with one leaked normal child private key yields the parent private key. Wallets therefore derive the upper levels with hardened derivation and export public keys below that boundary.
The signatures chapter treats a signature as a commitment to selected transaction data. Sighash flags choose which inputs and outputs a signature covers, and inputs in one transaction can carry different flags, which lets several parties assemble a partially signed transaction. A valid signature proves that whoever produced it could use the matching private key to authorize exactly the committed data. It names no person and settles no legal title, since stolen keys produce valid signatures too; ownership has to rest on other evidence. The schnorr material is careful where carelessness costs money. It first builds multisignature by adding public keys together and labels that scheme insecure. It then explains how a participant who sees the other keys first can choose his own so that the combined key is one he controls alone. Finally it turns to protocols designed against that attack.
The fees chapter describes the fee as inputs minus outputs. It works as a bid that miners rank by fee divided by transaction weight. A higher rate improves a transaction's ranking but does not guarantee a confirmation time. The two fee-bumping methods differ in who can use them. Replace-by-fee requires the ability to construct a valid conflicting spend of the same input. In an ordinary payment the sender, who signed the original inputs, signs a replacement, although some sighash arrangements let existing signatures be reused or another party contribute an input. Child-pays-for-parent spends an output of the stuck transaction, so it is available to whoever controls one: the sender through change, or the recipient through the payment output, subject to any timelock or script conditions. Knowing that an output exists confers no authority to spend it. The price is more block space and a dependence on miners evaluating parent and child as a package. Relay limits on unconfirmed ancestors and descendants, along with minimum mempool fees, can also block a fee bump that consensus rules would accept. The authors connect this to pinning attacks on protocols whose presigned transactions must confirm before a deadline.
Deadlines also drive the applications chapter and its account of payment channels. Each update leaves the older commitment transaction fully signed and free of any wall-clock expiry; it remains usable for as long as the funding output stays unspent. Revocation therefore attaches a cost to broadcasting an old state. If a party publishes an outdated state, the other side gets a window, set by a relative timelock, in which a revocation key lets her claim the cheater's balance. The punishment depends on the honest party watching the chain, having fees available and getting block space before the window closes. The chapter's list of Lightning benefits reads more optimistically than its mechanism. Channel capacity is finite and runs in each direction separately, and payments fail when routes lack liquidity. Onion routing reduces what intermediaries learn, but it does not guarantee anonymity against timing analysis or colluding nodes.
For implementers, the book's fit as a reference has a clear limit. Its schnorr section does scalar arithmetic modulo the field prime p, whereas BIP340 specifies that arithmetic modulo the group order n, a distinct number, so code copied from that step would disagree with the standard. The fees chapter's relay rules and defaults likewise describe Bitcoin Core at the time of writing, and policy can change between releases. Exact algorithms belong to the BIPs and BOLT specifications, and current policy to current software documentation.
The preface addresses the book mostly to coders, with its first chapters offered to noncoders as an introduction. Its deepest value goes to programmers who are comfortable with a command line, hexadecimal data and public-key cryptography and who build wallets, custody arrangements, payment processing or Lightning software. For them, the lasting lesson is that holding a key starts self-custody, and the remaining work lies in backups that restore everything spending requires and transactions that can still confirm when a deadline arrives.