Front Matter

*Preface

Every Bitcoin transaction is a tiny program. Not a database record, not an API call, not a row in a ledger—a program, written in a stripped-down scripting language, serialized into raw bytes, broadcast to a network of sixty thousand nodes, and validated by each one independently.

Most people who use Bitcoin never see these bytes. They see addresses, amounts, confirmations. They interact through wallets that abstract away the wire format entirely. This is fine for sending money. It is not fine for understanding money.

This book cracks open the abstraction. We take real transactions—pulled from the Bitcoin blockchain and the live mempool—and parse them byte by byte. Every field, every opcode, every signature component gets its own annotation. Nothing is hidden. Nothing is hand-waved.

The first specimen is the first-ever person-to-person Bitcoin transaction: Satoshi Nakamoto sending 10 BTC to Hal Finney on January 12, 2009. It is 275 bytes long. By the time you finish Chapter 1, you will understand what every one of those bytes means.

From there, we work forward through Bitcoin's evolution: from the raw public-key outputs of 2009, through the address revolution of P2PKH, the script flexibility of P2SH, the witness restructuring of SegWit, and the Schnorr/Taproot upgrade of 2021. Each era gets its own specimens, its own byte-by-byte parsing, and its own script execution traces.

The final chapters cover the protocol-layer transactions that most people never think about: Lightning channel operations, Ordinals inscriptions, and Runes tokens. These are all just Bitcoin transactions—clever arrangements of the same bytes and opcodes we learn in Chapter 1.

Brian Hirschfield

New York, 2026

*How to Use This Guide

*Prerequisites

This book assumes you can read hexadecimal and understand that computers store numbers as bytes. That's it. We build everything else from scratch—serialization formats, script evaluation, cryptographic signatures, witness structures.

You do not need:

• A Bitcoin node (we pull specimens from the public blockchain)
• Programming experience (though it helps for the Rust appendix)
• Cryptographic background (we explain every hash and signature from the bytes up)

If you've read The Quantum Threat (the companion volume on quantum computing and Bitcoin cryptography), you'll find the mathematical background for Chapters 3, 12, and 18 already familiar. But neither book requires the other.

*How This Book Is Organized

The six parts follow Bitcoin's chronological evolution. Each part introduces a new era of transaction types, building on the parsing skills established in earlier parts.

*Reading Paths

The linear path (recommended): Read Parts I through VI in order. Each chapter builds on the previous one, and the progression mirrors Bitcoin's own evolution. This is the path that gives you the deepest understanding.

The practitioner's path: If you already understand Bitcoin Script and just want to parse modern transactions, start at Part I (Chapters 1–3 for the fundamentals), then skip to Part III (SegWit) and continue forward.

The protocol path: If you're building on Bitcoin (Lightning, Ordinals, Runes), read Part I, then jump to Part VI. Refer back to earlier parts as needed when the protocol-layer chapters reference specific transaction types.

*The Specimens

Every chapter is built around a real Bitcoin transaction—a specimen—pulled from the blockchain. These are permanent, verifiable artifacts. You can look up every specimen on any block explorer and verify our parsing byte by byte. We use mempool.space throughout. We never fabricate transactions. Every hex dump in this book corresponds to real bytes stored permanently on the blockchain.

*Exercises

Each chapter ends with layered exercises:

• Litmus (L) — Can you parse the bytes? Quick verification that you followed the chapter.
• Hands-On (H) — Extended parsing tasks. Pull a real transaction and dissect it yourself.
• Proofs (P) — Demonstrate deeper understanding. Why does the encoding work this way? What would break if a field were different?
• Connections (C) — Cross-chapter links. How does this transaction type relate to what came before or after?
• Bridge (B) — Preview the next chapter's concepts. What limitations of the current format motivate the next evolution?

Complete solutions appear at the end of each chapter.

*Notation

Throughout this book, hex bytes are color-coded by field type:

01 00 00 00 | Version field (4 bytes, little-endian)

01 | VarInt (count or length)

c9 97 a5 e5 ... | Previous transaction ID (32 bytes, internal byte order)

00 00 00 00 | Output index / vout (4 bytes, little-endian)

47 30 44 ... | ScriptSig / unlocking script (variable)

ff ff ff ff | Sequence number (4 bytes)

00 ca 9a 3b ... | Output value in satoshis (8 bytes, little-endian)

41 04 ae ... | ScriptPubKey / locking script (variable)

00 00 00 00 | nLockTime (4 bytes, little-endian)

00 01 | SegWit marker (00) and flag (01)

02 47 30 ... | Witness data (per-input stacks)