Bitcoin Protocol Guide

A deep dive into Bitcoin’s protocol internals — from UTXOs to Taproot to the Ordinals debate. Written from a “confused → understanding” perspective, with real transaction examples you can verify yourself.

No price talk. No trading. Pure protocol.

Table of Contents

Bonus

• Satoshi’s Words — 19 verified, verbatim quotes from the white paper and BitcoinTalk forums
• CLI Commands — Useful bitcoin-cli commands for exploring the blockchain
• Examples — Real decoded transactions from mempool.space
  • The Pizza Transaction — 10,000 BTC for two pizzas (P2PKH)
  • First BRC-20 Deploy — The ordi token (Taproot inscription)
  • Large Image Inscription — Witness data “abuse” in practice

Philosophy

Every claim in this guide can be verified with a Bitcoin node and bitcoin-cli. The goal is to understand why Bitcoin works the way it does, not just what it does. Each chapter builds on the last:

UTXOs → Script → SegWit → Taproot → Ordinals → BIP-110 → Node Setup → History
    → Self-Custody → Mining → Network → Future

Chapters 1-8 build linearly. Chapters 9-12 expand the picture: how to hold your keys, how mining works, how the network operates, and what’s being built next.

Prerequisites

• Basic understanding of public/private key cryptography
• A Bitcoin node (Core or Knots) — see Chapter 07 for setup
• Willingness to read hex and JSON

How to Use This Guide

1. Read sequentially — each chapter builds on the previous
2. Run the CLI commands — verify everything yourself
3. Decode the example transactions — seeing real data makes it click
4. Use mempool.space as a visual companion — paste any txid to see it rendered

Tools

Query your own node with bitcoinlib-rpc — a typed Python wrapper for Bitcoin Core RPC:

pip install bitcoinlib-rpc
bitcoin-mempool    # Fee buckets, congestion analysis
bitcoin-block 939290  # Pool ID, SegWit/Taproot adoption
bitcoin-tx <txid>  # Full decode + inscription detection

See the Tools section for details.

Contributing

Found an error? Open an issue or PR. This is a living document.

License

CC BY-SA 4.0 — Share and adapt with attribution.

Chapter 1: The UTXO Model

In Satoshi’s Words

“We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.”

— White paper, Section 2: Transactions (October 2008)

The Mental Model That Makes Everything Click

Forget bank accounts. Bitcoin doesn’t track balances. Instead, it tracks unspent transaction outputs (UTXOs) — think of them as individual coins sitting in lockboxes.

When you “have 1 BTC,” what you really have is a collection of UTXOs that add up to 1 BTC. Maybe it’s one UTXO worth exactly 1 BTC, or maybe it’s three UTXOs worth 0.5, 0.3, and 0.2 BTC.

UTXOs vs. Account Model

The UTXO Lifecycle

flowchart LR
    CB[Coinbase Tx<br/>Block N] -->|creates| U1[UTXO<br/>0.5 BTC]
    TX1[Some Tx] -->|creates| U2[UTXO<br/>0.1 BTC]
    U1 -->|spent by| TX2[Your Tx]
    U2 -->|spent by| TX2
    TX2 -->|creates| U3[UTXO<br/>0.3 BTC<br/>→ recipient]
    TX2 -->|creates| U4[UTXO<br/>0.2999 BTC<br/>→ change]
    TX2 -.->|0.0001 BTC fee| MINER[Miner]

    style U1 fill:#f96,stroke:#333
    style U2 fill:#f96,stroke:#333
    style U3 fill:#6f9,stroke:#333
    style U4 fill:#6f9,stroke:#333
    style MINER fill:#ff9,stroke:#333

UTXOs are created (green) by transactions and destroyed (orange) when spent. The difference between inputs and outputs is the miner fee. There is no “balance” — only unspent outputs.

Anatomy of a Transaction

Every Bitcoin transaction does exactly one thing: destroy old UTXOs and create new ones.

INPUTS (UTXOs being spent)          OUTPUTS (new UTXOs being created)
┌─────────────────────┐            ┌─────────────────────┐
│ UTXO: 0.5 BTC       │──────────►│ 0.3 BTC → recipient │
│ (from previous tx)   │           ├─────────────────────┤
├─────────────────────┤           │ 0.2999 BTC → me     │ ← change
│ UTXO: 0.1 BTC       │           │ (back to my address) │
│ (from previous tx)   │──────────►└─────────────────────┘
└─────────────────────┘
                                    Fee = 0.6 - 0.5999 = 0.0001 BTC

Key rules:

1. Inputs must reference existing, unspent outputs — you can’t spend what doesn’t exist or what’s already been spent
2. Entire UTXOs are consumed — you can’t partially spend a UTXO. If you have a 0.5 BTC UTXO and want to send 0.3, you spend the whole 0.5 and send 0.2 back to yourself as change
3. Sum of inputs ≥ sum of outputs — the difference is the miner fee (there’s no explicit fee field)
4. Each input must prove authorization — via a digital signature (covered in Chapter 2)

Change Outputs

Satoshi described this pattern directly in the white paper:

“Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.”

— White paper, Section 9: Combining and Splitting Value

Change is the most confusing part for newcomers. Here’s why it exists:

Imagine you have a $20 bill and want to buy a $12 item. You hand over the $20 (the full UTXO), get the item ($12 to the merchant), and receive $8 back (change to yourself). You can’t tear the $20 bill in half.

Bitcoin works identically. Every UTXO is an indivisible unit that must be fully consumed.

Common gotcha: If you forget to create a change output, the entire difference becomes the miner fee. People have accidentally paid hundreds of thousands of dollars in fees this way.

The Transaction Format (Simplified)

{
  "version": 2,
  "inputs": [
    {
      "txid": "abc123...",     // Which previous transaction?
      "vout": 0,               // Which output of that transaction?
      "scriptSig": "...",      // Proof you can spend it
      "sequence": 4294967293
    }
  ],
  "outputs": [
    {
      "value": 30000000,       // Amount in satoshis (0.3 BTC)
      "scriptPubKey": "..."    // Lock: who can spend this?
    },
    {
      "value": 29990000,       // Change (0.2999 BTC)
      "scriptPubKey": "..."    // Lock: back to me
    }
  ],
  "locktime": 0
}

Fields explained:

• version: Transaction format version (1 or 2). Version 2 enables BIP 68 relative timelocks
• inputs[].txid + vout: Points to a specific output of a previous transaction — this is the UTXO being spent
• inputs[].scriptSig: The “key” that unlocks the UTXO (your signature + public key)
• outputs[].value: Amount in satoshis (1 BTC = 100,000,000 satoshis)
• outputs[].scriptPubKey: The “lock” — a script that defines who can spend this new UTXO
• locktime: Earliest time/block this transaction can be included in a block (0 = immediately)

Fees

There is no fee field in a transaction. The fee is implicit:

fee = sum(input values) - sum(output values)

Miners collect the fee by including the transaction in their block. Higher fee = higher priority = faster confirmation. Fees are measured in satoshis per virtual byte (sat/vB), which we’ll explain in Chapter 3.

The UTXO Set

The UTXO set is the current state of Bitcoin — every unspent output that exists right now. As of 2025, it’s roughly:

• ~180 million UTXOs
• ~12 GB of data
• Stored on disk in LevelDB, with a configurable memory cache (default ~450 MB)

This is the only state a node needs to validate new transactions. You don’t need the full blockchain history to know if a transaction is valid — just the current UTXO set.

Coinbase Transactions

“The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.”

— White paper, Section 6: Incentive

Every block starts with a special transaction called the coinbase transaction. It has:

• No inputs (it creates new bitcoin from nothing)
• Outputs totaling the block subsidy + all fees from transactions in the block

As of 2024 (post-4th halving), the block subsidy is 3.125 BTC. The coinbase output can’t be spent until 100 blocks later (coinbase maturity rule).

The very first coinbase transaction (block 0, the genesis block) contains a famous message embedded by Satoshi:

“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”

This served as both a timestamp proof (the block couldn’t have been mined before that date) and a political statement about why Bitcoin was created. The genesis block’s 50 BTC coinbase is permanently unspendable — a unique property of block 0.

Verify It Yourself

# Get a raw transaction
bitcoin-cli getrawtransaction <txid> 2

# Look at the UTXO set stats
bitcoin-cli gettxoutsetinfo

# Check if a specific output is unspent
bitcoin-cli gettxout <txid> <vout>

Key Takeaways

1. Bitcoin has no balances — only UTXOs
2. Transactions consume entire UTXOs and create new ones
3. Change goes back to you (if you remember to add the output)
4. Fees = inputs - outputs (implicit, no fee field)
5. The UTXO set is Bitcoin’s entire current state
6. Wallet software manages your UTXOs for you — see Chapter 9 for how HD wallets derive keys and track your UTXOs
7. Covenants (proposed in Chapter 12) would add the ability to restrict where UTXOs can be spent — a fundamental extension of the UTXO model

Next: Chapter 2 — The Script System — How those scriptPubKey locks actually work.

Chapter 2: The Script System

In Satoshi’s Words

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.”

— Satoshi Nakamoto, BitcoinTalk (June 17, 2010)

Bitcoin’s Hidden Programming Language

Every UTXO is locked by a small program called a script. To spend a UTXO, you must provide another script that makes the combined program evaluate to true. This is Bitcoin’s programmability layer — simple, deliberate, and intentionally limited.

How Script Execution Works

Bitcoin Script is stack-based, like Forth or a reverse Polish notation calculator. There are no loops (by design — scripts must terminate), no floating point, and no access to external state.

Spending a UTXO evaluates two scripts:

scriptSig (provided by spender) → scriptPubKey (set by previous creator)

As Satoshi put it:

“The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.”

Important: Since BIP 16 (P2SH, 2012), scriptSig and scriptPubKey are not concatenated — they run in separate evaluation contexts. The scriptSig executes first, and its resulting stack is copied as input to the scriptPubKey. This separation fixed a class of attacks where a crafted scriptSig could manipulate the scriptPubKey’s execution. If the stack’s top value is non-zero (truthy) after scriptPubKey finishes, the spend is valid.

Example: P2PKH (Pay-to-Public-Key-Hash)

This is the original Bitcoin address type (starts with 1).

scriptPubKey (the lock):

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

scriptSig (the key):

<sig> <pubKey>

Execution trace:

Stack              | Operation
-------------------|------------------------------------------
                   | Start with scriptSig
[sig]              | Push <sig>
[sig, pubKey]      | Push <pubKey>
                   | Now execute scriptPubKey
[sig, pubKey,      | OP_DUP — duplicate top item
 pubKey]           |
[sig, pubKey,      | OP_HASH160 — hash the top item
 hash(pubKey)]     |
[sig, pubKey,      | Push <pubKeyHash>
 hash(pubKey),     |
 pubKeyHash]       |
[sig, pubKey]      | OP_EQUALVERIFY — check equality, fail if not
[true]             | OP_CHECKSIG — verify signature against pubKey

The script checks: “Does the provided public key hash to the address, AND does the signature match that key?” Both must be true.

Script Types: A History of Upgrades

flowchart LR
    P2PKH["**P2PKH**<br/>2009<br/>Hash of pubkey"]
    P2SH["**P2SH**<br/>2012<br/>Hash of script"]
    P2WPKH["**P2WPKH**<br/>2017<br/>SegWit single-sig"]
    P2WSH["**P2WSH**<br/>2017<br/>SegWit scripts"]
    P2TR["**P2TR**<br/>2021<br/>Schnorr + MAST"]

    P2PKH -->|"complex conditions"| P2SH
    P2SH -->|"witness discount"| P2WPKH
    P2SH -->|"witness discount"| P2WSH
    P2WPKH -->|"Schnorr + privacy"| P2TR
    P2WSH -->|"Schnorr + privacy"| P2TR

Each new script type solved specific problems:

P2PKH — Pay to Public Key Hash (2009)

• Address format: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
• The original. Lock to a hash of a public key
• Problem: No way to create complex spending conditions

Satoshi had already planned for these advanced use cases:

“The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.”

— Satoshi Nakamoto, BitcoinTalk (June 17, 2010)

P2SH — Pay to Script Hash (2012, BIP 16)

• Address format: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
• Lock to a hash of a script. The actual script is only revealed when spending
• Enables: multisig, timelocks, any complex condition
• The spender bears the cost of the complex script, not the sender

# P2SH scriptPubKey (simple — just a hash check)
OP_HASH160 <scriptHash> OP_EQUAL

# P2SH scriptSig (reveals the actual script)
<signatures...> <redeemScript>

Example — 2-of-3 Multisig via P2SH:

redeemScript = OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG

The sender just sees a short hash. The complex multisig script is hidden until spending time.

P2WPKH — Pay to Witness Public Key Hash (2017, SegWit)

• Address format: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 (bech32)
• Same logic as P2PKH but signature data moves to the witness field
• Result: smaller transaction weight, lower fees
• Detailed in Chapter 3

P2WSH — Pay to Witness Script Hash (2017, SegWit)

• Like P2SH but with witness data
• Enables complex scripts with the SegWit weight discount

P2TR — Pay to Taproot (2021, BIP 340/341/342)

• Address format: bc1p... (bech32m)
• Two spending paths: key-path (just a signature) or script-path (reveal a script)
• Uses Schnorr signatures instead of ECDSA
• Detailed in Chapter 4

Notable Opcodes

Disabled opcodes

Satoshi disabled several opcodes early on due to security concerns:

• OP_CAT (concatenate) — now proposed for re-enabling as BIP 347 (see Chapter 12 for the full OP_CAT debate and what recursive covenants enable)
• OP_MUL, OP_DIV — arithmetic that could cause issues
• OP_SUBSTR, OP_LEFT, OP_RIGHT — string manipulation

These are consensus rules — any transaction using them is invalid, period.

OP_RETURN: Data Embedding

OP_RETURN creates a provably unspendable output. Nodes can safely prune these from the UTXO set since they can never be spent.

OP_RETURN <arbitrary data>

Before OP_RETURN, people embedded data by creating fake addresses (which bloated the UTXO set permanently). OP_RETURN was a compromise: “If you must put data on-chain, at least don’t pollute the UTXO set.”

Note on the size limit: Bitcoin Core historically enforced an 80-byte OP_RETURN relay policy (raised to 83 bytes), but this was a node policy rule, not a consensus rule. Miners could always include larger OP_RETURN outputs in blocks. Bitcoin Core v30 (October 2025) removed the relay limit entirely. This is relevant to the Ordinals debate — BIP-110 proposes re-imposing data limits at the consensus level.

Sighash Types

When signing a transaction, you choose what parts of the transaction the signature covers:

ANYONECANPAY | ALL means: “I sign my input and all outputs, but anyone can add more inputs.” This enables on-chain crowdfunding — multiple people contribute inputs to fund a shared set of outputs.

Verify It Yourself

# Decode a transaction to see scriptSig and scriptPubKey
bitcoin-cli getrawtransaction <txid> 2

# Decode a raw script (hex)
bitcoin-cli decodescript <hex>

# See the fields:
# "asm" — human-readable opcodes
# "type" — script type (pubkeyhash, scripthash, witness_v0_keyhash, witness_v1_taproot)

Key Takeaways

1. Every UTXO is locked by a script (scriptPubKey)
2. Spending requires a matching script (scriptSig/witness) that makes the combined program return true
3. Script is stack-based with no loops — intentionally limited
4. Script types evolved: P2PKH → P2SH → P2WPKH/P2WSH → P2TR
5. Each upgrade enabled new capabilities while maintaining backward compatibility (soft forks)

Next: Chapter 3 — SegWit — How moving signatures out of the transaction changed everything.

Chapter 3: Segregated Witness (SegWit)

In Satoshi’s Words

Satoshi never saw SegWit (he disappeared in 2011), but he anticipated the scaling challenges that drove its creation:

“The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.”

— Satoshi Nakamoto, BitcoinTalk (July 2010)

And he explicitly proposed raising the block size limit via a scheduled upgrade:

“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit. It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.”

— Satoshi Nakamoto, BitcoinTalk (October 4, 2010)

SegWit took a different approach than Satoshi’s simple size increase — but the problem it solved was the one he identified.

The Upgrade That Made Everything Possible

SegWit (BIP 141, activated August 2017) is the most consequential upgrade in Bitcoin’s history. It fixed transaction malleability, enabled the Lightning Network, introduced script versioning, and — critically — created the weight discount that makes Ordinals economically viable.

The Problem: Transaction Malleability

Before SegWit, anyone could modify the scriptSig of a transaction without invalidating it. The signature itself was valid, but the encoding could be tweaked (e.g., adding extra padding). This changed the transaction’s hash (txid) without changing what the transaction actually did.

Why this matters:

• Lightning Network was impossible — payment channels rely on pre-signed transactions referencing specific txids. If a txid changes in-flight, the pre-signed transaction becomes invalid
• Exchange accounting broke — exchanges tracked withdrawals by txid. Malleable transactions could show as “unconfirmed forever” even though the funds arrived (Mt. Gox cited this as a contributing factor)

The Solution: Move Signatures Out

SegWit literally segregates the witness (signature data) from the transaction. The witness data is included in blocks but excluded from the txid calculation.

BEFORE SegWit:                    AFTER SegWit:
┌──────────────────┐              ┌──────────────────┐
│ version          │              │ version          │
│ inputs           │              │ marker + flag    │  ← new
│   txid + vout    │              │ inputs           │
│   scriptSig ◄────── signature  │   txid + vout    │
│   sequence       │  in here     │   scriptSig      │  ← empty
│ outputs          │              │   sequence       │
│   value          │              │ outputs          │
│   scriptPubKey   │              │   value          │
│ locktime         │              │   scriptPubKey   │
└──────────────────┘              │ witness ◄────────── signatures here
                                  │ locktime         │
                                  └──────────────────┘

txid = hash of everything except witness data wtxid = hash of everything including witness data

Since the signature is no longer part of the txid, malleability is fixed.

Weight Units: The New Size Metric

flowchart TB
    subgraph Legacy["Legacy Transaction (250 bytes)"]
        L1["250 bytes × 4 = **1,000 WU**"]
    end
    subgraph SegWit["SegWit Transaction (same data)"]
        S1["150 non-witness bytes × 4 = 600 WU"]
        S2["100 witness bytes × 1 = 100 WU"]
        S3["Total: **700 WU** (30% savings)"]
    end
    Legacy ~~~ SegWit

SegWit replaced the simple byte-count block size limit with a weight system:

weight = (non-witness bytes × 4) + (witness bytes × 1)

The block weight limit is 4,000,000 weight units (4 MWU), replacing the old 1 MB block size limit.

Why 4:1?

This is the key insight. Non-witness data (inputs, outputs, amounts) counts 4× as much as witness data (signatures). This means:

The practical effect: Witness data is 75% cheaper to put on-chain than non-witness data.

Block capacity comparison:

• Old limit: 1,000,000 bytes (~1 MB)
• New limit: 4,000,000 weight units
• Typical SegWit block: ~1.5-2 MB actual data (since witness bytes are discounted)
• Maximum theoretical: ~4 MB (if a block were 100% witness data)

Why This Matters for Ordinals

The 4:1 witness discount was designed to make signatures cheap. But the witness field can hold arbitrary data — not just signatures. This is how Ordinals/Inscriptions work:

1. Inscription data goes in the witness (1 WU per byte)
2. Without the discount, the same data would cost 4× more in fees
3. A 400 KB image in witness data only “costs” 400,000 WU — leaving room for actual transactions in the same block

This was an unintended consequence. SegWit’s designers wanted cheaper signatures, not cheaper JPEGs. This tension drives the BIP-110 debate.

Virtual Bytes (vBytes)

For fee calculation purposes, Bitcoin uses virtual bytes:

vsize = weight / 4  (rounded up)

Fee rates are expressed in sat/vB (satoshis per virtual byte). This normalizes fee calculations across legacy and SegWit transactions.

Example:

• Legacy transaction: 250 bytes = 1000 WU = 250 vB
• SegWit transaction: 150 non-witness + 100 witness = (150×4) + (100×1) = 700 WU = 175 vB
• Same fee rate → SegWit pays less total fee

Script Versioning

SegWit introduced witness versions (0-16), enabling future upgrades without hard forks:

• Witness v0: P2WPKH, P2WSH (the original SegWit scripts)
• Witness v1: Taproot (P2TR) — activated November 2021
• Witness v2-16: Reserved for future soft forks

This is how Bitcoin can keep upgrading without breaking backward compatibility. Old nodes see SegWit outputs as “anyone-can-spend” (from their perspective), but they trust that miners enforce the new rules.

Address Formats

Bech32 addresses are case-insensitive, have better error detection, and are more efficient in QR codes.

How SegWit Activated: The UASF Drama

SegWit’s activation was politically contentious:

1. BIP 9 signaling: Miners signal readiness by setting bits in block headers
2. Miners stalled at ~30% signaling for months (some wanted bigger blocks instead)
3. BIP 148 UASF (User Activated Soft Fork): Node operators threatened to reject non-SegWit blocks after August 1, 2017
4. BIP 91: Miners capitulated and locked in SegWit days before the UASF deadline
5. SegWit activated at block 481,824 (August 24, 2017)

This established that users (node operators) ultimately control Bitcoin’s consensus rules, not miners. For the full story of the UASF — including the political context, the CIA visit, and the block size wars that preceded it — see Chapter 8.

Verify It Yourself

# Compare a legacy vs SegWit transaction
bitcoin-cli getrawtransaction <legacy-txid> 2
bitcoin-cli getrawtransaction <segwit-txid> 2

# Check the "weight" and "vsize" fields
# SegWit tx will have weight < size * 4

# See block weight stats
bitcoin-cli getblock <blockhash> 2 | grep -E "weight|size"

Key Takeaways

1. SegWit moves signatures to a separate witness field, fixing malleability
2. Witness data gets a 75% discount (1 WU/byte vs 4 WU/byte)
3. Block limit is now 4M weight units (~1.5-2 MB typical, up to ~4 MB theoretical)
4. The witness discount unintentionally made on-chain data embedding cheap — enabling Ordinals
5. Script versioning enabled Taproot and future upgrades without hard forks

Next: Chapter 4 — Taproot — Schnorr signatures, MAST, and the upgrade that made inscriptions technically possible.

Chapter 4: Taproot

The Upgrade Ordinals Couldn’t Exist Without

Taproot (BIPs 340/341/342, activated November 2021) is the most elegant upgrade in Bitcoin’s history. It replaced ECDSA with Schnorr signatures, introduced Merkelized Abstract Syntax Trees (MAST), and made complex scripts indistinguishable from simple payments on-chain.

It also, accidentally, created the exact mechanism Ordinals use to embed data.

What Taproot Gives You

A P2TR (Pay-to-Taproot) output can be spent two ways:

                    P2TR Output
                    ┌─────────┐
                    │ tweaked  │
                    │ public   │
                    │ key      │
                    └────┬────┘
                   ┌─────┴─────┐
              Key Path     Script Path
              (fast)       (flexible)
                │               │
           Single Schnorr   Reveal a script
           signature        from the MAST

Key-Path Spend

Just provide a Schnorr signature. On-chain, this looks identical to any other single-sig spend. Nobody can tell if there were hidden script conditions you could have used.

Script-Path Spend

Reveal one specific script from a Merkle tree of possible scripts. Only the executed branch is published on-chain — unused branches stay hidden.

Schnorr Signatures (BIP 340)

Taproot replaces ECDSA with Schnorr signatures. Why?

Linearity is the killer feature

Schnorr signatures are linear: you can add public keys together and add signatures together. This means a 3-of-3 multisig can produce a single public key and single signature that’s indistinguishable from a solo spend.

# ECDSA multisig (old way, on-chain footprint):
OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG
→ Reveals all 3 pubkeys + 2 signatures on-chain

# Schnorr + MuSig2 (new way):
<aggregated_pubkey>  →  <aggregated_sig>
→ Looks like a single-key spend. Nobody knows it was multisig.

Batch Validation

Nodes can validate multiple Schnorr signatures simultaneously, ~2.5x faster than verifying each independently. This makes initial block download faster.

MAST: Merkelized Abstract Syntax Trees

MAST lets you commit to a tree of possible scripts but only reveal the one you actually use.

            Root Hash (committed in the output)
               ┌──────┴──────┐
            Hash AB         Hash CD
          ┌───┴───┐       ┌───┴───┐
      Script A  Script B  Script C  Script D

To spend via Script C:
  Reveal: Script C + Hash D + Hash AB
  Verifier: hash(C) + hash(D) = Hash CD
            Hash CD + Hash AB = Root Hash ✓

Why this matters:

• Privacy: Unused branches are never revealed
• Efficiency: Only the executed script goes on-chain
• Composability: You can have thousands of possible spending conditions in a single output

Real example — Escrow with timeout:

Script A: 2-of-3 multisig (buyer, seller, arbitrator)
Script B: After 30 days, seller can claim unilaterally
Script C: After 90 days, buyer gets refund

If buyer and seller agree, they use the key-path (just a signature, no scripts revealed). The escrow conditions existed but were never published. Maximum privacy.

Key Tweaking

Here’s where it gets clever. A Taproot output commits to a single public key, but that key is tweaked to commit to the script tree:

tweaked_key = internal_key + hash(internal_key || merkle_root) × G

• internal_key: Your actual public key
• merkle_root: Root of your MAST tree (or nothing, for key-path only)
• G: The generator point (secp256k1 constant)

To spend via key-path: sign with the tweaked private key. Nobody can tell if a script tree exists.

To spend via script-path: reveal the internal key + merkle proof + the specific script.

How Ordinals Use Taproot

sequenceDiagram
    participant W as Wallet
    participant BC as Blockchain
    participant N as Nodes

    W->>BC: 1. Commit Tx — create P2TR output<br/>(script tree hides inscription data)
    Note over BC: Output looks like any<br/>normal Taproot output
    W->>BC: 2. Reveal Tx — spend via script-path<br/>(publishes inscription in witness)
    BC->>N: Nodes validate & store witness data
    Note over N: Inscription permanently<br/>recorded on-chain

Ordinals exploit the script-path mechanism:

1. Commit transaction: Create an output whose Taproot script tree contains the inscription data
2. Reveal transaction: Spend that output via the script-path, publishing the data on-chain

The inscription envelope is a script that looks like:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1           // content type tag
  OP_PUSH "image/png" // MIME type
  OP_PUSH 0           // content tag
  OP_PUSH <data>      // actual file data (can be split across multiple pushes)
OP_ENDIF
<pubkey>
OP_CHECKSIG

The OP_FALSE OP_IF ... OP_ENDIF block never executes — the OP_FALSE ensures the OP_IF branch is skipped. The actual spending happens via OP_CHECKSIG. But the data is still published on-chain in the witness, permanently recorded in the blockchain.

This is why the data goes in the witness (cheap thanks to SegWit discount) and uses Taproot’s script-path (to embed arbitrary data in the script tree). Without both SegWit and Taproot, this mechanism wouldn’t exist.

More details in Chapter 5.

Taproot Activation: Speedy Trial

Unlike SegWit’s contentious activation, Taproot used “Speedy Trial” (a modified BIP 9 approach):

• 90% miner signaling threshold
• Locked in June 12, 2021 (within the first signaling period)
• Activated at block 709,632 (November 14, 2021)
• Near-universal support — no controversy at the time

The irony: Taproot activated smoothly because everyone thought it was a privacy/efficiency upgrade. Nobody anticipated Ordinals (which launched in January 2023).

Verify It Yourself

# Decode a Taproot transaction
bitcoin-cli getrawtransaction <p2tr-txid> 2

# Look for:
# - "type": "witness_v1_taproot" in scriptPubKey
# - witness field containing script-path data (if not key-path)
# - "witness": ["<sig>"] for key-path (just one 64-byte signature)

# Get output info for a Taproot UTXO
bitcoin-cli gettxout <txid> <vout>

Key Takeaways

1. Taproot outputs have two spending paths: key-path (fast, private) and script-path (flexible)
2. Schnorr signatures are smaller, enable key aggregation, and support batch validation
3. MAST hides unused script branches — only the executed path is revealed
4. Key tweaking commits to a script tree without revealing it
5. Ordinals use the script-path to embed data in the witness via an OP_FALSE OP_IF envelope
6. Without both SegWit (cheap witness) and Taproot (script-path data), inscriptions wouldn’t work
7. Taproot addresses (bc1p...) are supported by all major hardware wallets — see Chapter 9 for the address type compatibility matrix
8. Lightning Taproot channels use P2TR for privacy — cooperative closes look like normal spends (see Chapter 12)
9. BIP 360 proposes P2MR as a quantum-resistant alternative that removes the key-path spend entirely (see Chapter 12)

Next: Chapter 5 — Ordinals & Inscriptions — How the theory becomes NFTs and tokens.

Chapter 5: Ordinals & Inscriptions

What Satoshi Said About Data on the Blockchain

“It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen. If there’s going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain.”

— Satoshi Nakamoto, BitcoinTalk (October 23, 2010)

This quote is the primary ammunition in the “spam debate” — Satoshi explicitly opposed non-financial data on-chain. Ordinals launched 13 years later, using mechanisms (SegWit + Taproot) that didn’t exist when he wrote this.

NFTs and Tokens on Bitcoin — Using Only Existing Rules

Ordinals didn’t require any protocol change. Casey Rodarmor built the entire system using Bitcoin’s existing consensus rules — SegWit’s witness discount, Taproot’s script-path spending, and the UTXO model itself. That’s what makes the debate so interesting.

Ordinal Theory: Numbering Satoshis

Every satoshi that has ever existed or will exist gets a unique ordinal number based on the order it was mined:

• The first satoshi ever mined (block 0, first output) = ordinal 0
• The 5 billionth satoshi (end of block 0) = ordinal 4,999,999,999
• Satoshis from block 1 start at ordinal 5,000,000,000

Block 0:  sats 0 — 4,999,999,999
Block 1:  sats 5,000,000,000 — 9,999,999,999
Block 2:  ...
(after 1st halving, blocks produce 25 BTC = 2.5B sats each)

Tracking transfers

When a transaction spends UTXOs, ordinals transfer using first-in-first-out (FIFO) ordering:

Input 0: sats [0, 1, 2, 3, 4]      Output 0: sats [0, 1, 2]  (value: 3 sats)
Input 1: sats [5, 6, 7]            Output 1: sats [3, 4, 5]  (value: 3 sats)
                                    Output 2: sats [6, 7]      (value: 2 sats)

Sats flow from inputs to outputs in order. This is a convention, not a protocol rule — Bitcoin nodes don’t track ordinals. Only ordinal-aware software (like ord) interprets transactions this way.

Rarity

Because ordinals follow mining events, some are “rarer” than others:

This is entirely a social convention — the protocol doesn’t care.

Inscriptions: Data on Bitcoin

An inscription attaches content to a specific satoshi. The content is embedded in a Taproot script-path witness using the envelope format from Chapter 4.

The Commit-Reveal Pattern

Inscriptions use a two-transaction pattern:

Step 1 — Commit Transaction: Create a Taproot output whose script tree contains the inscription data. The output itself looks like any other P2TR output — you can’t tell it contains an inscription by looking at it.

Step 2 — Reveal Transaction: Spend the commit output using the script-path, which publishes the inscription data on-chain in the witness field.

Commit TX:                           Reveal TX:
┌──────────┐                        ┌──────────────────────────┐
│ Input:   │                        │ Input: commit output     │
│ funding  │──►┌──────────┐         │ Witness:                 │
│ UTXO     │   │ P2TR     │──────►  │   signature              │
└──────────┘   │ output   │         │   inscription script:    │
               │ (looks   │         │     OP_FALSE OP_IF       │
               │ normal)  │         │       "ord"              │
               └──────────┘         │       content-type       │
                                    │       <image data>       │
                                    │     OP_ENDIF             │
                                    │     <pubkey> OP_CHECKSIG │
                                    │   control block          │
                                    └──────────────────────────┘

Why two transactions?

The commit transaction hides the inscription data until reveal. This prevents front-running — nobody can see what you’re inscribing and race to inscribe it first on a different sat.

Inscription Envelope Detail

witness:
  <signature>
  <script>:
    OP_FALSE           // pushes 0 to stack
    OP_IF              // 0 is falsy, so this block is SKIPPED
      OP_PUSH3 "ord"   // ordinals protocol marker
      OP_1             // tag: content type
      OP_PUSH "image/png"
      OP_0             // tag: body
      OP_PUSH <chunk1> // data (max 520 bytes per push)
      OP_PUSH <chunk2> // continued...
      OP_PUSH <chunk3>
    OP_ENDIF
    <pubkey>
    OP_CHECKSIG        // actual spending condition
  <control block>      // Taproot internal key + merkle proof

The OP_FALSE OP_IF trick means the inscription data is present in the witness (recorded on-chain) but never executed by the script interpreter. The only thing that actually runs is <pubkey> OP_CHECKSIG.

Size limits

• Each OP_PUSH can push up to 520 bytes
• Multiple pushes can be chained for larger content
• Taproot removed the old 10,000-byte script size limit
• Only constrained by the 4M weight unit block limit
• Maximum single inscription: ~3.9 MB (nearly filling an entire block’s witness space)

BRC-20 Tokens

BRC-20 is a token standard built on top of inscriptions. It embeds JSON in a text inscription:

Deploy a new token:

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "ordi",
  "max": "21000000",
  "lim": "1000"
}

Mint tokens:

{
  "p": "brc-20",
  "op": "mint",
  "tick": "ordi",
  "amt": "1000"
}

Transfer tokens:

{
  "p": "brc-20",
  "op": "transfer",
  "tick": "ordi",
  "amt": "500"
}

Important: Bitcoin nodes don’t understand BRC-20. The token balances are tracked by off-chain indexers that read inscription data and maintain a state. If two indexers disagree on the rules, they’ll show different balances. This is fundamentally different from Ethereum’s ERC-20 where the smart contract IS the ledger.

The Economics: Why Inscriptions Use Witness Data

Thanks to SegWit’s witness discount (Chapter 3):

At 10 sat/vB, inscribing 100 KB in witness costs roughly:

• 100,000 WU / 4 = 25,000 vB × 10 sat/vB = 250,000 sats (~$250 at $100K/BTC)

The same data in non-witness would cost 4× more. This is why inscriptions exclusively use the witness field.

Runes: A Better Token Standard

Runes (launched April 2024 at the halving) was Casey Rodarmor’s answer to BRC-20’s inefficiency. Key differences:

Runes use the UTXO model natively — token balances are attached to UTXOs and transfer following standard Bitcoin transaction rules. This is more Bitcoin-native than BRC-20’s off-chain indexer approach.

Verify It Yourself

# Decode an inscription reveal transaction
bitcoin-cli getrawtransaction <reveal-txid> 2

# Look at the witness field — you'll see the OP_FALSE OP_IF envelope
# The hex between OP_IF and OP_ENDIF is the inscription data

# Check the ord indexer for inscription details
# (requires running the ord binary)
ord index
ord inscription <inscription-id>

You can also use mempool.space or ordinals.com to view inscriptions without running your own indexer.

Key Takeaways

1. Ordinal theory assigns unique numbers to every satoshi — a social convention, not a protocol rule
2. Inscriptions embed data in Taproot witness using OP_FALSE OP_IF — data is recorded but never executed
3. Commit-reveal prevents front-running of inscriptions
4. SegWit’s witness discount makes inscriptions 4× cheaper than other on-chain data
5. BRC-20 tokens are JSON inscriptions tracked by off-chain indexers — not enforceable by consensus
6. Runes is a UTXO-native alternative that doesn’t bloat the UTXO set
7. Inscription fees are now a significant component of miner revenue (see Chapter 10 for why this matters post-halving)
8. RGB protocol offers an alternative: client-side validated tokens that don’t use block space at all (see Chapter 12)

Next: Chapter 6 — The BIP-110 Debate — Should Bitcoin restrict this? Both sides of the “spam war.”

Chapter 6: The BIP-110 Debate

Bitcoin’s “Spam War” — Both Sides

BIP-110 (also called BIP-444 / Reduced Data Temporary Softfork) is the most contentious proposal in Bitcoin since the block size wars. It proposes to limit arbitrary data in transactions, directly targeting Ordinals/Inscriptions. Understanding both sides requires everything from the previous chapters.

What Satoshi Said

Both sides of this debate claim Satoshi’s vision. Here are his actual words:

Pro-restriction camp cites:

“Messages should not be recorded in the block chain.” — BitcoinTalk (October 23, 2010)

Anti-restriction camp cites:

“The incentive can transition entirely to transaction fees and be completely inflation free.” — White paper, Section 6

And on Bitcoin’s resilience:

“The network is robust in its unstructured simplicity… Any needed rules and incentives can be enforced with this consensus mechanism.” — White paper, Section 12: Conclusion

The tension is real: Satoshi opposed non-financial data, but also designed a permissionless fee market as Bitcoin’s long-term security model.

What BIP-110 Does

Author: Dathon Ohm, backed by Luke Dashjr (Bitcoin Knots maintainer) Proposed: December 2025 Status: Draft, enforced by Bitcoin Knots nodes

Specific restrictions:

Key detail: Temporary

BIP-110 is designed as a 1-year soft fork. After expiration, the restrictions lift unless renewed. This is unusual — most soft forks are permanent.

Activation mechanism

Requires 55% hashrate signaling over a defined period. As of early 2026, support is around 3% of nodes (mostly Knots) and one mining pool (Ocean).

The “Anti-Spam” Case (Pro BIP-110)

1. Block space is for financial transactions

“Bitcoin was designed for peer-to-peer electronic cash. Using block space for JPEGs and meme tokens is a misuse of a scarce resource.”

The argument: Bitcoin’s value proposition is censorship-resistant money. Every byte used for inscriptions is a byte not available for payments. When blocks are full, inscriptions compete with financial transactions, driving up fees for everyone.

2. The witness discount was not meant for data storage

SegWit’s 4:1 discount was designed to make signatures cheap, not to subsidize on-chain data storage. Inscriptions exploit an unintended consequence.

Design intent:     Actual use:
Cheaper sigs  →    Cheap data storage
More TXs/block →   Fewer TXs/block (data fills witness)

3. UTXO set bloat

While inscriptions themselves don’t bloat the UTXO set (they’re in witness data), the ecosystem around them creates dust UTXOs. BRC-20 in particular creates many small UTXOs that every node must track.

4. Precedent for “anything goes”

If arbitrary data is acceptable, what’s next? Full movies? Malware? CSAM? The argument is that some content policy is necessary, and limiting data size is a neutral way to do it.

5. Luke Dashjr’s position

Luke (Bitcoin Knots lead) has consistently argued that non-financial data in transactions is spam. He views BIP-110 as restoring Bitcoin’s original purpose and fixing a policy mistake (the removal of OP_RETURN limits in Bitcoin Core v30).

The “Free Market” Case (Anti BIP-110)

1. Paid-for block space is not spam

“If someone pays the market fee rate, they have as much right to block space as anyone else. Bitcoin is permissionless.”

The argument: Bitcoin’s fee market is the mechanism for allocating block space. Inscriptions pay fees — often very high fees. Calling paid transactions “spam” is a value judgment that contradicts Bitcoin’s permissionless nature.

2. Filters don’t work — they make things worse

Historical precedent from Bitcoin Core’s OP_RETURN limits:

Every restriction pushes data embedding into worse methods. If you ban witness data, inscriptions will move to multisig scripts, fake outputs, or other creative workarounds — all of which are MORE harmful to the network.

3. Miner revenue matters

Inscriptions generate significant fee revenue for miners. Post-halving, the block subsidy keeps decreasing. Bitcoin’s long-term security depends on fee revenue replacing the subsidy. Banning a major fee source is counterproductive.

Block subsidy schedule:
2024: 3.125 BTC/block → ~$312K/block at $100K
2028: 1.5625 BTC/block → needs fees to maintain security
2032: 0.78125 BTC/block → fees become dominant

4. Soft fork risk

Any contentious soft fork risks a chain split. If BIP-110 activates with 55% hashrate but significant economic nodes reject it, you get:

• Chain A: BIP-110 blocks (restrictive)
• Chain B: Non-BIP-110 blocks (permissive)
• Confusion, potential value loss on both chains

Adam Back (Blockstream CEO, HashCash inventor) has explicitly warned that BIP-110 risks damaging Bitcoin’s credibility.

5. The slippery slope

Who decides what’s “legitimate” use of block space? Today it’s inscriptions. Tomorrow it might be privacy transactions (CoinJoin), time-locked contracts, or specific smart contract patterns. Establishing the precedent that Bitcoin transactions can be censored by content opens a dangerous door.

6. Jameson Lopp’s analysis

Lopp (Casa CTO, long-time Bitcoin developer) called BIP-110 “misguided,” arguing:

• Technical restrictions are trivially circumvented
• The proposal conflates policy preferences with protocol rules
• Bitcoin’s value comes from being neutral infrastructure

The Nuanced Middle

Some thoughtful positions that don’t fit neatly into either camp:

“Fix the discount, not the data”

Instead of restricting data, adjust the witness discount. If witness data cost 2 WU/byte instead of 1, inscriptions would cost 2× more. This preserves permissionlessness while reducing the subsidy for non-signature witness data.

“Separate the concerns”

• Consensus level: Allow anything that pays fees
• Relay policy: Individual nodes can choose what to relay (already possible — miners can filter their own mempools)
• Application level: Build better fee estimation and block space markets

“Wait for the market”

Inscription activity naturally ebbs and flows with market cycles. During quiet periods, blocks have plenty of room. The “crisis” may be self-correcting.

Current State (Early 2026)

• Bitcoin Core v30 (Oct 2025) removed the 83-byte OP_RETURN limit
• Bitcoin Knots enforces BIP-110 restrictions
• Ocean pool (backed by Jack Dorsey) mines some BIP-110-compliant blocks
• ~3% of network nodes enforce BIP-110
• The 55% hashrate threshold has not been met
• The debate continues

The Deeper Question

The BIP-110 debate is really about Bitcoin’s identity:

Is Bitcoin neutral infrastructure (like TCP/IP — it doesn’t care what data you send) or is it purpose-built money (like the Federal Reserve wire system — only for financial transactions)?

Your answer to this question determines your position on BIP-110, and probably every future debate about Bitcoin’s scope.

Key Takeaways

1. BIP-110 proposes temporary (1-year) restrictions on data sizes in transactions and witness
2. Pro: Block space should be for payments, witness discount wasn’t meant for data, UTXO bloat concerns
3. Anti: Paid fees = legitimate use, restrictions don’t work (data finds other paths), miner revenue, chain split risk
4. The real question: Is Bitcoin neutral infrastructure or purpose-built money?
5. Currently ~3% of nodes, far from the 55% hashrate threshold needed
6. Miner economics make this debate existential — see Chapter 10 for why fee revenue must replace the block subsidy
7. RGB and Taproot Assets offer non-bloating alternatives for tokens — see Chapter 12 for how these could resolve the debate by making on-chain data unnecessary for asset issuance

Next: Chapter 7 — Node Setup — Run your own node and verify everything yourself.

Chapter 7: Node Setup

Running Bitcoin Knots on Windows

Running your own node is how you go from “I read about it” to “I verified it myself.” This guide covers setting up Bitcoin Knots with an existing blockchain on an external drive.

Prerequisites

• Bitcoin Knots installed (includes bitcoin-qt.exe GUI and bitcoin-cli.exe)
• Blockchain data on an external/secondary drive (or willingness to download ~700+ GB)
• ~300 GB free space on the data drive (for catch-up sync + transaction index)
• Windows 10/11

Step 1: Create bitcoin.conf

Bitcoin looks for its config file at:

%APPDATA%\Bitcoin\bitcoin.conf

Create this file with your settings:

# Point to your blockchain data directory
datadir=E:/

# Enable RPC server (needed for bitcoin-cli)
server=1

# Build transaction index (enables getrawtransaction lookups)
txindex=1

What each setting does:

Optional settings:

# Limit memory usage (default is 450 MB for dbcache)
dbcache=1024

# Limit upload bandwidth (default unlimited)
maxuploadtarget=5000

# Prune old blocks (incompatible with txindex=1)
# prune=550000

# Listen for incoming connections
listen=1

# Set RPC credentials (auto-generated if not set)
# rpcuser=yourusername
# rpcpassword=yourpassword

Note: txindex=1 and prune are mutually exclusive. We want txindex for exploring transactions, so no pruning.

Step 2: Start Bitcoin Knots

Launch bitcoin-qt.exe (the GUI). It will:

1. Read bitcoin.conf from %APPDATA%\Bitcoin\
2. Find existing blockchain data on E:/
3. Start syncing from where the data left off

If your blockchain data is from September 2025, it needs to catch up ~6 months of blocks. This takes hours to days depending on your hardware and internet speed.

First-time with txindex

If you’re enabling txindex=1 for the first time on existing data, Bitcoin Knots will need to build the transaction index from scratch. This scans the entire blockchain and can take several hours. You’ll see progress in the GUI’s debug console or logs.

Step 3: Verify with bitcoin-cli

While Bitcoin Knots is running, open a terminal:

# Check node status
"C:/Program Files/Bitcoin/daemon/bitcoin-cli.exe" -getinfo

# Expected output (example):
# Chain: main
# Blocks: 890123
# Headers: 890456
# Verification progress: 0.9999
# Difficulty: 123456789.12

Common commands for exploration:

CLI="C:/Program Files/Bitcoin/daemon/bitcoin-cli.exe"

# Get blockchain info
"$CLI" getblockchaininfo

# Get a specific block by height
"$CLI" getblockhash 0
"$CLI" getblock <hash> 2

# Decode a transaction (requires txindex=1)
"$CLI" getrawtransaction <txid> 2

# Get network info
"$CLI" getnetworkinfo

# Get mempool stats
"$CLI" getmempoolinfo

# Get peer info
"$CLI" getpeerinfo

Step 4: Create a CLI Shortcut

Typing the full path every time is tedious. Create a helper:

Option A: Shell alias (Git Bash / WSL)

Add to your ~/.bashrc or ~/.bash_profile:

alias btc='"C:/Program Files/Bitcoin/daemon/bitcoin-cli.exe"'

Then: btc -getinfo

Option B: Batch file

Create btc.bat somewhere in your PATH:

@echo off
"C:\Program Files\Bitcoin\daemon\bitcoin-cli.exe" %*

Then: btc -getinfo

Troubleshooting

“Cannot connect to Bitcoin server”

• Make sure bitcoin-qt.exe (or bitcoind.exe) is running
• Check that server=1 is in bitcoin.conf
• Check the debug log: E:/debug.log

“Transaction not found” for getrawtransaction

• txindex=1 must be set AND the index must be fully built
• Check progress: bitcoin-cli getindexinfo
• If you added txindex after initial sync, you need to wait for reindexing

Slow initial sync

• Increase dbcache (e.g., dbcache=4096 if you have RAM to spare)
• Make sure your data drive isn’t USB 2.0 (USB 3.0+ or internal SSD recommended)
• Close other disk-heavy applications during sync

Data directory structure

After syncing, your data directory (E:/ in our case) contains:

E:/
├── blocks/           # Raw block data (~650+ GB)
│   ├── blk00000.dat
│   ├── blk00001.dat
│   └── ...
├── chainstate/       # Current UTXO set (LevelDB, ~12 GB)
├── indexes/
│   └── txindex/      # Transaction index (if txindex=1, ~35 GB)
├── peers.dat         # Known peer addresses
├── banlist.json      # Banned peers
├── debug.log         # Log file
└── wallet.dat        # Wallet file (if created)

Bitcoin Knots vs. Bitcoin Core

Bitcoin Knots is a fork of Bitcoin Core maintained by Luke Dashjr. Key differences:

Both follow the same consensus rules — they agree on which blocks are valid. The difference is in relay policy: what transactions they’ll propagate to other nodes before they’re mined.

Verify Everything From This Guide

Now that you have a node running with txindex=1, you can verify every claim in this guide:

# Chapter 1: UTXO model — check UTXO set stats
btc gettxoutsetinfo

# Chapter 2: Script — decode any transaction's scripts
btc getrawtransaction <txid> 2 | jq '.vin[0].scriptSig, .vout[0].scriptPubKey'

# Chapter 3: SegWit — compare weight vs size
btc getrawtransaction <segwit-txid> 2 | jq '{size, weight, vsize}'

# Chapter 4: Taproot — look at witness data
btc getrawtransaction <taproot-txid> 2 | jq '.vin[0].txinwitness'

# Chapter 5: Ordinals — decode an inscription transaction
btc getrawtransaction <inscription-txid> 2 | jq '.vin[0].txinwitness'
# Look for the OP_FALSE OP_IF envelope in the witness hex

Key Takeaways

1. bitcoin.conf needs server=1 for CLI access and txindex=1 for arbitrary transaction lookups
2. Point datadir to your existing blockchain data to avoid re-downloading
3. Building txindex from scratch takes hours but enables full exploration
4. Create a shell alias or batch file for convenient CLI access
5. Bitcoin Knots and Core share consensus rules but differ in relay policy
6. For deeper understanding of what your node does on the network — peer discovery, block propagation, compact blocks, and eclipse attack resistance — see Chapter 11
7. Bitcoin Core 28+ supports AssumeUTXO for faster initial sync — see Chapter 11 for how it works

Next: Chapter 8 — Satoshi’s Timeline and Bitcoin Core History — Who created Bitcoin, who maintains it now, and who actually controls the protocol.

Chapter 8: Satoshi’s Timeline and Bitcoin Core History

In Satoshi’s Words

“I’ve moved on to other things. It’s in good hands with Gavin and everyone.”

— Satoshi Nakamoto, private email to Mike Hearn, April 23, 2011

That seven-word sentence — “good hands with Gavin and everyone” — is one of the most consequential handoffs in the history of open-source software. A person who had just invented a new form of money, mined the first block, sent the first transaction, and quietly shepherded a global network into existence, disappeared. No press conference. No farewell post. Just a clean pass to the next runner.

This chapter is about that handoff, everyone who came after it, and what “who controls Bitcoin” actually means.

Part I: The Satoshi Timeline (2007–2011)

Before Bitcoin Was Bitcoin

Satoshi later told BitcoinTalk that he had been working on the design since 2007:

“Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn’t resist to keep thinking about it. Much more of the work was designing than coding.”

The design-to-code ratio matters. Bitcoin wasn’t thrown together — it was architected. The system had unusual conceptual coherence because the economics, the game theory, and the cryptography had been worked out before a line of code was written.

By mid-2008, he had a working implementation and a draft whitepaper. Before going public, he quietly reached out to two people whose prior work he wanted to cite and who he respected:

• Adam Back (HashCash, the proof-of-work function Bitcoin uses) — contacted sometime before August 2008
• Wei Dai (b-money, a 1998 proposal for anonymous distributed electronic cash) — emailed August 22, 2008

Satoshi’s email to Wei Dai is one of the few pre-launch primary sources we have:

“I was very interested to read your b-money page. I’m getting ready to release a paper that expands on your ideas into a complete working system.”

He needed the citation date for b-money. That’s it. Professional, direct, no fanfare.

The Complete Satoshi Timeline

The Genesis Block: A Political Statement Embedded in Code

Block 0 is unique in multiple ways. Its coinbase transaction contains this ASCII string in the scriptSig:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This is simultaneously:

1. A timestamp proof — the block cannot have been mined before January 3, 2009, because that newspaper headline didn’t exist yet
2. A political statement — the UK government was bailing out banks that had created the 2008 financial crisis. Bitcoin’s genesis was an explicit response to that
3. An aesthetic act — Satoshi chose to write something permanent into the first block of his system

The genesis block’s 50 BTC coinbase reward is also permanently unspendable — a quirk of the protocol design that means Satoshi’s “founder’s reward” from block 0 can never be moved.

You can verify the message yourself:

bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 2
# Look for the coinbase transaction's scriptSig (hex) and decode it

The First Transaction (Block 170)

On January 12, 2009 — nine days after the genesis block — Satoshi sent 10 BTC to Hal Finney, a cryptographer and the only other person running the Bitcoin software at the time. Finney had responded enthusiastically to the whitepaper announcement.

Block 170 contains what is generally considered the first Bitcoin transaction between two people. Finney ran a node, participated in the early network, and later wrote:

“When Satoshi announced Bitcoin on the cryptography mailing list, he got a skeptical reception at best. Cryptographers have seen too many grand schemes by clueless noobs. They tend to have a knee-jerk reaction.”

Finney was an exception. He saw what Satoshi was building and engaged seriously from day one.

You can decode this transaction yourself:

bitcoin-cli getrawtransaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 2

Why Did Satoshi Leave?

He never explained. The WikiLeaks post from December 11, 2010 provides a hint — he was alarmed at the political attention Bitcoin was attracting before it was robust enough to survive it. WikiLeaks had just begun accepting Bitcoin donations after being cut off by Visa, Mastercard, and PayPal. Government attention was incoming.

But there are other factors the community has noted:

• The CIA visit announcement — In late April 2011, Gavin Andresen announced he would give a presentation about Bitcoin at CIA headquarters. Satoshi’s final email to Gavin — days later — conspicuously requested that Gavin stop describing him as a “mysterious shadowy figure.” Whether the CIA presentation contributed to Satoshi’s departure is speculation, but the timing is noted.
• Bitcoin’s political exposure — The system was explicitly designed to resist state-level interference. A de facto leader who could be subpoenaed, threatened, or revealed undermined the whole premise.
• Decentralization completed — Satoshi had distributed keys, handed off maintenance, and built a system that didn’t need him anymore.

His final email to Gavin ends with the request to give more credit to dev contributors. Not “please continue my vision.” Not a farewell. A PR note about attribution. That’s consistent with someone who had simply moved on and wanted the project to stand on its own.

Satoshi’s Coins: The Sleeping Giant

Analysis by Sergio Lerner (Patoshi pattern) and others suggests Satoshi mined approximately 1.1 million BTC in Bitcoin’s early days (blocks 1 through ~21,000). These coins have never moved. As of early 2026, they represent approximately 5% of the total Bitcoin supply.

The community’s relationship with these coins is one of Bitcoin’s most fascinating ongoing dynamics:

• They serve as a kind of decentralization proof — Satoshi could have sold long ago and didn’t
• Any movement of these coins would be a market and philosophical event simultaneously
• Multiple people have claimed to be Satoshi; none have proven it by moving coins from known early addresses

Part II: Bitcoin Core Maintainers — The History

Understanding “Maintainer”

Before going through the history, it’s important to understand what a Bitcoin Core maintainer actually is — and isn’t.

A maintainer has merge access to the Bitcoin Core GitHub repository. They can:

• Merge pull requests that have been reviewed and approved by other contributors
• Sign official release binaries (so users can verify they’re authentic)
• Coordinate the release process

A maintainer cannot:

• Force changes into the protocol without community consensus
• Override economic nodes (exchanges, businesses, wallets)
• Make Bitcoin do anything users don’t accept

Jameson Lopp described it well: “Acting as a Bitcoin Core maintainer is often referred to as janitorial work because maintainers don’t actually have the power to make decisions that run contrary to the consensus of contributors or of the users.”

The misconception that “whoever controls Core controls Bitcoin” is wrong in a specific, important way. Bitcoin Core is software that nodes choose to run. If Core’s developers made changes that economic nodes didn’t accept, those nodes would fork or switch implementations. The maintainers serve the network; they don’t govern it.

The Maintainer Succession

Satoshi Nakamoto
     │  (2009–2010)
     │
     ▼
Gavin Andresen
     │  (2010–2014)
     │  Lead maintainer; also hands out keys to others
     │
     ▼
Wladimir van der Laan (laanwj)
     │  (2014–2022/2023)
     │  Longest-serving lead maintainer
     │  Steps down gradually; Craig Wright lawsuits accelerate decentralization
     │
     ▼
No single "lead maintainer"
     │  (2022–present)
     │  Collective of 5–6 trusted key holders
     ▼
Current: Marco Falke*, Hennadii Stepanov, Ava Chow (achow101),
         Ryan Ofsky, TheCharlatan
         *Falke stepped down 2023; others joined

Satoshi → Gavin Andresen (2010–2014)

Gavin Andresen is a software developer from Amherst, Massachusetts — an alum of Princeton, with early-career experience at Silicon Graphics. He discovered Bitcoin in 2010 and almost immediately made himself useful.

His first notable contribution was the Bitcoin Faucet: a website that gave away free Bitcoin to anyone who solved a CAPTCHA. Gavin personally funded it with 10,000 BTC ($50 at the time). This was marketing and adoption infrastructure that no one had thought to build. It worked — it rapidly distributed Bitcoin to new users and showed Satoshi that Gavin understood the growth problem.

Satoshi gave Gavin escalating levels of trust through 2010. When Satoshi disappeared in late 2010 / early 2011, Gavin found himself as the de facto project lead by default. Crucially, Satoshi never explicitly asked Gavin if he wanted the job.

As Mike Hearn recalled: “Satoshi never actually asked Gavin if he wanted the job, and in fact he didn’t. So the first thing Gavin did was grant four other developers access to the code as well.”

Gavin’s practical response was exactly right: he immediately distributed commit access to prevent a single-point-of-failure. The original five-person core team was assembled quickly — “essentially, whoever was around and making themselves useful at the time.”

Gavin also founded the Bitcoin Foundation in 2012, a nonprofit aimed at funding development and promoting Bitcoin. The Foundation became controversial through no direct fault of Gavin’s — board members Charlie Shrem and Mark Karpeles (Mt. Gox) were later implicated in legal scandals.

The CIA Visit (2011): In late April 2011, Gavin announced on BitcoinTalk that he had accepted an invitation to speak about Bitcoin to the US intelligence community at CIA headquarters. He argued, reasonably, that engaging with government was better than being ignored by it. Many Bitcoin developers disagreed strongly. Whether or not this was the right call, it created tension that never fully resolved. Satoshi’s final email to Gavin — written just days later — was notably pointed about how Gavin was representing Bitcoin in public.

The Block Size Wars: As Bitcoin grew, Gavin became increasingly convinced that the 1MB block size limit needed to be raised — urgently. He backed BIP 101, which would have increased the limit to 8MB immediately and continued doubling. When this was rejected by the Core contributors, he collaborated with Mike Hearn to launch Bitcoin XT in 2015, a fork of Core that implemented BIP 101. Bitcoin XT never gained enough economic support to succeed and was eventually abandoned.

The Craig Wright Debacle (2016): In May 2016, Craig Wright — an Australian academic with a history of Bitcoin-adjacent claims — publicly claimed to be Satoshi Nakamoto. He provided demonstrations to a small group, including Gavin, in private sessions. Gavin published a blog post stating:

“I believe Craig Steven Wright is the person who invented Bitcoin. After spending time with him I am convinced beyond a reasonable doubt.”

The Bitcoin Core team immediately revoked Gavin’s commit access to the repository, citing concerns he had been “hacked” — but the real concern was that he had endorsed a claim that the rest of the community found technically inconsistent. Wright’s “proof” was quickly dissected and found wanting. Gavin later expressed doubt about his own conclusion. In 2024, a UK High Court ruled definitively: Craig Wright is not Satoshi Nakamoto. He had fabricated evidence, committed perjury, and lied to multiple courts across multiple jurisdictions over years.

Gavin’s last commit to Bitcoin Core was in February 2016. He effectively retired from active development after the Wright controversy. His contributions during the critical 2010–2014 period, when Bitcoin could easily have died from abandonment or incompetence, were genuine and important.

Gavin → Wladimir van der Laan (2014–2022/2023)

On April 7, 2014, Gavin stepped down from the lead maintainer role and nominated Wladimir J. van der Laan (GitHub: laanwj) as his successor. Van der Laan, a Dutch developer based in Eindhoven with a background in computer science and embedded systems, had been contributing to Core since 2011 and had become the most consistently active technical contributor.

The transition was quiet. By 2014, as Gavin was spending more time on Bitcoin Foundation work and less on actual code review, van der Laan had already been doing most of the actual maintainer tasks. Gavin’s colleagues had noticed: as Wladimir told CoinDesk, “not only was [Gavin] not writing code, he wasn’t discussing on the developer IRC, nor on GitHub, nor reviewing code.”

Van der Laan’s tenure (2014–2022/2023) is the longest sustained period of stewardship Bitcoin Core has had under any single developer. His technical contributions were substantial: he oversaw SegWit activation, Taproot, numerous security fixes, and the ongoing hardening of the codebase. His salary was funded by MIT’s Digital Currency Initiative and, later, other Bitcoin development funding organizations.

What made van der Laan’s position unusual was the personal cost. Being lead maintainer meant being the public face of Bitcoin’s development — a target for:

• Intense political pressure during the block size wars
• Personal attacks from both sides of every major protocol debate
• Legal harassment from Craig Wright, who named van der Laan as a defendant in copyright suits claiming ownership of the Bitcoin whitepaper
• A 2020 Twitter controversy over variable naming conventions that nearly led to his resignation

The Craig Wright lawsuits in particular shaped his thinking about decentralization. Van der Laan began advocating for spreading commit access more widely — specifically so that no single person could be sued into compliance. This initiative succeeded and became the current multi-maintainer model.

Van der Laan announced he would begin delegating his tasks on January 21, 2021. He gradually stepped back over the next two years. In February 2023, he removed his own merge privileges — formally ending his tenure as lead maintainer. His stated hope was that Bitcoin Core would become more decentralized, with maintainer responsibility spread across more people and institutions.

The Current Model: No Lead Maintainer (2022–Present)

Bitcoin Core no longer has a single “lead maintainer.” Instead, a small group of developers hold Trusted Keys — cryptographic signing keys that authorize merges and sign release binaries.

Current maintainers as of early 2026:

Recent departures:

• Marco Falke (marcofalke) — Trusted Key 2016–2023; most prolific contributor in Core’s history (2,000+ commits); stepped down in 2023, citing personal reasons. Still contributes actively but without merge access.
• Gloria Zhao (glozow) — Trusted Key 2022–2026; mempool and transaction relay specialist; stepped down early 2026 following sustained personal attacks during the OP_RETURN debate. See Chapter 6.

Note: Pieter Wuille (sipa) held commit/merge access from 2011 to 2022 and is one of the most impactful contributors in Bitcoin’s history, though he stepped back from maintainer duties in 2022 alongside the broader transition.

Part III: Key Contributors (Not All Maintainers)

These people shaped Bitcoin’s protocol in ways that go beyond their formal role titles.

Pieter Wuille (sipa)

Belgian software engineer; PhD in computer science from the University of Leuven; former Google SRE in Switzerland. Joined Bitcoin Core in May 2011 and held commit access until 2022. Currently at Chaincode Labs.

By commit count, Wuille is the closest to Satoshi in codebase impact. His contributions include:

• libsecp256k1 — A highly optimized elliptic curve library for Bitcoin’s ECDSA signatures. Before this, Bitcoin used OpenSSL for signature verification, which was slow and had a larger attack surface. Sipa’s library made signature verification massively faster and more auditable.
• BIP 32 (Hierarchical Deterministic Wallets) — The reason you can back up all your Bitcoin addresses with a single 12- or 24-word seed phrase. Wuille invented the HD wallet derivation scheme.
• BIP 66 (Strict DER encoding) — Closed a consensus-critical security bug in signature encoding
• Segregated Witness (SegWit) — Co-primary author and implementer of the most significant protocol upgrade in Bitcoin’s history (see Chapter 3)
• Schnorr/Taproot — Co-authored the MuSig multi-signature scheme; major contributor to Taproot (see Chapter 4)
• Bech32 addresses — The bc1... address format
• MiniScript — A language for writing and analyzing Bitcoin spending conditions
• ultraprune — Minimized the disk space required to sync a full node

The Human Rights Foundation’s Finney Prize described Wuille’s secp256k1 as “based on experimental code originally published by Hal Finney, which made signing and verifying signatures massively faster and more secure.” That detail — that Wuille built on Finney’s work — creates a quiet lineage from Bitcoin’s first user to one of its most important technical improvements.

Gregory Maxwell (gmaxwell)

One of the most intellectually formidable and personally controversial figures in Bitcoin’s history. Maxwell was a Core developer from 2011 to 2018, co-founder and former CTO of Blockstream.

Before Bitcoin, he was a Mozilla developer who co-authored the Opus audio codec (RFC 6716) and contributed to the Daala video codec. He brought that deep systems-engineering background to Bitcoin.

His contributions include:

• CoinJoin — The fundamental technique for combining multiple users’ transactions into one for privacy
• Confidential Transactions — Cryptographic technique to hide transaction amounts while proving they balance
• BIP 32 co-work — Contributed to homomorphic key derivation
• Taproot original proposal — Maxwell originally proposed Taproot (the MAST-based approach to hiding script complexity); Wuille and others developed it further
• Compact blocks — Improved block propagation speed significantly
• FIBRE (Fast Internet Bitcoin Relay Engine) — Reduced orphan rates dramatically
• Block size debate intellectual leadership — Maxwell was perhaps the most effective articulator of why large block sizes posed existential risks to decentralization

His controversies were real. He gave up his maintainer role in 2017, likely in part due to sustained personal pressure during the block size wars. His online style could be abrasive. He had disputes with other developers that became public. But on technical substance, even his critics frequently acknowledged the quality of his work.

Marco Falke (marcofalke)

The single most prolific committer in Bitcoin Core history: over 2,000 individual commits, primarily in testing infrastructure. During three of his seven years as a trusted key holder, his work was funded by OKCoin and Paradigm.

Falke’s focus was test coverage — regression tests, functional tests, fuzz tests. Consensus-critical software that controls real money needs a level of testing rigor that most software never approaches. Falke spent years ensuring that Bitcoin Core’s test suite was comprehensive enough that bugs could be caught before they reached production.

He stepped down in 2023: “I remain passionate about open source and Bitcoin and I am positive about the future, however being a maintainer is no longer a good fit for me personally.”

Ava Chow / Andrew Chow (achow101)

Wallet maintainer and Trusted Key holder since 2021. Chow’s primary focus is Bitcoin Core’s wallet and key management system. Key contributions include:

• Descriptor wallets — A new wallet format that makes it explicit what scripts are being watched and controlled, replacing the older, less transparent approach
• Output Script Descriptors (BIP 380–386) — The formal specification for describing Bitcoin output scripts
• PSBT (Partially Signed Bitcoin Transactions, BIP 174) — The standard format for multi-party transaction signing, now used by hardware wallets, multisig coordinators, and CoinJoin implementations everywhere

Gloria Zhao (glozow)

Trusted Key holder 2022–2026; the first publicly known female maintainer of Bitcoin Core. Zhao’s domain was the mempool — the waiting room where transactions sit before being included in blocks — and transaction relay.

Her major contributions:

• Package relay (BIP 331) — Allows related transactions (packages) to be relayed together, which is critical for Lightning Network fee bumping
• TRUC / BIP 431 (Topologically Restricted Until Confirmation) — A new type of transaction designed to prevent mempool pinning attacks
• RBF improvements — More predictable replace-by-fee behavior

Zhao stepped down in early 2026, following years of personal attacks that intensified during the OP_RETURN debate in 2025. She had deleted her X (Twitter) account in 2025 after a livestream in which another developer questioned her credentials. Her departure was mourned by many and celebrated by others — a reflection of how polarized Bitcoin development discourse had become. See Chapter 6 for the context.

Part IV: Who Controls Bitcoin?

This is the question everyone asks and almost everyone answers incorrectly.

The Wrong Answer

“Bitcoin Core developers control Bitcoin.”

Why it’s wrong: Core developers can only merge code. They cannot force anyone to run that code. Every node operator chooses which software to run. Every miner chooses what to mine. Every exchange chooses what to accept.

The Right Mental Model

Bitcoin is a protocol that many parties implement. The parties who ultimately define what “Bitcoin” means are:

1. Economic nodes — full nodes run by exchanges, businesses, large holders. They define the rules they’ll accept and reject.
2. Miners — choose which transactions to include and which chain tip to extend
3. Users — choose which software to run and which chain to transact on

Bitcoin Core developers can propose changes. But a change only “happens” if economic nodes adopt it. This is the key insight.

The BIP Process

The Bitcoin Improvement Proposal (BIP) process is how changes are formally proposed and tracked. It was created by Amir Taaki in 2011 (BIP 1), modeled on Python’s PEP (Python Enhancement Proposal) process.

How a BIP works:

Idea                          → Discussed informally (mailing list, IRC, GitHub)
                                        ↓
Draft BIP                     → Formal document: motivation, specification, backwards compatibility
                                        ↓
Community review              → Open feedback; author revises
                                        ↓
Reference implementation      → Code exists and can be tested
                                        ↓
Consensus reached             → Rough consensus (not a vote, but lack of serious objection)
                                        ↓
Activation                    → Soft fork: nodes enforce new rules; miners signal readiness

There are three BIP types:

• Standards Track — Protocol changes (consensus rules, P2P, wallet formats)
• Process — Changes to the BIP process itself
• Informational — Non-binding documentation or guidelines

Important: No BIP has ever been implemented via a hard fork. Every consensus change in Bitcoin’s history has been a soft fork — backward compatible with older nodes (though older nodes see less of the picture).

How Soft Forks Actually Activate

Before SegWit, most soft forks used BIP 9 (miner-activated, also called MASF — miner-activated soft fork). Miners signal readiness by setting version bits in their block headers. Once 95% of miners signal over a defined window, the soft fork activates.

The problem with BIP 9: it gave miners de facto veto power. They could block protocol upgrades that had broad community support simply by not signaling.

SegWit demonstrated this problem: miners — primarily large Chinese mining pools with commercial interests in competing settlement layers — delayed SegWit signaling for over a year despite overwhelming developer and user support.

The UASF Precedent (2017)

The User-Activated Soft Fork (UASF) is the most important governance event in Bitcoin’s history. It established, once and for all, who actually controls Bitcoin.

Background: By 2017, SegWit had clear technical and community support but miners were refusing to signal. Developer Shaolin Fry proposed BIP 148: a flag-day activation where, on August 1, 2017, all nodes running BIP 148 would simply start rejecting any block that didn’t signal SegWit readiness. No miner permission required.

What this meant: if enough economic nodes ran BIP 148, miners would face a choice:

• Mine SegWit-signaling blocks and stay on the economically dominant chain
• Mine non-SegWit blocks and mine into a worthless chain

The UASF movement grew. Exchange support grew. Wearing a “UASF” hat at Bitcoin conferences became a political statement. Miners read the situation correctly.

Before August 1, 2017 arrived, miners capitulated and signaled SegWit. BIP 148 never actually had to execute. But the threat was credible enough that SegWit activated in August 2017 via a more conventional path (BIP 91 → BIP 141).

The lesson: users and economic nodes, not miners, have final authority over protocol rules. The UASF precedent now exists as proof. Any future attempt by miners to block changes that economic nodes strongly want will face the same counter: a credible threat that nodes will simply stop accepting the miners’ blocks.

Bitcoin Knots’ enforcement of BIP 110 restrictions (Chapter 6) operates on the same principle, just from the other direction: a minority of nodes enforcing stricter rules, hoping to gather enough economic weight that miners follow.

The “No One Controls Bitcoin” Statement

This claim is sometimes dismissed as naive idealism. Here’s why it’s technically accurate:

No single party controls all of these simultaneously. Bitcoin has no CEO, no board of directors, no kill switch, and no mailing address to serve a court order to.

For a deeper look at one of these vectors — how mining pool operators control block template construction and why Stratum V2 is the fix — see Chapter 10.

The closest thing to “control” that exists is the collective of economic nodes. If they converge on a rule, that rule is Bitcoin. If they diverge, you get a chain split (like Bitcoin Cash in 2017). Even that split shows the system working as designed: those who disagreed could leave.

The Unanswered Question

Who is Satoshi Nakamoto?

After 17 years, we don’t know. The serious candidates proposed over the years (Hal Finney, Nick Szabo, Wei Dai, Adam Back) have all denied it or lack sufficient evidence. Craig Wright spent years claiming it, fabricated evidence across multiple court cases, and was definitively ruled not to be Satoshi by a UK High Court in 2024.

The most honest answer: it may not matter anymore. Satoshi designed Bitcoin to work without him. It does. Whether Satoshi was one person or a small group, whether they are alive or dead, whether they will ever return — Bitcoin’s protocol has been running continuously since January 3, 2009. The coinbase transactions have kept coming. The blocks have kept getting mined. The keys have passed from hand to hand.

The system works. That was the goal.

Key Takeaways

1. Satoshi worked on Bitcoin’s design for two years before publishing the whitepaper (Oct 31, 2008)
2. The genesis block (Jan 3, 2009) embedded a political statement; the first transaction (Jan 12, 2009) went to Hal Finney
3. Satoshi’s last public post was Dec 12, 2010; his last known private communication was April 26, 2011 — no farewell, just a pass to Gavin and the team
4. The maintainer lineage: Satoshi → Gavin Andresen (2010–2014) → Wladimir van der Laan (2014–2022) → collective model (2022–present)
5. “Maintainer” means merge access and release signing — not protocol authority
6. The 2017 UASF proved that economic nodes, not miners, have final say over protocol rules
7. Bitcoin Core’s trusted key group as of 2026: Hennadii Stepanov, Ava Chow, Ryan Ofsky, TheCharlatan (plus others with active merge access)
8. Nobody controls Bitcoin. The UTXO set runs as long as nodes run. The nodes run as long as the incentives hold.

Previous: Chapter 7 — Node Setup — Run your own node and verify everything yourself.

Next: Chapter 9 — Wallets & Self-Custody — How to actually hold your own keys without losing everything.

Related: Satoshi’s Words — Verbatim quotes from the white paper and BitcoinTalk, with context.

Chapter 9: Wallets & Self-Custody

In Satoshi’s Words

“The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve.”

— Satoshi Nakamoto, P2P Foundation, February 11, 2009

That quote isn’t about wallets. It’s about why wallets exist. Satoshi’s entire design assumed that individuals would hold their own keys. There is no “Bitcoin bank” in the whitepaper. There is no custodian. There is no account recovery department. The system is built — from the cryptographic primitives up — on the premise that the person who controls the private key controls the money.

This chapter is about how to actually do that without losing everything.

Part I: What Is a “Wallet”?

A Bitcoin wallet is a misleading term. It doesn’t hold Bitcoin. Nothing “holds” Bitcoin — UTXOs exist on a distributed ledger maintained by thousands of nodes. What a wallet actually holds is private keys (or the seed material to derive them). The wallet software’s job is to:

1. Generate and store private keys
2. Derive addresses from those keys
3. Monitor the blockchain for UTXOs spendable by those keys
4. Construct and sign transactions when you want to spend

If you lose the keys, the Bitcoin still exists on the blockchain. It’s just permanently unspendable. Chainalysis estimates that 3.7 million BTC — roughly 17.6% of the total supply — is lost forever, most of it from the early years when people didn’t understand what they were holding.

Wallet vs. Account

In traditional finance, you have an “account” at an institution. The institution holds the money. You have a credential (password, card number) to instruct the institution. If you lose the credential, the institution issues a new one. The money never moves.

In Bitcoin, there is no institution. The key IS the money. If you lose the key, there is no recovery. If someone copies the key, they can spend everything. There is no customer service number. There is no chargeback.

This is the fundamental tradeoff of self-custody: you remove the counterparty risk of trusting an institution, but you assume the operational risk of securing your own keys. Both risks are real. The question is which one you’re better equipped to manage.

Part II: Wallet Types

Hot Wallets

A hot wallet is any wallet where the private keys exist on an internet-connected device. This includes:

• Mobile wallets — BlueWallet, Muun, Phoenix, Green (Blockstream), Nunchuk
• Desktop wallets — Sparrow, Electrum, Bitcoin Core (with wallet enabled), Wasabi
• Browser extensions — Alby (Lightning-focused), Xverse (Ordinals-focused)

Hot wallets are convenient for daily spending. They are NOT appropriate for storing significant amounts of Bitcoin. A hot wallet on your phone is the equivalent of the cash in your physical wallet — useful for buying coffee, not for holding your savings.

The threat model is simple: if malware can access the device’s memory, it can access the keys. Android and iOS sandboxing provide some protection, but sophisticated attacks (zero-day exploits, compromised apps, clipboard hijacking) can breach it.

Cold Wallets (Hardware Wallets)

A cold wallet keeps private keys on a device that never touches the internet. The keys are generated on the device, stored on the device, and used for signing on the device. The signed transaction is then transferred to an online device for broadcasting.

Hardware wallets are the standard recommendation for any amount of Bitcoin you’d be upset to lose. We’ll cover specific hardware wallets in detail in Part V.

Air-Gapped Wallets

An air-gapped wallet takes cold storage further: the signing device has no USB, Bluetooth, WiFi, or NFC connection to any other device. Communication happens exclusively through:

• QR codes — The signing device displays a QR code; the online device scans it (and vice versa)
• MicroSD cards — Transaction data is transferred via removable storage (ColdCard’s approach)

Air-gapping eliminates an entire class of firmware-level attacks. Even if the hardware wallet’s firmware were malicious, it would need a communication channel to exfiltrate keys — and an air-gapped device has none.

ColdCard, SeedSigner, and Jade (in QR mode) support full air-gapped operation.

Paper Wallets

A paper wallet is a printed private key (typically as a QR code and/or WIF-encoded string). They were popular in 2013–2016 and are now considered obsolete for several reasons:

1. No partial spending — To spend any amount, you must import the entire private key into a hot wallet, exposing it. If you don’t sweep the entire balance immediately, the change goes to a new address that your paper wallet doesn’t control.
2. Generation risk — Most paper wallet generators ran in web browsers. If the page was compromised, every printed wallet was compromised.
3. Physical fragility — Paper degrades. Ink fades. Water destroys it. Fire destroys it.
4. Single address — Paper wallets are a single key/address pair. No HD derivation, no privacy rotation.

If you find an old paper wallet, sweep the entire balance to a modern HD wallet immediately. Don’t try to spend “part” of it.

Brain Wallets (And Why They’re Terrible)

A brain wallet is a private key derived from a passphrase you memorize. The passphrase is hashed (typically SHA-256) to produce a 256-bit private key.

Brain wallets are catastrophically insecure. Here’s why:

Humans are bad at entropy. A 256-bit private key requires 256 bits of entropy to be secure. The average English sentence has approximately 1–2 bits of entropy per character. A “strong” 20-word passphrase that you can actually remember has maybe 40–60 bits of entropy. That’s 2^200 times weaker than a properly random key.

Automated brainwallet crackers exist. Services and scripts continuously hash dictionaries, common phrases, song lyrics, Bible verses, literary quotes, and password lists, then check the resulting addresses for balances. If your brain wallet passphrase appears in any corpus of human language ever recorded, it will be found — usually within hours of receiving funds.

Real examples of brain wallets that were drained:

• "correct horse battery staple" (the XKCD example) — drained instantly
• "how much wood could a woodchuck chuck if a woodchuck could chuck wood" — drained
• "to be or not to be that is the question" — drained
• Random-seeming phrases that people believed were unique — also drained

Do not use brain wallets. Use BIP 39 mnemonic seeds generated by a hardware wallet’s true random number generator.

Part III: Key Generation — From Entropy to Addresses

The BIP 39 Standard: Mnemonic Seeds

BIP 39 (Mnemonic code for generating deterministic keys) defines the standard that most Bitcoin wallets use today. The process has four steps:

Entropy (128 or 256 bits of randomness)
    │
    ▼
Mnemonic words (12 or 24 words from a fixed 2048-word list)
    │
    ▼
Seed (512-bit value derived via PBKDF2)
    │
    ▼
Master key pair (root of the HD derivation tree)

Step 1: Generate entropy. The wallet’s random number generator produces 128 bits (for 12 words) or 256 bits (for 24 words) of entropy. This MUST come from a cryptographically secure random number generator (CSPRNG). Hardware wallets use dedicated hardware RNGs; software wallets use the OS-provided CSPRNG.

Step 2: Compute the checksum. The entropy is SHA-256 hashed. The first ENT/32 bits of the hash are appended to the entropy. For 128-bit entropy: 4 checksum bits → 132 bits total. For 256-bit entropy: 8 checksum bits → 264 bits total.

Step 3: Map to words. The resulting bit string is split into 11-bit groups. Each 11-bit value (0–2047) indexes into the BIP 39 word list. 132 bits / 11 = 12 words. 264 bits / 11 = 24 words.

Step 4: Derive the seed. The mnemonic words (as a UTF-8 string) are fed through PBKDF2-HMAC-SHA512 with 2048 iterations. The salt is "mnemonic" + passphrase (if a passphrase is used; otherwise just "mnemonic"). This produces a 512-bit seed.

Why 24 words instead of 12? Twelve words provide 128 bits of entropy — sufficient security against brute force for the foreseeable future. Twenty-four words provide 256 bits, which adds margin against hypothetical future attacks (including speculative quantum computing scenarios). Most hardware wallets default to 24 words. Both are considered safe today.

The BIP 39 word list is carefully designed:

• No word is a prefix of another (e.g., “build” and “building” cannot both appear)
• The first four letters uniquely identify each word — so you only need to stamp four letters on steel
• Words were chosen for unambiguous spelling across English speakers

BIP 32: Hierarchical Deterministic Derivation

Once you have a 512-bit seed, BIP 32 (Hierarchical Deterministic Wallets, authored by Pieter Wuille) defines how to derive an entire tree of key pairs from it.

The seed is HMAC-SHA512 hashed with the key "Bitcoin seed" to produce:

• Left 256 bits → master private key
• Right 256 bits → master chain code

From this master key pair, child keys are derived using a tree structure:

Master (m)
├── m/0     (first child)
│   ├── m/0/0     (first grandchild)
│   └── m/0/1
├── m/1
│   ├── m/1/0
│   └── m/1/1
└── m/2
    └── ...

Each derivation level uses an index (32-bit integer). Indices below 2^31 are normal derivation; indices at or above 2^31 are hardened derivation (written with ' or h). Hardened derivation prevents a leaked child public key + chain code from compromising parent keys.

Why this matters: a single 12- or 24-word seed phrase backs up an unlimited number of addresses. Before BIP 32, wallets generated independent random keys for each address, and you had to back up each key individually. Losing a backup meant losing funds. HD wallets eliminated that problem entirely.

BIP 44/49/84/86: Derivation Path Standards

BIP 32 defines the tree structure; these BIPs define which paths to use for which address types:

m / purpose' / coin_type' / account' / change / address_index

The path components:

• purpose’ — Hardened. Identifies the address standard.
• coin_type’ — Hardened. 0' for Bitcoin mainnet, 1' for testnet. (Defined in SLIP 44.)
• account’ — Hardened. Allows multiple logical accounts under one seed. 0' is the first account.
• change — 0 for receiving addresses, 1 for change addresses. NOT hardened.
• address_index — Sequential index within the chain. NOT hardened.

You can verify this in Bitcoin Core with descriptor wallets:

# Create a descriptor wallet
bitcoin-cli createwallet "test_descriptors" false true "" false true

# List wallet descriptors — shows the derivation paths in use
bitcoin-cli -rpcwallet=test_descriptors listdescriptors

# Example output includes descriptors like:
# wpkh([fingerprint/84h/0h/0h]xpub.../0/*)#checksum  ← BIP 84 receive
# wpkh([fingerprint/84h/0h/0h]xpub.../1/*)#checksum  ← BIP 84 change
# tr([fingerprint/86h/0h/0h]xpub.../0/*)#checksum     ← BIP 86 receive (Taproot)

The xpub, ypub, zpub Confusion

Different extended public key formats signal which address type should be derived:

These are encoding conventions, not protocol-level distinctions. The underlying key data is the same — the prefix just tells wallet software which derivation scheme to use. Sparrow Wallet, for example, will show you all four formats for the same seed.

Warning: Sharing an xpub/ypub/zpub with anyone allows them to derive ALL your past and future receiving addresses. They can’t spend your Bitcoin, but they can see your entire transaction history and balance. Treat extended public keys as sensitive information.

Part IV: Address Types and Wallet Support

Bitcoin has four address formats in active use. Each corresponds to a different output script type (see Chapter 2 for the script-level details).

Which Address Type Should You Use?

Native SegWit (bc1q) is the default recommendation for most users in 2026. It’s supported by essentially all wallets and exchanges, has the lowest fees of the non-Taproot types, and is well-understood.

Taproot (bc1p) is the forward-looking choice. Better privacy properties (key-path spends look identical regardless of the underlying script complexity), lowest fees for key-path spending, and required for advanced features like MuSig2 key aggregation. Adoption is growing but some older services still don’t support sending to bc1p addresses.

P2SH-SegWit (3…) exists for backward compatibility. In 2017–2019, many services couldn’t send to bc1 addresses. The 3… format wrapped SegWit inside P2SH so it was universally accepted. There’s no reason to use it for new wallets today.

Legacy P2PKH (1…) should be avoided for new wallets. Higher fees, no SegWit benefits, no Taproot benefits. The only reason to interact with 1… addresses is if you’re recovering old wallets.

# Derive addresses of different types from a descriptor wallet in Bitcoin Core
bitcoin-cli -rpcwallet=test_descriptors deriveaddresses "wpkh([fingerprint/84h/0h/0h]xpub.../0/*)#checksum" "[0,4]"
# Returns 5 native SegWit (bc1q) addresses

bitcoin-cli -rpcwallet=test_descriptors deriveaddresses "tr([fingerprint/86h/0h/0h]xpub.../0/*)#checksum" "[0,4]"
# Returns 5 Taproot (bc1p) addresses

Wallet Compatibility Matrix

Not all wallets support all address types. As of 2026:

Part V: Hardware Wallets — Security Model Comparison

Hardware wallets are the primary tool for self-custody of significant Bitcoin holdings. They all solve the same core problem (keep keys offline) but their security models, trust assumptions, and philosophies differ substantially.

The Comparison

*Trezor Safe 5 added a secure element (Optiga Trust M); earlier models had none.

Security Model Deep Dive

Ledger uses a secure element (a tamper-resistant chip designed for smartcards and payment systems) running a proprietary real-time OS called BOLOS. The firmware is NOT open source. You are trusting Ledger’s internal audit and their secure element vendor (STMicroelectronics) that the chip does what it claims. Ledger’s argument: open-sourcing the firmware would let attackers study it; the secure element’s tamper resistance is the security boundary.

The counterargument: closed firmware means you can’t verify that Ledger isn’t extracting your keys. In May 2023, Ledger announced “Ledger Recover,” a service that would shard your seed and send encrypted fragments to three custodians (Ledger, Coincover, EscrowTech). The Bitcoin community reacted with outrage — not because the service was mandatory (it wasn’t), but because it proved the firmware COULD extract the seed if told to. This confirmed what open-source advocates had always argued: you’re trusting Ledger not to push a malicious firmware update.

Trezor takes the opposite approach: fully open-source firmware and hardware schematics. No secure element (until recently). The tradeoff: without a secure element, a physical attacker with access to the device can extract keys through voltage glitching or flash memory reads. Trezor relies on your PIN and optional passphrase to protect against physical theft. Against remote attacks, the open-source firmware is auditable — which is a stronger guarantee than Ledger’s trust model.

ColdCard combines both: a secure element (for key storage) AND open-source firmware (for auditability). It’s Bitcoin-only — it intentionally doesn’t support any altcoin, which dramatically reduces the attack surface. ColdCard pioneered air-gapped signing via MicroSD card: you export a PSBT to SD, sneaker-net it to the ColdCard, sign, sneaker-net it back. The Mk4 adds NFC for faster air-gapped communication. The ColdCard Q adds a QWERTY keyboard and QR scanner.

Jade (Blockstream) makes a radical design choice: no secure element at all. Instead, it uses a “virtual secure element” — the key is split between the device and Blockstream’s server (or your own blind oracle server). Neither party alone has the full key. This means a physical attacker who steals your Jade can’t extract your key (they’d also need the server PIN). The tradeoff: you need network access to decrypt your key for signing (though the signing itself can be air-gapped via QR). Fully open source. The cheapest entry point for air-gapped Bitcoin storage.

SeedSigner is the cypherpunk’s dream: you build it yourself from a Raspberry Pi Zero, a camera module, and a small screen (total cost ~$50–100 in parts). It runs Bitcoin-only signing software. It is entirely stateless — it doesn’t store your keys at all. Each time you use it, you scan your seed (as a QR code from your backup) or enter it manually, sign the PSBT, and the device forgets everything when powered off. There is nothing to steal if someone takes your SeedSigner, because it contains no keys.

BitKey (Block Inc., Jack Dorsey’s company) is a consumer-grade device that integrates a mobile app, a hardware device, and a server into a 2-of-3 multisig setup. You hold two keys (phone + hardware device), Block holds one. Any two of three can spend. If you lose the hardware device, you and Block can recover. If Block disappears, you have two keys locally. This is the most accessible multisig experience but requires trusting Block’s infrastructure for key management.

Which Hardware Wallet for Whom?

• “I want maximum paranoia and I’m Bitcoin-only” → ColdCard Mk4/Q
• “I want open source and I’ll build it myself” → SeedSigner
• “I want open source but not DIY, and I’ll accept the oracle model” → Jade
• “I want the most auditable commercial device” → Trezor Safe 5
• “I want maximum altcoin support and don’t mind closed firmware” → Ledger
• “I want easy multisig with no technical knowledge” → BitKey
• “I’m a developer who wants full control” → SeedSigner + Sparrow

Part VI: Multisig — Eliminating Single Points of Failure

Why Multisig

Single-signature wallets have a fundamental problem: one key controls everything. If that key is compromised, all funds are gone. If the key is lost, all funds are inaccessible. There’s no middle ground.

Multisig (multi-signature) solves this by requiring M of N keys to authorize a transaction. The most common setups:

• 2-of-3 — Three keys exist; any two can spend. Lose one key, you can still access funds. One key stolen, attacker can’t spend.
• 3-of-5 — Five keys exist; any three can spend. Higher redundancy but more operational complexity.

How Multisig Works On-Chain

Multisig is implemented using Bitcoin Script (see Chapter 2). The specific implementation depends on the address type:

P2SH Multisig (Legacy):

# The redeem script contains all public keys and the M-of-N requirement
OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG
# Wrapped in P2SH → 3... address

P2WSH Multisig (Native SegWit):

# Same logic, but in the witness script
# The witness contains: OP_0 <sig1> <sig2> <witness_script>
# bc1q... address (longer than single-sig bc1q due to 32-byte script hash)

P2TR Multisig (Taproot — via MuSig2 or Script Path):

# Option 1: MuSig2 key aggregation (key-path spend)
# All N signers collaborate to produce a single aggregated signature
# On-chain: looks identical to a single-sig spend (maximum privacy)

# Option 2: Taproot script-path
# Multisig logic in a MAST leaf; revealed only when spent

MuSig2 (BIP 327) is the most elegant approach: the N parties collaboratively produce a single public key and single signature. Nobody looking at the blockchain can tell it was a multisig. But it requires all N parties to be online and coordinate signing — it’s N-of-N by default. For M-of-N (like 2-of-3), you’d use Taproot’s script-path with multiple MAST leaves, each containing a different 2-of-3 combination.

# Create a multisig descriptor wallet in Bitcoin Core
bitcoin-cli createwallet "multisig_test" false true "" false true

# Add a multisig descriptor (2-of-3 with three xpubs)
bitcoin-cli -rpcwallet=multisig_test importdescriptors '[{
  "desc": "wsh(sortedmulti(2,[fp1/84h/0h/0h]xpub1/*,[fp2/84h/0h/0h]xpub2/*,[fp3/84h/0h/0h]xpub3/*))#checksum",
  "timestamp": "now",
  "active": true,
  "range": [0, 100]
}]'

# Derive a multisig address
bitcoin-cli -rpcwallet=multisig_test getnewaddress "" "bech32"

Managed Multisig Services

Setting up multisig correctly is hard. Key distribution, backup coordination, and transaction signing all become more complex. Two companies have built businesses around making multisig accessible:

Unchained (formerly Unchained Capital):

• 2-of-3 multisig (you hold 2 keys, Unchained holds 1)
• Hardware wallet agnostic (ColdCard, Trezor, Ledger)
• “Collaborative custody” — Unchained can co-sign but can never spend alone
• Inheritance planning: designated heir receives key access on verified death
• IRA product for Bitcoin in retirement accounts
• Unchained acts as a signing coordinator, not a custodian

Casa:

• 2-of-3 (basic) and 3-of-5 (premium) multisig
• Mobile key + hardware key(s) + Casa recovery key
• Health check system (periodically verifies you can still access your keys)
• Inheritance protocol with designated contacts
• More consumer-friendly than Unchained; less technical control

The key principle: in both models, the service provider holds ONE key in your multisig. They can facilitate recovery but cannot unilaterally spend your Bitcoin. Even if Unchained or Casa is compromised, seized, or goes bankrupt, the attacker gets at most one key — insufficient to spend.

This is qualitatively different from exchange custody (Coinbase, Kraken), where the exchange holds ALL the keys and you hold a database entry.

Part VII: The Passphrase (25th Word)

BIP 39 includes an optional passphrase (sometimes called the “25th word,” though it can be any string, not just a single word). When deriving the seed from the mnemonic, the passphrase is appended to the salt: PBKDF2(mnemonic, "mnemonic" + passphrase).

What the Passphrase Does

A different passphrase produces a completely different seed — and therefore completely different keys and addresses. There is no “wrong” passphrase; every passphrase produces a valid wallet. The “correct” passphrase is simply the one that derives the wallet containing your Bitcoin.

24-word mnemonic + no passphrase  → Wallet A (maybe empty, maybe decoy funds)
24-word mnemonic + "hunter2"      → Wallet B (your actual holdings)
24-word mnemonic + "anything"     → Wallet C (valid but empty)

Use Cases

Plausible deniability: If forced to reveal your seed phrase (by a thief, by a government, by a wrench), you can disclose the mnemonic without the passphrase. The attacker sees Wallet A, which might contain a small decoy amount. Your real funds in Wallet B remain hidden because the attacker doesn’t know a passphrase exists — let alone what it is.

Additional security layer: Even if your 24-word backup is stolen, the attacker can’t access funds without the passphrase. This turns single-factor security (something you have — the seed) into two-factor (something you have + something you know).

Risks

If you forget the passphrase, your Bitcoin is gone. There is no recovery. The wallet derived with the correct passphrase is the only wallet your funds exist in. A passphrase of "hunter2" and "Hunter2" produce different wallets. A trailing space produces a different wallet. Case sensitivity, whitespace, and Unicode normalization all matter.

Passphrase backups create their own security problem. If you write the passphrase on the same steel plate as the mnemonic, you’ve eliminated the benefit. If you memorize it, you’ve introduced the brain wallet failure mode — human memory is unreliable. The recommended approach: store the passphrase separately from the mnemonic, in a different geographic location, with clear documentation of its purpose.

Testing is essential. Before sending any Bitcoin to a passphrase-protected wallet:

1. Set up the wallet with your mnemonic + passphrase
2. Generate a receive address and note it
3. Wipe the device
4. Restore from mnemonic + passphrase
5. Verify the same receive address is generated
6. Only then fund the wallet

Part VIII: Shamir Secret Sharing (SLIP 39)

What It Is

Shamir Secret Sharing (SSS) is a cryptographic technique that splits a secret into N shares, of which any M are sufficient to reconstruct the original. Trezor implemented this as SLIP 39, which replaces BIP 39 mnemonic words with multiple sets of 20 or 33 words (shares).

Example: a 2-of-3 SLIP 39 setup generates three share groups. Any two groups can reconstruct the seed. Each group is a set of words (like BIP 39, but from a different word list).

Shamir vs. Multisig

These are fundamentally different tools that solve different problems:

When to use Shamir: backup redundancy. You want geographic distribution of your backup material so that losing one location doesn’t destroy your ability to recover. But you’re comfortable with single-sig spending.

When to use multisig: operational security. You want to ensure that no single device compromise, theft, or coercion can lead to loss of funds. Each key is an independent signing device — they never need to be in the same room.

The critical difference: with Shamir, when you reconstruct the seed to sign a transaction, the full seed exists in one device’s memory at that moment. With multisig, no single device ever holds enough information to spend. For high-value storage, multisig is strictly superior.

When Shamir Makes Sense

• You’re using single-sig (hardware wallet) and want robust backup distribution
• You want to give shares to family members for inheritance without any one person being able to access funds alone
• You’re supplementing multisig (backing up each individual multisig key with Shamir shares)

Part IX: Seed Storage — Physical Security

Your seed phrase is the master key to everything. Its physical storage is the most important operational security decision you’ll make.

Steel Backup Options

Paper degrades. Lamination helps but doesn’t survive fire. Steel plates withstand both:

Recommendation: center-punch or stamp methods (SeedPlate, Blockplate, DIY washers) are more durable than letter tiles because there are no moving parts that can scatter. Jameson Lopp has published extensive stress tests of seed storage devices — fire, crushing, corrosion, gunshots — and the results strongly favor solid-piece designs.

BIP 39’s four-letter prefix property means you only need to stamp the first four characters of each word. abandon → ABAN. This is unambiguous because no two BIP 39 words share their first four letters.

Geographic Distribution

A seed stored in one location is vulnerable to that location’s risks: fire, flood, burglary, government seizure.

The standard recommendation for significant holdings:

1. Primary backup — Home safe or safety deposit box
2. Secondary backup — Different geographic location (family member’s safe, second safety deposit box in a different bank, attorney’s vault)
3. Tertiary backup (for multisig) — Third location, ideally in a different city or state

For multisig, each key’s backup should be in a different location. A 2-of-3 multisig with all three keys in the same safe offers zero improvement over single-sig.

Inheritance Planning

Bitcoin inheritance is an unsolved problem at the protocol level. There is no beneficiary designation, no probate process, no account recovery. If you die without your heirs having access to your keys, the Bitcoin is permanently lost.

Approaches:

Letter of instruction: A sealed document stored with your will or estate attorney. It describes what Bitcoin is, where your hardware wallets are, where your seed backups are, and step-by-step recovery instructions. This is the minimum viable inheritance plan.

Unchained/Casa inheritance protocols: Both services offer heir designation. When your death is verified through a defined process, the service co-signs a transaction to transfer funds to your heir’s address.

Timelock-based dead man’s switch: Using OP_CHECKLOCKTIMEVERIFY (CLTV), you can create a transaction that becomes valid after a specific block height or date. You periodically refresh the timelock by moving funds to a new CLTV address with a later expiry. If you stop refreshing (because you’ve died or are incapacitated), the timelock eventually expires and your heir can claim the funds.

# Conceptual example of a timelock script for inheritance
# This is the spending condition, not a complete transaction
# After block 900000, heir_pubkey can spend; before that, only owner_pubkey can
#
# Script: OP_IF <owner_pubkey> OP_CHECKSIG
#         OP_ELSE <900000> OP_CHECKLOCKTIMEVERIFY OP_DROP <heir_pubkey> OP_CHECKSIG
#         OP_ENDIF

Multisig with a trusted party: In a 2-of-3 setup, give one key to your heir and one to a trusted service (attorney, Unchained, Casa). In normal operation, you use your two keys. After your death, your heir + the trusted service together control the funds.

The uncomfortable truth: every inheritance plan requires trusting someone — either a person, an institution, or a future version of yourself who keeps refreshing a timelock. Bitcoin eliminates counterparty risk for custody but reintroduces it for inheritance. Plan accordingly.

Part X: PSBTs (Partially Signed Bitcoin Transactions)

The Problem PSBTs Solve

Before BIP 174 (authored by Ava Chow), there was no standard way for multiple devices to collaboratively construct and sign a transaction. Each wallet had its own format. Hardware wallets had proprietary protocols. Multisig coordination was painful.

PSBTs (Partially Signed Bitcoin Transactions) define a universal container format for Bitcoin transactions that aren’t yet fully signed. A PSBT can be passed between devices — each one adding its signature — until the transaction has enough signatures to be valid.

PSBT Workflow

Step 1: CREATE (online wallet — Sparrow, Electrum, Bitcoin Core)
        Constructs the unsigned transaction with inputs, outputs, fee
        Encodes as PSBT (base64 string or binary file)
            │
            ▼
Step 2: TRANSFER (air-gap crossing)
        QR code, MicroSD card, USB, or file transfer
            │
            ▼
Step 3: SIGN (hardware wallet — ColdCard, Trezor, Jade, SeedSigner)
        Device displays transaction details for verification
        User confirms; device adds its signature to the PSBT
            │
            ▼
Step 4: (If multisig) TRANSFER to next signer → repeat Step 3
            │
            ▼
Step 5: FINALIZE (any PSBT-compatible wallet)
        Combines all signatures into a complete transaction
            │
            ▼
Step 6: BROADCAST (online wallet or bitcoin-cli)
        Sends the finalized transaction to the network

# PSBT workflow in Bitcoin Core

# Create a PSBT (unsigned transaction)
bitcoin-cli -rpcwallet=my_wallet walletcreatefundedpsbt \
  '[]' \
  '[{"bc1q...recipient_address": 0.01}]' \
  0 \
  '{"changeAddress": "bc1q...change_address"}'
# Returns: { "psbt": "cHNidP8BAH0CAAA...", "fee": 0.00000141, "changepos": 1 }

# Process the PSBT (adds UTXO information for signing)
bitcoin-cli walletprocesspsbt "cHNidP8BAH0CAAA..."

# Analyze a PSBT (check what signatures are present/missing)
bitcoin-cli analyzepsbt "cHNidP8BAH0CAAA..."
# Shows: which inputs need signatures, estimated fee, etc.

# Finalize (combine all signatures into valid transaction)
bitcoin-cli finalizepsbt "cHNidP8BAH0CAAA..."
# Returns: { "hex": "0200000001...", "complete": true }

# Broadcast the finalized transaction
bitcoin-cli sendrawtransaction "0200000001..."

PSBT Version 2 (BIP 370)

BIP 174 (PSBT v0) has a limitation: the transaction must be fully constructed before any signing begins. BIP 370 (PSBT v2, also by Ava Chow) allows inputs and outputs to be added incrementally. This is critical for:

• CoinJoin — Multiple parties each add their inputs and outputs to the same transaction
• PayJoin — Sender and receiver both contribute inputs
• Interactive protocols — Any workflow where the transaction is built collaboratively

Why PSBTs Matter

PSBTs are the glue that makes modern self-custody work. Without them:

• Air-gapped signing wouldn’t have a standard format
• Hardware wallets from different manufacturers couldn’t interoperate
• Multisig coordination would require each wallet to understand every other wallet’s format
• CoinJoin implementations would each need custom integration

Sparrow Wallet’s entire UX is built around PSBTs. When you create a transaction in Sparrow with a connected hardware wallet, what’s actually happening under the hood is: Sparrow creates a PSBT → sends it to the hardware wallet → the hardware wallet signs and returns the PSBT → Sparrow finalizes and broadcasts.

Part XI: Common Mistakes and Attack Vectors

Address Reuse (Privacy Leak)

Every time you reuse an address, you link all transactions involving that address. An observer can track your balance and spending patterns. HD wallets generate a new address for each receive — use that feature. Never manually copy-paste an address you’ve used before.

Bitcoin Core discourages address reuse by default:

# Generate a fresh address each time — never reuse
bitcoin-cli -rpcwallet=my_wallet getnewaddress "" "bech32"

Clipboard Malware

A category of malware specifically targeting cryptocurrency users. It monitors the clipboard and, when it detects a Bitcoin address (pattern matching on the prefix and length), silently replaces it with an attacker’s address. You paste what you think is the recipient’s address; you actually paste the attacker’s.

Defense: Always visually verify the full address on your hardware wallet’s screen before confirming a transaction. This is exactly why hardware wallets have screens — so you can verify the destination address on a device the malware can’t compromise.

Fake Hardware Wallets (Supply Chain Attacks)

Tampered hardware wallets have been documented. Attack vectors:

• Modified firmware — Device looks genuine but generates keys the attacker also knows
• Pre-loaded seed phrases — Device arrives with a seed phrase card, claiming it’s “your” seed. It’s actually the attacker’s seed. You load Bitcoin; they drain it.
• Counterfeit devices — Physical clones with malicious hardware

Defense:

1. Buy directly from the manufacturer. Never from Amazon third-party sellers, eBay, or “deals” on forums.
2. Verify the anti-tamper packaging is intact.
3. The device should generate your seed phrase fresh. If it arrives with a pre-filled seed, it’s compromised.
4. Verify firmware signatures before first use.
5. ColdCard has a “bag number” system — each device’s sealed bag has a unique number you can verify on Coinkite’s website.

SIM Swap Attacks

Attacker convinces your mobile carrier to port your phone number to their SIM. They then use SMS-based 2FA to access your exchange accounts. This doesn’t directly affect hardware wallet self-custody, but it’s devastating for anyone using:

• SMS 2FA on exchanges
• Phone-number-based recovery on any Bitcoin-related service

Defense: Use hardware-based 2FA (YubiKey) or TOTP (Google Authenticator, Authy) — never SMS. For mobile carrier security, add a PIN/passphrase to your account. Consider Google Fi or carriers that support number-lock features.

The $5 Wrench Attack

The most effective attack on Bitcoin self-custody requires no technical sophistication: someone threatens you with physical violence until you hand over your keys.

Mitigations:

• Don’t talk about your Bitcoin holdings publicly
• Passphrase wallets for plausible deniability (see Part VII)
• Multisig with geographically distributed keys (attacker can’t force you to access keys you physically can’t reach)
• Timelock transactions that prevent immediate spending
• Duress wallets: a small amount in an easily-accessible wallet you can surrender

Phishing and Social Engineering

The most common attack vector is not technical — it’s human. Common patterns:

• “Support agent” on Discord/Telegram asks for your seed phrase (no legitimate service will ever ask for this)
• Fake wallet apps in app stores
• Clone websites with slightly different URLs (e.g., electrurn.org instead of electrum.org)
• “Airdrop” transactions that send dust to your address with a memo pointing to a phishing site

The rule is simple: NEVER enter your seed phrase into any computer, website, app, or form. The only places your seed should ever exist are: (1) your hardware wallet, (2) your physical backup (steel/paper), and (3) during initial setup/recovery on the hardware wallet’s own screen.

Part XII: Self-Custody Philosophy

“Not Your Keys, Not Your Coins”

This phrase, attributed to Andreas Antonopoulos, captures the fundamental reality of Bitcoin: if someone else holds your private keys, you don’t own Bitcoin. You own an IOU from the entity holding your keys. Whether that entity is an exchange, a bank, a fund, or a government — you have a claim, not a possession.

Satoshi designed Bitcoin to eliminate trusted third parties. The entire point of proof-of-work, of the UTXO model, of the scripting system, is to create money that can be held and transferred without anyone’s permission. Using an exchange as a permanent wallet reverses every property that makes Bitcoin different from a bank balance.

The Graveyard of Custodians

History has demonstrated this lesson with extraordinary consistency:

Mt. Gox (2014): The dominant Bitcoin exchange, handling 70% of all Bitcoin transactions at its peak. Lost 850,000 BTC (recovered ~200,000). Users waited TEN YEARS for partial recovery through Japanese bankruptcy proceedings. As of 2024, creditors received approximately 15% of their holdings, denominated in Bitcoin at 2014 prices.

QuadrigaCX (2019): Canadian exchange. Founder Gerald Cotten died (or claimed to die) with the only keys to $190 million in customer funds. An investigation revealed the funds had likely been misappropriated long before his death. Users recovered almost nothing.

Celsius Network (2022): Crypto lending platform froze withdrawals in June 2022 with $4.7 billion in customer assets. Filed bankruptcy the next month. Customers classified as unsecured creditors — behind lawyers and executives in the repayment queue.

FTX (2022): The second-largest cryptocurrency exchange. Customer funds were secretly loaned to Alameda Research (FTX’s sister trading firm) and lost. $8+ billion in customer deposits vanished. Founder Sam Bankman-Fried convicted of fraud and sentenced to 25 years. Customers in bankruptcy proceedings as of 2024.

BlockFi (2022): Crypto lending platform. Filed bankruptcy in November 2022 after FTX collapse. Customer funds locked for years. Partial recovery through bankruptcy.

The pattern is identical every time:

1. Custodian appears legitimate and trustworthy
2. Custodian takes risks with customer funds (rehypothecation, lending, fraud, or simply poor security)
3. Custodian fails
4. Customers discover they have no Bitcoin — they have a bankruptcy claim

Every one of these failures was preventable with self-custody. Not theoretically. Literally. If those users had held their own keys, no management decision, fraud, hack, or death could have touched their Bitcoin.

The Spectrum of Trust

Self-custody isn’t binary. There’s a spectrum:

Full custodial    ──────────────────────────────────────>    Full self-custody
(exchange holds   (exchange + your    (managed         (single-sig    (multisig,
 all keys)         2FA/withdrawal     multisig —       hardware       own keys,
                   whitelist)         Unchained/Casa)  wallet)        geographic
                                                                      distribution)
    ▲                    ▲                   ▲              ▲              ▲
    │                    │                   │              │              │
  LEAST              MODERATE           GOOD           STRONG        MAXIMUM
  SECURE             SECURITY           SECURITY       SECURITY      SECURITY

Move as far right as your technical comfort and operational discipline allow. The minimum for anyone holding more than pocket change: a hardware wallet with a properly backed-up seed phrase.

The Real Risk Calculus

Self-custody skeptics argue: “Most people will lose their keys. An exchange is safer.”

This is like arguing: “Most people will crash their car. Let someone else drive.” It’s true for some people. But the response isn’t to give up driving — it’s to learn how to drive.

The realistic threats, ranked by probability of actual Bitcoin loss:

1. Exchange insolvency/fraud — Has happened repeatedly, affecting millions of users
2. Lost seed phrases / forgotten passphrases — Preventable with proper backup
3. Phishing / social engineering — Preventable with education and discipline
4. Physical theft — Mitigated by multisig and passphrase wallets
5. Hardware wallet vulnerability — Extremely rare; no mass-exploit has occurred
6. Sophisticated targeted attack — Only relevant if you’re publicly known to hold large amounts

For most people, the exchange risk (item 1) is orders of magnitude higher than the self-custody risks (items 2–6) combined. Self-custody is harder, but the failure modes are all within your control. Exchange custody outsources both the security AND the risk to someone whose incentives may not align with yours.

Part XIII: Practical Self-Custody Checklist

For someone setting up self-custody for the first time:

Phase 1: Basic (1 hardware wallet)

• Buy a hardware wallet directly from the manufacturer
• Initialize it and write down the 24-word seed phrase
• Stamp or punch the seed onto a steel backup
• Test recovery: wipe the device, restore from seed, verify same addresses
• Send a small test transaction, verify receipt, send back
• Store the steel backup somewhere physically secure (not the same room as the hardware wallet)

Phase 2: Robust (passphrase + geographic distribution)

• Add a passphrase to create a hidden wallet
• Document the passphrase separately from the seed
• Create a second steel backup of the seed; store in a different location
• Write a letter of instruction for heirs (what it is, where the backups are, how to recover)

Phase 3: Paranoid (multisig)

• Set up 2-of-3 multisig using Sparrow, Nunchuk, or a managed service
• Use three different hardware wallets from different manufacturers
• Store each key’s backup in a different geographic location
• Test the full signing workflow: create PSBT → sign on device 1 → sign on device 2 → broadcast
• Document the multisig configuration (xpubs, derivation paths, quorum) — this is needed for recovery

# Verify your wallet setup in Bitcoin Core
# Check that your descriptors are correctly imported
bitcoin-cli -rpcwallet=my_wallet getwalletinfo

# List all descriptors and their derivation paths
bitcoin-cli -rpcwallet=my_wallet listdescriptors true

# Verify a specific address belongs to your wallet
bitcoin-cli -rpcwallet=my_wallet getaddressinfo "bc1q..."

Key Takeaways

1. A wallet holds keys, not Bitcoin. UTXOs live on the blockchain. Keys are what let you spend them. Lose the keys, lose the Bitcoin.

2. BIP 39 turns entropy into words; BIP 32 turns words into a tree of keys. Your 12 or 24 words back up an unlimited number of addresses across all four address types (P2PKH, P2SH-SegWit, P2WPKH, P2TR).

3. Native SegWit (bc1q) is the current default; Taproot (bc1p) is the future. Both are supported by all major wallets. Legacy addresses cost more in fees and should not be used for new wallets.

4. Hardware wallets are the baseline for serious self-custody. ColdCard for maximum paranoia. Trezor for open-source purity. Jade for cheap air-gapping. SeedSigner for stateless DIY. Ledger for altcoin support (with the trust tradeoff).

5. Multisig eliminates single points of failure. 2-of-3 is the most common setup. No single device compromise, theft, or coercion can result in loss. Unchained and Casa make multisig accessible.

6. The passphrase (25th word) adds plausible deniability and a second factor — but if you forget it, your funds are irretrievable. Test recovery before funding.

7. Shamir (SLIP 39) splits your backup; multisig splits your signing authority. They solve different problems. For high-value holdings, multisig is strictly superior because no single device ever holds the complete signing capability.

8. PSBTs (BIP 174) are the universal standard for multi-device transaction signing. They enable air-gapped workflows, hardware wallet interoperability, and multisig coordination.

9. Steel backups, geographic distribution, and a letter of instruction are the minimum for responsible seed storage. Your backup strategy must survive fire, flood, theft, and your own death.

10. Self-custody is not optional if you take Satoshi’s design seriously. Mt. Gox, QuadrigaCX, Celsius, FTX — the pattern is always the same. The only Bitcoin you truly own is Bitcoin you hold the keys to. Everything else is a promise.

Previous: Chapter 8 — Satoshi’s Timeline and Bitcoin Core History — Who built Bitcoin, who maintains it now, and who actually controls it.

Next: Chapter 10 — Mining & Hardware — From Satoshi’s CPU to 1,160 TH/s hydro-cooled ASICs: the mining arms race and its economics.

Related: Chapter 2 — The Script System — How P2PKH, P2SH, P2WSH, and P2TR scripts work at the opcode level.

Chapter 10: Mining & Hardware

In Satoshi’s Words

“At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.”

— Satoshi Nakamoto, Bitcoin whitepaper mailing list, November 3, 2008

Satoshi predicted industrial mining before Bitcoin had a single user. Before there was a genesis block, before there was a price, before Hal Finney ran the second node — Satoshi already knew that CPU mining was a bootstrapping mechanism, not an endgame. The whitepaper mailing list message is unambiguous: specialist hardware, server farms, economies of scale. This wasn’t a corruption of the original vision. It was the original vision.

The romance of “one CPU, one vote” lasted about eighteen months. What replaced it is an arms race that has consumed billions of dollars in capital, reshaped global energy markets, and produced the most powerful computational network in human history — one that now processes over 800 exahashes per second. This chapter covers how we got here, what the hardware landscape looks like today, and why the economics of mining are far more nuanced than “plug in a machine and print money.”

Part I: The Mining Evolution

Era 1: CPU Mining (January 2009 – Mid 2010)

When Satoshi launched Bitcoin on January 3, 2009, you mined with whatever processor your computer had. Satoshi’s own mining setup was almost certainly a modest desktop PC — he mined approximately 1.1 million BTC (the Patoshi pattern blocks) on what appears to have been a single machine, possibly throttled to avoid dominating the network too aggressively.

In this era:

• Hardware: Intel/AMD desktop CPUs. A Core 2 Duo might produce 2–5 MH/s (megahashes per second).
• Who did it: Satoshi, Hal Finney, a handful of cypherpunks and early adopters.
• Difficulty: Started at 1 (the minimum). By May 2010, it had only climbed to about 24.
• Economics: Electricity cost was irrelevant — you were mining bitcoin worth fractions of a cent per coin. The real cost was the opportunity cost of caring about this at all.

Satoshi himself acknowledged the transitional nature of CPU mining on BitcoinTalk:

“The current system where every user is a network node is not the intended configuration for large scale.” — Satoshi Nakamoto, BitcoinTalk, July 14, 2010

By mid-2010, GPU mining was already making CPU mining obsolete. The “one CPU, one vote” era lasted less than two years.

Era 2: GPU Mining (Mid 2010 – 2012)

On July 18, 2010, a developer known as ArtForz is generally credited with creating the first OpenCL-based GPU miner. The logic was straightforward: Bitcoin’s SHA-256 hashing algorithm is massively parallelizable, and GPUs have thousands of simple cores designed for parallel computation. A single high-end GPU could outperform dozens of CPUs.

In this era:

• Hardware: AMD Radeon HD 5870, 5970, 6990. Nvidia GPUs were used but AMD had a significant advantage due to their architecture being better suited to integer math.
• Hashrate: A Radeon HD 5870 could produce ~400 MH/s — roughly 100x faster than a high-end CPU.
• Who did it: Early technical adopters, gamers repurposing hardware, the first dedicated mining “rigs” with multiple GPUs.
• Profitability: Enormously profitable at first. A $350 GPU could mine dozens of BTC per day in late 2010. By late 2011, rising difficulty made it harder but still viable.
• When it died: GPU mining remained profitable through most of 2012 for those with cheap electricity and efficient setups. By mid-2013, ASICs made GPUs uncompetitive for SHA-256 mining. Some GPU miners pivoted to Litecoin (Scrypt) and later Ethereum (Ethash).

The GPU era established two patterns that persist today:

1. Hardware arms races favor whoever adopts next-generation technology first — early GPU miners made fortunes; late GPU miners barely broke even.
2. Mining centralizes toward whoever has access to cheap electricity and better hardware — the meritocracy of “anyone with a laptop” ended permanently.

Era 3: FPGA Mining (Mid 2011 – Early 2013)

Field-Programmable Gate Arrays (FPGAs) are chips that can be configured at the logic-gate level to perform specific computations. Several companies produced FPGA-based Bitcoin miners starting in mid-2011.

In this era:

• Hardware: Xilinx Spartan-6, Altera Cyclone IV-based boards. Products like the BFL (Butterfly Labs) Single, Icarus, and ModMiner Quad.
• Hashrate: 100–800 MH/s per unit, comparable to GPUs.
• Key advantage: Not raw speed but power efficiency. An FPGA could deliver GPU-level hashrate at a fraction of the wattage, often under 10 watts per 100 MH/s compared to 200+ watts for an equivalent GPU.
• Who did it: Technically sophisticated miners, small companies specializing in FPGA design.
• When it died: Late 2012 to early 2013, when the first ASICs arrived and immediately made FPGAs noncompetitive.

The FPGA era was short — barely 18 months — and is often treated as a footnote. But it was significant as a proof of concept: custom silicon for Bitcoin mining was viable and profitable. The companies and engineers who learned FPGA design during this period became the talent pipeline for the ASIC era.

Era 4: ASIC Mining (2013 – Present)

Application-Specific Integrated Circuits (ASICs) are chips designed to do one thing and one thing only: compute SHA-256 hashes. They cannot run an operating system, browse the web, or do anything else. They are the most efficient possible implementation of the SHA-256 algorithm in silicon.

The first Bitcoin ASIC: Avalon shipped the first commercial Bitcoin ASIC miner in January 2013 — the Avalon1, producing approximately 66 GH/s (gigahashes per second). It was roughly 50x more efficient than the best GPU and marked the point of no return for general-purpose mining hardware.

The early ASIC era was chaotic:

• Butterfly Labs sold ASIC miners on pre-order, then failed to deliver for months while mining with customers’ machines. They were eventually shut down by the FTC for fraud.
• KnC Miner (Sweden) produced competitive ASICs but went bankrupt by 2016.
• Avalon (Canaan Creative, China) shipped first but couldn’t maintain manufacturing leadership.
• Bitmain (China), founded in 2013 by Jihan Wu and Micree Zhan, rapidly became the dominant manufacturer. Their Antminer S-series became the de facto standard for Bitcoin mining hardware.

Why ASICs centralized manufacturing: Designing and fabricating a competitive ASIC requires:

1. Multi-million dollar tape-out costs (the process of turning a chip design into physical silicon)
2. Access to leading-edge semiconductor foundries (TSMC, Samsung)
3. Deep expertise in chip architecture, power delivery, and thermal management
4. Supply chain relationships for components, enclosures, and power supplies

These barriers to entry mean that as of 2026, essentially three companies produce the vast majority of Bitcoin mining hardware globally. This is a centralization pressure that the protocol itself cannot address — it’s a manufacturing and capital markets problem.

Part II: Current Hardware Landscape (2025–2026)

The mining hardware market in 2025–2026 is defined by three manufacturers, a push toward sub-10 J/TH efficiency, and the emergence of liquid/hydro cooling as the differentiator between mid-tier and top-tier operations.

The Big Three Manufacturers

Bitmain (Antminer S-series) remains the market leader, with an estimated 50–60% market share of new ASIC sales. Their Antminer S21 series represents the current generation.

MicroBT (Whatsminer M-series) is the primary competitor, with roughly 25–35% market share. Founded in 2016 by Yang Zuoxing, a former Bitmain chip designer (the subject of an extended legal dispute), MicroBT has consistently produced competitive alternatives.

Auradine (Teraflux) is the newest entrant — a US-based company founded in 2022 and backed by significant venture capital. Their Teraflux line targets the premium efficiency segment and represents the first serious American challenge to the Chinese duopoly.

Hardware Comparison Table (2025–2026 Models)

Note: Prices fluctuate with Bitcoin price and difficulty. The 1,160 TH/s unit is Bitmain’s flagship immersion model — a single rack-mounted unit producing hashrate that would have represented a meaningful fraction of the entire network just a few years ago.

Cooling Is the New Battleground

Air-cooled miners top out around 270 TH/s with current chip technology. To push beyond that, manufacturers have turned to liquid cooling:

• Direct-to-chip hydro cooling: Coolant flows through cold plates mounted directly on the ASIC chips. This is what Bitmain’s “Hydro” models use. Allows higher clock speeds and denser rack deployment.
• Single-phase immersion cooling: The entire miner is submerged in a dielectric fluid. Companies like LiquidStack and GRC provide the tanks. Eliminates fans entirely, reduces noise to near-zero, and enables heat reuse.
• Two-phase immersion cooling: The dielectric fluid boils on contact with the chips, and the vapor condenses on a heat exchanger. The most efficient cooling method, but also the most complex and expensive to deploy.

Industrial mining operations increasingly treat cooling infrastructure as the primary capital investment — the ASICs themselves are almost commoditized. The ability to remove heat determines power density, which determines cost per hash.

Part III: Mining Economics

Mining is not a technology problem. It’s an energy arbitrage problem with a hardware component. The miners who survive are the ones who secure the cheapest electricity, not necessarily the ones with the newest machines.

Hashprice: The Universal Mining Metric

Hashprice is the daily revenue earned per unit of hashrate, typically expressed as USD per petahash per day ($/PH/day). It captures the combined effect of Bitcoin’s price, network difficulty, transaction fees, and the block subsidy in a single number.

As of early 2026 (post-fourth halving):

• Block subsidy: 3.125 BTC per block (halved from 6.25 in April 2024)
• Average transaction fees: 0.2–0.5 BTC per block (highly variable; can spike to 2+ BTC during congestion)
• Network hashrate: ~800 EH/s
• Hashprice: Approximately $45–55/PH/day

For context, hashprice peaked above $400/PH/day during the 2021 bull market (when BTC was $60K+ and difficulty hadn’t caught up). After the 2024 halving, it dropped below $50 and has largely stayed in that range.

Difficulty Adjustments: The Thermostat

Bitcoin’s difficulty adjustment is one of its most elegant mechanisms. Every 2,016 blocks (approximately every two weeks), the protocol recalculates the mining difficulty target:

new_difficulty = old_difficulty × (2016 blocks × 10 minutes) / (actual time for last 2016 blocks)

If blocks came too fast (miners added hashrate), difficulty goes up. If blocks came too slow (miners dropped off), difficulty goes down. The maximum adjustment per period is capped at 4x in either direction — a safety valve Satoshi added to prevent instability.

This creates a self-regulating system:

1. Bitcoin price rises → mining becomes more profitable → miners add hardware → hashrate increases → difficulty increases → profitability normalizes
2. Bitcoin price falls → mining becomes unprofitable for marginal miners → they shut off → hashrate decreases → difficulty decreases → remaining miners become profitable again

The difficulty adjustment is why Bitcoin’s block time has remained remarkably close to 10 minutes for seventeen years, despite hashrate increasing by a factor of roughly 10^14 from the first block to today.

Electricity Cost Breakeven Analysis

The single most important variable in mining economics is the cost of electricity. Here’s a breakeven analysis for a modern air-cooled miner (Antminer S21 Pro, 234 TH/s, 15 J/TH) at different electricity rates, assuming a Bitcoin price of $90,000 and network difficulty as of early 2026:

Assumes continuous operation; excludes hosting costs, maintenance, hardware depreciation, and cooling overhead. Real margins are 10-20% lower than shown.

Key observations:

• Below $0.04/kWh is the “printing money” zone. This is where flared gas, stranded hydro, and curtailed renewable sites operate.
• $0.06–0.08/kWh is where well-run industrial operations live.
• Above $0.10/kWh, you’re fighting for scraps. Residential electricity rates in most developed countries ($0.10–0.30/kWh) make home mining a money-losing hobby.
• At $0.14/kWh and above, even efficient hardware loses money. This is where older-generation machines (S19 series, 20-30 J/TH) have already been forced offline.

The Halving Cycle and Profitability

Bitcoin’s block subsidy halves every 210,000 blocks (approximately every four years). This is the single most predictable shock to mining economics:

Each halving cuts the block subsidy in half overnight. Miners who were operating on thin margins are immediately pushed into negative territory. The survivors are those with:

1. The cheapest power
2. The most efficient hardware
3. The lowest overhead (cooling, rent, staff, financing)
4. Access to capital to upgrade hardware before the halving hits

The fourth halving in April 2024 was particularly brutal because it came during a period of already-elevated difficulty. Many operators running S19j Pro models (approximately 29.5 J/TH) found themselves unprofitable unless their power cost was below $0.05/kWh.

Part IV: The Pool Landscape

Why Pools Exist

Solo mining a Bitcoin block in 2026 is a lottery ticket. With network hashrate at ~800 EH/s, a single Antminer S21 Pro (234 TH/s) has a probability of finding a block of approximately:

234 TH/s / 800,000,000 TH/s = 0.00000029 (0.000029%)

At 144 blocks per day, that miner would expect to find one block approximately every 24,000 days — about 65 years. When it does find one, it earns ~3.125 BTC plus fees (roughly $300,000 at current prices). But the variance is extreme: you might find one in a week, or you might never find one.

Mining pools solve this problem through statistical aggregation. Thousands of miners contribute hashrate to a pool, the pool finds blocks at a predictable rate, and rewards are distributed proportionally. You earn less per block, but you earn consistently.

Current Pool Distribution

The concentration problem is severe. The top 4 pools (Foundry, AntPool, ViaBTC, F2Pool) control approximately 70% of total network hashrate. This is not mining centralization in the traditional sense — the individual miners who point hashrate at these pools can switch at any time — but it creates a different, arguably more dangerous form of centralization: block template centralization.

How Pools Work: Shares, Payouts, and the Trust Problem

A mining pool operates by distributing work units to its members. Each work unit is a candidate block template — a partially completed block header that the miner needs to complete by finding a valid nonce. Here’s the flow:

1. Pool constructs a block template — selects transactions from the mempool, builds the Merkle tree, sets the coinbase transaction (with the pool’s payout address)
2. Pool distributes work — sends each miner a unique portion of the nonce space to search
3. Miners hash — trying nonces until they find one that produces a hash below the pool’s “share difficulty” (much easier than the network difficulty)
4. Miners submit shares — each valid share proves the miner did work, even if it wasn’t a full block solution
5. Occasionally, a share IS a block solution — the pool broadcasts it to the network and earns the block reward
6. Pool distributes rewards — to all miners proportionally based on shares submitted

Payout Methods

FPPS has become the dominant payout method at major pools because miners prefer predictable income. The pool effectively acts as an insurance company, absorbing the variance of block-finding in exchange for keeping a small fee (typically 1–3%).

Pool Hopping

Pool hopping is the practice of switching between pools to maximize short-term returns — mining at a PPLNS pool right after it finds a block (when few shares are in the window, meaning each new share earns a larger proportion) and leaving before the next block is found. Modern pools have implemented anti-hopping measures (larger N in PPLNS, score-based systems), and the dominance of PPS/FPPS has made hopping largely irrelevant. If you’re paid per share regardless of blocks found, there’s nothing to hop to.

Part V: The Centralization Problem — Who Builds the Blocks?

This is the most important and least understood issue in Bitcoin mining today.

When you point your ASIC at Foundry USA or AntPool, you are not choosing which transactions go into blocks. You’re not even choosing the block structure. You are hashing a template that the pool operator constructed. You are a dumb compute node executing someone else’s decisions.

The pool operator decides:

• Which transactions to include (and which to exclude or censor)
• How to order transactions (relevant for MEV — Miner Extractable Value — and for Ordinals/BRC-20 sorting)
• Whether to include OP_RETURN data, Ordinals inscriptions, or other “controversial” transaction types
• The coinbase message (the arbitrary data in the coinbase transaction)

This means that even though “hashrate is distributed” across thousands of individual miners worldwide, the actual power to construct blocks — to decide what Bitcoin’s blockchain contains — is concentrated in a handful of pool operators. Foundry USA alone constructs ~30% of all Bitcoin blocks. Add AntPool, and two entities construct roughly half.

This is not a theoretical concern. It has practical implications:

1. Transaction censorship: A pool operator could refuse to include transactions from sanctioned addresses. In 2022, Foundry USA and Marathon briefly experimented with OFAC-compliant block templates that excluded transactions involving sanctioned addresses. The backlash was intense, and both reversed course, but the capability exists.

2. MEV extraction: As on-chain activity becomes more complex (Ordinals, BRC-20 tokens, Runes), the ordering of transactions within a block has economic value. Pool operators can extract this value. Miners see none of it.

3. Government coercion: A government that wants to censor specific Bitcoin transactions doesn’t need to control 51% of hashrate. It needs to pressure the pool operators who construct 51% of block templates. If Foundry USA (US-based) and AntPool (China-based) both complied with their respective governments, over 48% of block templates would be censored.

4. Empty block mining: Some pools have been observed mining empty blocks (containing only the coinbase transaction) immediately after receiving a new block, before they’ve had time to validate the full block and construct a new template. This is rational behavior for the pool (they earn the block subsidy without waiting) but harmful to the network (it wastes block space and delays transaction confirmation).

The fix is not to complain about pool centralization. The fix is to change the protocol so that miners — not pool operators — construct their own templates.

Part VI: Stratum V2 — The Fix for Template Centralization

The Problem with Stratum V1

The original mining pool protocol, Stratum V1, was introduced by Slush Pool (now Braiins) in 2012. It’s simple and effective: the pool sends work to miners, miners return shares. But it has a fundamental design flaw: the pool constructs the block template, and the miner has no say in what that template contains.

Under Stratum V1, the miner is a hashing machine. Nothing more. It doesn’t see the transactions, doesn’t choose the block structure, and has no way to resist censorship by the pool operator.

What Stratum V2 Changes

Stratum V2 is a complete protocol redesign, co-developed by Braiins, Square Crypto (now Spiral), and others. It introduces three key improvements:

1. Job Declaration Protocol: The miner can construct its own block template and submit it to the pool. The pool validates that the template is valid (correct difficulty, valid transactions) but cannot force the miner to use the pool’s template. This is the critical change — it shifts template construction authority from pool operators back to individual miners.

2. Encrypted connections: Stratum V1 sends all communication in plaintext. Anyone between the miner and the pool (ISP, government, man-in-the-middle) can see which pool the miner is using and what work it’s doing. Stratum V2 uses AEAD (Authenticated Encryption with Associated Data) to encrypt the connection.

3. Bandwidth reduction: Binary framing (instead of JSON over TCP) reduces bandwidth by roughly 50%, which matters for miners in areas with poor internet connectivity.

Job Declaration: Why It Matters

With Job Declaration enabled:

• The miner selects transactions from its own mempool
• The miner builds the Merkle tree
• The miner decides what goes in the block
• The pool just validates and distributes the reward

This fundamentally changes the centralization dynamic. Even if 30% of hashrate points at Foundry USA, if those miners are running Stratum V2 with Job Declaration, Foundry can’t censor transactions. Each miner constructs its own template. The pool is reduced to an accounting layer — a payout coordinator, not a block builder.

Adoption Status

Ocean (founded by Jack Dorsey and Luke Dashjr) was the first major pool to implement Stratum V2 with Job Declaration support. Ocean also pioneered non-custodial payouts — miners receive their share of the block reward directly in the coinbase transaction rather than trusting the pool to pay them later.

Braiins Pool (formerly Slush Pool) has supported Stratum V2 since 2023, though full Job Declaration adoption among its miners has been slow.

DEMAND: The firmware side matters too. Braiins OS and other aftermarket firmware packages support Stratum V2 on compatible hardware. Bitmain’s stock firmware does not natively support Stratum V2 Job Declaration as of early 2026 — a notable gap given Bitmain’s hardware market share.

The honest assessment: Stratum V2 is technically ready and demonstrably superior. But adoption is slow because (a) most miners are economically indifferent to template construction — they care about payout reliability and low fees — and (b) pool operators have no incentive to give up template authority, which is a source of both economic value and influence.

Part VII: Solo Mining vs. Pool Mining

The Math

Solo mining makes economic sense only when your hashrate is large enough that the expected time between blocks is short relative to your financial planning horizon.

When Solo Mining Makes Sense

1. You operate at scale: If you have 100+ PH/s, you’ll find blocks regularly enough that variance smooths out naturally. Major public miners like Marathon and CleanSpark solo-mine or run proprietary pools.

2. You want maximum sovereignty: Solo mining means you construct your own block template, select your own transactions, and answer to no pool operator. This is philosophically aligned with Bitcoin’s design, even if economically suboptimal for small operations.

3. You’re running a lottery miner: Some hobbyists run a single old-generation ASIC as a solo miner, fully aware they’re unlikely to ever find a block. The expected value is approximately the same as pool mining (minus pool fees), but the payout distribution is binary: 0 or ~$300,000. For someone who can afford the electricity and treats it as entertainment, this is fine. It’s not a business strategy.

When Solo Mining Doesn’t Make Sense

For virtually everyone else. If you’re operating fewer than 50 PH/s and depend on mining income to cover costs, pool mining is the rational choice. The guaranteed, predictable revenue from FPPS payouts lets you plan, budget, and service debt — all things that are impossible when your income arrives in random ~$300,000 lump sums separated by months or years of nothing.

Part VIII: The AI Pivot — Mining Facilities as Data Centers

One of the most significant trends in the mining industry since 2023 is the pivot toward high-performance computing (HPC) and artificial intelligence workloads. Several publicly traded Bitcoin miners have announced or begun converting portions of their mining infrastructure to GPU-based AI/ML compute.

Why Mining Facilities Are Perfect for AI

Bitcoin mining facilities and AI data centers have nearly identical infrastructure requirements:

The key insight: power infrastructure is the bottleneck for AI scaling, and Bitcoin miners already have it. A mining facility with 100 MW of grid capacity, cooling, and permitting can repurpose that infrastructure for AI training or inference workloads faster than a hyperscaler can build new capacity from scratch.

The Major Players

Marathon Digital (MARA): The largest publicly traded Bitcoin miner by market cap. Marathon has announced plans to allocate portions of its 1+ GW pipeline to AI/HPC hosting. Their Garden City, Texas facility is being partially converted.

IREN (formerly Iris Energy): Australian-founded, US-listed miner with operations in British Columbia and Texas. IREN has been the most aggressive AI pivoter, with Nvidia GPU clusters already deployed alongside Bitcoin ASICs. They’ve secured significant contracts for AI inference hosting.

CleanSpark: Georgia-based miner that has expanded rapidly through acquisition of distressed mining sites. More cautious on the AI pivot than peers, but has explored colocation arrangements.

Hut 8: Canadian miner that merged with USBTC in 2023. Has explicitly targeted AI/HPC as a diversification strategy, with GPU compute offerings.

Core Scientific: Emerged from bankruptcy in early 2024 and immediately pivoted toward AI hosting, signing a 200 MW deal with CoreWeave (a GPU cloud provider).

The Economics of the Pivot

The math is compelling. Bitcoin mining generates approximately $30–60 per MWh consumed (depending on hashprice). AI/HPC hosting can generate $100–200+ per MWh consumed. The capital expenditure to convert is significant — GPU servers cost far more than ASICs, and the networking/storage requirements are different — but the revenue per megawatt is substantially higher.

The catch: AI hosting requires higher reliability (SLAs, redundancy, uptime guarantees) than Bitcoin mining. If a Bitcoin miner goes offline for an hour, you lose an hour of expected revenue. If an AI training cluster goes offline for an hour, you might corrupt a multi-million-dollar training run. The operational discipline required is different.

Strategic Tension

There’s a philosophical tension in the mining industry about this pivot. Bitcoin maximalists view it as miners abandoning their core function — securing the network — in pursuit of higher margins. The pragmatists view it as rational capital allocation that actually strengthens Bitcoin mining: AI revenue cross-subsidizes Bitcoin mining operations, allowing miners to keep hashrate online even during low-profitability periods.

The most likely outcome is hybrid facilities: some racks running ASICs, some running GPUs, with the allocation shifting dynamically based on relative profitability. Bitcoin miners become energy-monetization platforms rather than single-purpose hashing operations.

Part IX: The Environmental Debate

Bitcoin mining’s energy consumption is one of the most polarized topics in the space. The annual energy consumption of the Bitcoin network is estimated at 150–200 TWh (terawatt-hours) as of early 2026 — comparable to the energy consumption of a mid-sized country like Poland or Argentina. Both sides of the debate have legitimate points.

The Case Against Bitcoin Mining’s Energy Use

1. Absolute consumption is enormous: 150+ TWh per year is a lot of energy by any measure. Even if it’s “only” 0.1% of global energy production, that’s still enough to power tens of millions of homes.

2. Carbon footprint depends on the energy mix: Mining operations that run on coal-fired power (as many Chinese miners did before the 2021 ban, and as some operations in Kazakhstan and parts of the US still do) have a real and significant carbon footprint.

3. The “useful work” question: Unlike AI training, scientific computing, or industrial processes, Bitcoin mining’s computational output has no direct productive use beyond securing the network. Every hash is discarded except the winning one. Critics argue this is wasteful by definition.

4. E-waste: ASICs have a useful life of 3–5 years before being replaced by more efficient models. Millions of obsolete miners end up in landfills. They contain valuable metals but are rarely recycled economically.

The Case For Bitcoin Mining’s Energy Use

1. Energy mix is better than critics claim: The Bitcoin Mining Council (an industry group, so take with appropriate skepticism) estimates that approximately 60% of Bitcoin mining uses sustainable energy sources. Cambridge’s independent estimates are lower (roughly 40–50%) but still substantial. Many mining operations are specifically sited at renewable energy sources.

2. Stranded energy monetization: Bitcoin mining is uniquely suited to consuming energy that would otherwise be wasted:

   • Flared natural gas: Oil wells produce associated gas that is often flared (burned off) because there’s no pipeline to transport it. Companies like Crusoe Energy and Giga Energy place mining containers at wellheads to monetize this gas, converting a waste product into economic value while reducing methane emissions (since the generators burn more completely than open flares).
   • Stranded hydro: Hydroelectric dams in remote areas (especially in Sichuan, Canada, Scandinavia, and Ethiopia) produce more power than the local grid can consume. Mining absorbs the surplus.
   • Curtailed renewables: Wind and solar farms sometimes produce more power than the grid can absorb, leading to curtailment (energy wasted). Mining can absorb curtailed power, improving the economics of renewable projects.

3. Grid stabilization (demand response): Large mining operations can serve as controllable load — ramping down instantly when the grid needs power (during heat waves, cold snaps, or peak demand) and ramping up when there’s surplus. ERCOT (the Texas grid operator) has embraced this model: Bitcoin miners in Texas are significant participants in demand response programs, earning payments for curtailment that supplement their mining revenue.

4. Methane capture: Methane (CH4) is 80x more potent as a greenhouse gas than CO2 over a 20-year period. Mining operations that capture methane from landfills, abandoned coal mines, or agricultural waste — and use it to generate electricity for mining — are converting a potent greenhouse gas into a much less potent one (CO2 from combustion). The net effect is a reduction in warming impact.

5. Subsidizing renewable development: By providing a buyer of last resort for renewable energy, mining improves the financial return of wind, solar, and hydro projects, potentially accelerating their construction. The marginal economics of a solar farm that can sell 100% of its output (including curtailed power, to miners) are better than a solar farm that curtails 15–20% of production.

The Honest Assessment

Both sides are partially right. Bitcoin mining does consume a lot of energy, and some of that energy comes from fossil fuels. But the industry’s energy mix is genuinely improving, the stranded-energy use case is real and growing, and the demand-response model creates genuine value for grid operators.

The strongest argument for Bitcoin mining’s energy use is not environmental — it’s economic: the network secures hundreds of billions of dollars in value, and the energy cost is the mechanism that makes that security trustless. Whether that security is “worth” the energy depends on whether you think a non-sovereign, censorship-resistant monetary network has value. For people living under authoritarian governments, currency controls, or hyperinflation, the answer is unambiguously yes.

Part X: Selfish Mining

The Theory

Selfish mining is a theoretical attack strategy described in a 2013 paper by Ittay Eyal and Emin Gun Sirer (“Majority is Not Enough: Bitcoin Mining is Vulnerable”). The core idea:

A miner who finds a valid block does not immediately broadcast it. Instead, they continue mining on top of their secret block, attempting to build a private chain that is longer than the public chain. If they succeed, they can release their private chain all at once, orphaning the honest miners’ blocks and claiming all the rewards.

How It Works

1. Selfish miner finds block N. Does not broadcast it.
2. Selfish miner immediately starts mining block N+1 on top of their secret block N.
3. Honest network is still mining on block N-1 (the previous public tip).
4. Case A: Honest network finds block N first. Selfish miner immediately releases their block N, creating a race. If the selfish miner’s block propagates faster (because they have good network connectivity), honest miners build on the selfish miner’s chain.
5. Case B: Selfish miner finds block N+1 before the honest network finds block N. Selfish miner now has a 2-block lead. They release both blocks, orphaning any honest block N that was in progress.

The Math

Eyal and Sirer showed that selfish mining is profitable for miners with more than approximately 33% of network hashrate (under certain network propagation assumptions), not the 50% that naive analysis would suggest. With favorable network positioning (high connectivity, low latency), the threshold could be even lower.

The key insight: selfish mining doesn’t require 51% hashrate to be profitable. It requires roughly 25–33% (depending on the attacker’s network connectivity advantage, often parameterized as “gamma” — the fraction of the honest network the attacker can reach first during a block race).

Why It Hasn’t Happened (Probably)

1. The honest mining assumption holds: Miners are economically rational, and selfish mining is risky. If the selfish miner’s private chain is outpaced by the honest chain, they lose all the mining revenue from those blocks — a catastrophic cost for a large operation.

2. Detection: Anomalous orphan rates and suspicious block timing would be detectable by network observers. A selfish miner would be identified relatively quickly, and the social/economic consequences (exclusion from pools, loss of business relationships) could outweigh the gains.

3. No miner has 33% of hashrate: As of 2026, no single mining entity has 33% of network hashrate. Pools control more than that, but the pool itself doesn’t own the hashrate — individual miners do, and they can switch pools. A pool attempting to selfish mine would lose its members overnight.

4. Opportunity cost: The capital required to acquire 33% of hashrate would be in the billions of dollars. The expected return from selfish mining is only marginally better than honest mining. The risk-adjusted return is likely negative when you factor in detection, social costs, and the possibility of protocol-level responses.

Protocol-Level Mitigations

Several defenses have been proposed:

• Uniform tie-breaking: Instead of miners always building on the first block they receive during a race, they randomly choose between competing blocks. This reduces the selfish miner’s advantage from network positioning.
• Timestamp analysis: Detecting blocks with suspiciously old timestamps (suggesting they were withheld).
• Publish-or-perish: Penalizing blocks that arrive significantly after they could have been mined.

None of these have been implemented in Bitcoin Core, largely because the attack hasn’t been observed at scale and the proposed mitigations introduce their own complexity and potential for abuse.

Key Takeaways

1. Mining evolved from CPU to ASIC in four years (2009–2013). Each hardware generation rendered the previous one obsolete within 12–18 months. Satoshi predicted this trajectory before Bitcoin had a single user.

2. Three companies dominate hardware manufacturing: Bitmain (~55% share), MicroBT (~30%), and Auradine (emerging challenger). Modern ASICs hit 200–1,160 TH/s at 9–18 J/TH efficiency. Cooling technology (hydro, immersion) is the key differentiator for top-tier units.

3. Electricity cost is the only variable that matters long-term. Below $0.04/kWh is highly profitable; above $0.10/kWh is marginal at best. The difficulty adjustment ensures that mining profitability always regresses toward the cost of the cheapest available electricity.

4. Pool centralization is real and dangerous. The top 4 pools control ~70% of hashrate. More importantly, pool operators — not individual miners — construct block templates and decide which transactions are included. This is the most underappreciated centralization vector in Bitcoin.

5. Stratum V2 with Job Declaration is the fix. It returns template construction authority to individual miners, making pools into payout coordinators rather than block builders. Adoption is still early (Ocean, Braiins) but the protocol is production-ready.

6. The halving cycle drives hardware obsolescence. Every four years, the block subsidy halves and marginal miners are pushed offline. The fourth halving (April 2024) forced a fleet refresh to sub-20 J/TH hardware.

7. Bitcoin miners are pivoting to AI/HPC. Their existing power infrastructure, cooling capacity, and grid interconnections make mining facilities natural candidates for GPU compute hosting. This is reshaping the public miner landscape (MARA, IREN, Core Scientific).

8. The environmental picture is nuanced. 150+ TWh/year is a lot of energy. But 40–60% is renewable, stranded energy monetization is real, methane capture reduces emissions, and demand response provides genuine grid value. The strongest defense of mining’s energy use is the security model it provides.

9. Selfish mining is a real theoretical vulnerability that is profitable above ~33% of hashrate, but has never been observed in practice due to detection risk, capital requirements, and the absence of any single entity with sufficient hashrate.

10. The endgame is that transaction fees must replace the block subsidy. With each halving, fees become a larger proportion of miner revenue. By the late 2030s, the block subsidy will be negligible. Bitcoin’s long-term security depends on a robust fee market — a topic that connects directly to the block size debate, mempool policy, and the Ordinals/BRC-20 activity that has reinvigorated on-chain fee revenue.

Previous: Chapter 8 — Satoshi’s Timeline and Bitcoin Core History — Who created Bitcoin, who maintains it now, and who actually controls the protocol.

Next: Chapter 11 — The Bitcoin Network — How the P2P layer actually works: node types, block propagation, transaction relay, and why ~20,000 nodes keep Bitcoin decentralized.

Chapter 11: The Bitcoin Network

In Satoshi’s Words

“The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms.”

— Satoshi Nakamoto, BitcoinTalk, July 29, 2010

That prediction is half right and half wrong — and the tension between the two halves defines everything about Bitcoin’s peer-to-peer layer.

Satoshi was right that running a node would become harder over time. The blockchain is over 700 GB in 2026. Initial block download takes hours to days on consumer hardware. Bandwidth requirements are nontrivial. Most Bitcoin users don’t run nodes — they use wallets that connect to someone else’s infrastructure.

But Satoshi was wrong about the “server farm” endgame. As of early 2026, roughly 20,000 reachable full nodes operate globally, and an estimated 60,000+ total nodes exist when you count Tor, I2P, and non-listening nodes behind NATs. Many of these run on consumer hardware — Raspberry Pis, old laptops, $200 mini PCs. The community has fought hard — through pruning, compact blocks, assumeUTXO, and relentless optimization — to keep node operation within reach of ordinary people.

This chapter covers the layer that makes all of that possible: the peer-to-peer network. It’s the layer most people skip, but it’s the layer that makes everything else — consensus, mining, transaction relay, chain validation — actually work in a decentralized system with no central server.

Part I: Node Types

Not all nodes are created equal. The Bitcoin network is a heterogeneous mix of nodes with different capabilities, different storage requirements, and different trust models. Understanding what each type can and cannot verify is fundamental.

Full Node (Archival)

The gold standard. A full archival node:

• Downloads and stores every block since the genesis block (January 3, 2009)
• Validates every transaction in every block against the consensus rules
• Maintains the complete UTXO set (the set of all unspent transaction outputs)
• Can serve historical blocks to peers who request them
• Can independently verify any transaction in Bitcoin’s history

Storage requirement: ~600+ GB as of early 2026, growing at roughly 50-80 GB per year.

What it can verify: everything. A full archival node trusts no one. It has independently validated every signature, every script, every block header, every difficulty adjustment, and every coinbase reward from block 0 to the present. If you run one, you have mathematically proven to yourself that the chain you’re following is valid.

# Check your node's blockchain info
bitcoin-cli getblockchaininfo
# Look at: "blocks", "headers", "size_on_disk", "pruned"

Pruned Node

A pruned node does everything a full node does — with one difference: after validating old blocks, it discards the raw block data to save disk space. It retains only:

• The complete UTXO set (required to validate new transactions)
• Recent blocks (configurable; minimum is 550 MB of block data)
• All block headers (80 bytes each — trivial storage)

Storage requirement: As low as ~7-10 GB with aggressive pruning settings.

What it can verify: Everything a full node can verify — it validates every block during initial sync. The catch is that after pruning, it cannot serve old blocks to peers. If someone asks for block 100,000, a pruned node can’t deliver it. This limits the node’s contribution to the network’s data availability but doesn’t limit its own security model.

# Enable pruning (in bitcoin.conf)
# prune=550   # Keep 550 MB of recent block data (minimum allowed)

# Or start with pruning:
bitcoind -prune=1000  # Keep ~1 GB of recent blocks

The critical point: pruned nodes are not less secure than archival nodes for the operator. They validated everything. They just threw away the receipts afterward. The trust model is identical.

SPV / Lightweight Node

SPV stands for Simplified Payment Verification, described by Satoshi in Section 8 of the whitepaper. An SPV node:

• Downloads only block headers (80 bytes per block — the entire header chain since genesis is ~75 MB)
• Verifies the proof-of-work chain (headers link together; difficulty adjustments are correct)
• Uses Bloom filters (BIP 37) or compact block filters (BIP 157/158) to check if specific transactions appear in blocks
• Does not validate transactions or scripts independently

What it can verify: That a transaction is buried under proof-of-work. That’s it. An SPV node cannot verify that a transaction is valid according to consensus rules — only that miners included it in a block. It trusts miners to have validated correctly.

What it cannot verify:

• Whether a transaction’s inputs actually existed and were unspent
• Whether the scripts were satisfied correctly
• Whether the block reward was correct
• Whether any inflation bugs were exploited

SPV is the trust model used by most mobile wallets (Electrum on mobile, BlueWallet in SPV mode, BRD). It’s vastly better than trusting a centralized server, but it’s not trustless. It’s “trust miners and assume honest majority.”

Mining Node

A mining node is a full node (usually archival) plus:

• Block template construction — assembles candidate blocks from mempool transactions, ordered by fee rate
• Stratum protocol support — connects to mining pools or manages ASICs directly
• getblocktemplate — the RPC call that returns a candidate block for miners to hash against

# Get a block template (what a miner would work on)
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'
# Returns: transactions to include, previous block hash, target difficulty, coinbase value

Mining nodes must be full nodes because they need to validate the blocks they produce. A miner who builds on an invalid block wastes energy and risks their block being rejected by the network. The economic incentive to run a full node is strongest for miners — invalid blocks mean lost revenue.

In practice, most individual miners don’t run their own full nodes anymore. They connect to mining pools (Foundry, Antpool, ViaBTC, F2Pool), which operate the full nodes and distribute work to miners via the Stratum protocol. The centralization risk here is real: a pool operator who validates incorrectly can cause all their connected miners to waste work.

Archival Node with Transaction Index

A full archival node with -txindex=1 enabled maintains an additional index that maps every transaction ID to its location on disk. Without txindex, a node can only look up transactions that are in the UTXO set (unspent) or in recent blocks. With txindex, you can query any transaction in Bitcoin’s history by its txid.

# Requires txindex=1 in bitcoin.conf
# Look up any historical transaction by its ID
bitcoin-cli getrawtransaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 2
# This is the first Bitcoin transaction — Satoshi to Hal Finney, block 170

Storage overhead: The txindex adds roughly 30-40 GB on top of the full blockchain. It’s used by block explorers, analytics services, and anyone who needs to look up arbitrary historical transactions.

Summary Table

Part II: Peer Discovery — The Bootstrap Problem

When a brand-new Bitcoin Core node starts for the first time, it faces a cold-start problem: it doesn’t know any peers. It has no IP addresses, no connections, and no way to download blocks. How does it find the network?

DNS Seeds

Bitcoin Core ships with a hardcoded list of DNS seed nodes — domain names that resolve to IP addresses of known, reliable Bitcoin nodes. These are maintained by long-standing community members.

When your node starts, it queries these DNS seeds:

seed.bitcoin.sipa.be          — Pieter Wuille
dnsseed.bluematt.me            — Matt Corallo
dnsseed.bitcoin.dashjr-list-of-p2sh-hierarchical-deterministic-wallets.org — Luke Dashjr
seed.bitcoinstats.com          — Christian Decker
seed.bitcoin.jonasschnelli.ch  — Jonas Schnelli
seed.btc.petertodd.net         — Peter Todd
seed.bitcoin.sprovoost.nl      — Sjors Provoost
dnsseed.emzy.de                — Stephan Oeste
seed.bitcoin.wiz.biz           — Jason Maurice

Each of these domains returns a set of IP addresses for currently-reachable Bitcoin nodes. Your node connects to several of them, requests more peer addresses, and gradually builds up its address book.

Hardcoded Seed Nodes

If DNS resolution fails (censored network, DNS outage), Bitcoin Core falls back to a hardcoded list of seed IP addresses compiled at release time. These are baked into the binary as a last resort. They’re less reliable than DNS seeds (IPs change over time), but they provide a minimum bootstrap capability even in hostile network environments.

The addr and addrv2 Messages

Once connected to at least one peer, your node participates in address gossip. Nodes periodically share the addresses of other nodes they know about:

┌─────────┐    addr/addrv2     ┌─────────┐
│  Node A  │ ───────────────→  │  Node B  │
│          │                   │          │
│ "I know  │                   │ Adds to  │
│ about    │                   │ address  │
│ Node C,  │                   │ book     │
│ Node D"  │                   │          │
└─────────┘                    └─────────┘

The original addr message (v1) only supported IPv4 and IPv6 addresses. addrv2 (BIP 155, implemented in Core 22.0) extended this to support:

• Tor v3 (.onion) addresses (56 characters)
• I2P addresses
• CJDNS addresses
• Any future network protocol with addresses up to 512 bytes

This was essential for privacy-focused node operation. Without addrv2, Tor and I2P nodes couldn’t be discovered through normal gossip.

Anchor Connections

Starting in Bitcoin Core 0.21.0, the node persists its anchor connections — the peers it was connected to at shutdown — and reconnects to them on startup. This provides continuity across restarts and makes it harder for an attacker to isolate the node (see Eclipse Attacks below).

# See your current peers
bitcoin-cli getpeerinfo

# Key fields to examine:
# "addr"        — peer's IP address and port
# "network"     — ipv4, ipv6, onion, i2p, cjdns
# "subver"      — peer's user agent string (e.g., "/Satoshi:27.0.0/")
# "synced_headers" — how many headers they've sent us
# "synced_blocks"  — how many blocks they've sent us
# "connection_type" — inbound, outbound-full-relay, block-relay-only, feeler, addr-fetch

Connection Types

Bitcoin Core distinguishes several connection types, each serving a specific purpose:

• Outbound full-relay (8 by default) — Your node initiates these; they relay both transactions and blocks
• Outbound block-relay-only (2 by default) — Only relay blocks, not transactions; reduces fingerprinting risk
• Inbound (up to 125 by default) — Other nodes connect to you; only if you’re listening (port 8333)
• Feeler connections — Short-lived connections to test if addresses in your address book are reachable
• Addr-fetch connections — One-time connections to seed nodes to populate your address book

The diversity of connection types is deliberate. Block-relay-only connections, for example, exist specifically to make eclipse attacks harder: an attacker who controls all your transaction-relaying peers still can’t isolate you from the block chain if you have independent block-relay-only connections.

Part III: Block Propagation

Block propagation is a race. When a miner finds a valid block, they want the rest of the network to know about it as fast as possible — because every second of delay is a second during which another miner might find a competing block at the same height, causing an orphan race and wasted work.

The Old Way: Full Block Relay

In Bitcoin’s early years, block propagation was simple and slow:

Miner finds block
       │
       ▼
Sends full block (~1-2 MB) to all peers
       │
       ▼
Each peer validates and forwards to their peers
       │
       ▼
Propagation time: 10-40 seconds across the network

This was inefficient because every node in the network already had most of the transactions in the block sitting in their mempool. Sending the full block meant redundantly transmitting data that the receiving node already possessed.

Headers-First Sync (BIP 130)

Introduced in Bitcoin Core 0.10.0, headers-first sync changed how nodes synchronize with the chain. Instead of downloading blocks sequentially and validating as they go, nodes now:

1. Download all block headers first (80 bytes each — fast)
2. Validate the proof-of-work chain (headers contain nonce and difficulty target)
3. Identify the best chain (most cumulative proof-of-work)
4. Request and download blocks in parallel from multiple peers

┌──────────────────────────────────────────────────┐
│              Headers-First Sync                   │
│                                                   │
│  Phase 1: Download headers                        │
│  ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ... ┌──┐              │
│  │H0│→│H1│→│H2│→│H3│→│H4│→...→│Hn│  (~75 MB)    │
│  └──┘ └──┘ └──┘ └──┘ └──┘     └──┘              │
│                                                   │
│  Phase 2: Validate PoW chain                      │
│  (Can we trust that this chain has real work?)     │
│                                                   │
│  Phase 3: Request blocks in parallel              │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐            │
│  │Blk 0 │ │Blk 1 │ │Blk 2 │ │Blk 3 │  ...      │
│  │Peer A│ │Peer B│ │Peer C│ │Peer A│            │
│  └──────┘ └──────┘ └──────┘ └──────┘            │
│                                                   │
│  Phase 4: Validate full blocks, update UTXO set   │
└──────────────────────────────────────────────────┘

This matters enormously for initial block download (IBD). A new node can download headers from the fastest peer, verify the PoW chain in seconds, and then request blocks from multiple peers in parallel — dramatically reducing sync time compared to the old sequential approach.

The sendheaders message (BIP 130) also changed ongoing sync: instead of using inv messages to announce new blocks, peers send headers messages directly, allowing the receiving node to immediately validate the PoW and request the full block.

Compact Blocks (BIP 152)

Compact blocks are the single most impactful optimization to Bitcoin’s block propagation. Proposed by Matt Corallo in BIP 152, implemented in Bitcoin Core 0.13.0 (2016).

The insight: when a new block arrives, the receiving node already has ~99% of the transactions in its mempool. Sending the full block is almost entirely redundant. Instead:

1. The sending node transmits a compact block containing:
   • The block header
   • Short transaction IDs (6 bytes each, derived from txids using SipHash)
   • Any transactions the sender suspects the receiver might not have (called “prefilled transactions” — typically just the coinbase)
2. The receiving node reconstructs the full block from its mempool using the short IDs
3. If any transactions are missing, the receiver sends a getblocktxn request for just those specific transactions
4. The sender responds with a blocktxn message containing the missing transactions

┌─────────────────────────────────────────────────────────┐
│                 Compact Block Flow                       │
│                                                          │
│  Sender                              Receiver            │
│    │                                    │                │
│    │  ── cmpctblock ──────────────→     │                │
│    │     (header + short IDs            │                │
│    │      + prefilled coinbase)         │                │
│    │                                    │                │
│    │                        Reconstruct from mempool     │
│    │                        Missing 2 of 3000 txs?       │
│    │                                    │                │
│    │  ←── getblocktxn ────────────      │                │
│    │      (request 2 missing txs)       │                │
│    │                                    │                │
│    │  ── blocktxn ─────────────────→    │                │
│    │     (2 missing transactions)       │                │
│    │                                    │                │
│    │                        Block fully reconstructed    │
│    │                        Validate and relay           │
└─────────────────────────────────────────────────────────┘

Bandwidth savings: A typical block contains ~3,000 transactions. Sending full: ~1.5 MB. Sending compact: ~15-25 KB (header + short IDs). That’s a ~98-99% reduction in block relay bandwidth.

High-Bandwidth vs Low-Bandwidth Modes

BIP 152 defines two compact block modes:

• High-bandwidth mode: The sender pushes compact blocks immediately upon receiving them, without waiting for the receiver to request them via inv. The receiver tells up to 3 peers to operate in this mode using sendcmpct(1). This minimizes latency at the cost of some redundant data (you might receive the same compact block from multiple high-bandwidth peers).

• Low-bandwidth mode: The sender announces the new block via inv, waits for the receiver to request it with getdata(CMPCT_BLOCK), and then sends the compact block. Lower bandwidth, higher latency.

Most nodes use high-bandwidth mode with their 3 fastest peers and low-bandwidth mode with everyone else. The goal is to minimize the time between “block found” and “block validated” — because in that window, the node is vulnerable to working on a stale chain tip.

FIBRE — Fast Internet Bitcoin Relay Engine

FIBRE was a project by Gregory Maxwell designed for the most latency-sensitive use case: relay between miners. While compact blocks reduced bandwidth, FIBRE attacked latency directly.

FIBRE used forward error correction (FEC) — borrowed from satellite communication — to transmit block data over UDP. The sender encodes the compact block into a stream of FEC-coded packets. Even if some packets are lost, the receiver can reconstruct the full message without retransmission. This eliminated the round-trip delay of requesting missing transactions.

FIBRE was operated as a network of relay nodes on dedicated infrastructure, primarily connecting major mining pools. At its peak, it could relay blocks across the globe in under a second.

The project was eventually deprecated as compact blocks became more efficient and mining pool infrastructure matured. But its contribution to reducing orphan rates — and thus reducing centralization pressure from mining — was significant. The faster blocks propagate, the less advantage large miners have over small ones (because large miners are more likely to be the first to hear about their own blocks).

Part IV: Transaction Relay

Every Bitcoin transaction begins its life as a message gossiped through the peer-to-peer network. The journey from “user broadcasts transaction” to “miner includes it in a block” passes through the transaction relay layer.

The Message Flow

Transaction relay follows a three-step protocol designed to minimize redundant data transmission:

┌─────────┐                    ┌─────────┐
│  Node A  │                   │  Node B  │
│          │                   │          │
│ Has tx   │  ── inv ────→     │ "I have  │
│ abc123   │  (I have txid     │ txid     │
│          │   abc123)         │ abc123?" │
│          │                   │          │
│          │  ←── getdata ──   │ "I don't │
│          │  (send me abc123) │  have it,│
│          │                   │  send it"│
│          │                   │          │
│          │  ── tx ────────→  │ Validates│
│          │  (full tx data)   │ and adds │
│          │                   │ to       │
│          │                   │ mempool  │
└─────────┘                    └─────────┘

1. inv (inventory) — Node A announces “I have transaction with this ID.” This is a 32-byte hash, not the full transaction.
2. getdata — Node B checks its mempool. If it doesn’t already have the transaction, it requests the full data.
3. tx — Node A sends the complete serialized transaction.

This three-step dance prevents redundant transmission. If Node B already has the transaction (because another peer already relayed it), it simply ignores the inv and never requests the data.

Erlay (BIP 330) is a proposed improvement that replaces the inv flood with set reconciliation — nodes periodically compare their mempool contents using sketches (based on Minisketch), only exchanging the differences. This can reduce transaction relay bandwidth by ~40%. It was merged into Bitcoin Core in stages and is expected to be fully enabled in a near-future release.

Mempool Policy vs Consensus Rules

This distinction is critical and widely misunderstood.

Consensus rules define what is valid in a block. If a transaction violates consensus rules, any block containing it is invalid and will be rejected by all full nodes. Consensus rules are enforced universally and changing them requires a soft fork or hard fork.

Mempool policy defines what a node is willing to relay and keep in its mempool. Policy can be stricter than consensus. A node’s mempool is its own business — it can accept or reject whatever it wants.

Examples of policy-only rules (not consensus):

This distinction became politically explosive during the OP_RETURN debate (see Chapter 6). When Bitcoin Core changed the default OP_RETURN relay limit, it changed policy, not consensus. Miners were always free to include larger OP_RETURN outputs; they just wouldn’t propagate through default Core mempools.

The mempool is an economic buffer, not a consensus mechanism. It exists for convenience and fee estimation, not for rule enforcement.

Transaction Packages and Package Relay (BIP 331)

One of Gloria Zhao’s major contributions. The problem: in traditional relay, each transaction is evaluated independently. If Transaction B depends on Transaction A (B spends A’s outputs), and Transaction A has a low fee, nodes might reject A for being below their minimum fee — even if B pays a very high fee that would make the package profitable for miners.

This is especially problematic for Lightning Network channels. When a channel is force-closed, the commitment transaction might have an outdated fee rate. The child transaction (CPFP — Child Pays for Parent) needs to be relayed alongside its parent, or the parent might never propagate.

Package relay (BIP 331) allows nodes to submit and evaluate groups of related transactions as a single unit:

┌────────────────────────────────────────────┐
│          Package Relay                      │
│                                             │
│  Parent tx: 1 sat/vB fee  (too low alone)   │
│       │                                     │
│       ▼                                     │
│  Child tx: 100 sat/vB fee (CPFP)            │
│                                             │
│  Package fee rate: (parent + child fees)    │
│                    / (parent + child vsize) │
│                  = high enough to relay     │
└────────────────────────────────────────────┘

Without package relay, the parent might be rejected before the child ever has a chance to “pay” for it. With package relay, the pair is evaluated together, and the combined fee rate determines acceptance.

This is complemented by TRUC transactions (BIP 431 — Topologically Restricted Until Confirmation), which restrict package topology to prevent pinning attacks. TRUC transactions limit how many unconfirmed children a transaction can have, making fee bumping more predictable.

Fee Filters (BIP 133)

Nodes have limited mempool capacity (default: 300 MB). When the mempool is full, the lowest-fee transactions get evicted. BIP 133 introduced the feefilter message: a node tells its peers “don’t send me transactions below X sat/vB.”

# Check your node's mempool status
bitcoin-cli getmempoolinfo
# "size"         — number of transactions
# "bytes"        — total size in bytes
# "usage"        — memory usage
# "mempoolminfee" — current minimum fee rate to enter mempool
# "minrelaytxfee" — minimum fee rate to relay (static, from config)

When mempool congestion is high, feefilter values go up across the network. Peers stop relaying low-fee transactions to each other because no one has room for them. This is an emergent, distributed fee market operating at the relay layer.

Part V: Network Topology and Eclipse Attacks

What Is an Eclipse Attack?

An eclipse attack isolates a target node from the honest network by controlling all of its inbound and outbound connections. If an attacker succeeds, the victim node sees only the attacker’s version of the blockchain.

┌──────────────────────────────────────────────┐
│               Normal Operation                │
│                                               │
│    ┌──┐   ┌──┐   ┌──┐   ┌──┐   ┌──┐         │
│    │P1│───│P2│───│  │───│P4│───│P5│         │
│    └──┘   └──┘   │  │   └──┘   └──┘         │
│                   │ME│                        │
│    ┌──┐   ┌──┐   │  │   ┌──┐   ┌──┐         │
│    │P6│───│P7│───│  │───│P8│───│P9│         │
│    └──┘   └──┘   └──┘   └──┘   └──┘         │
│                                               │
│  (Connected to diverse, honest peers)         │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│                Eclipse Attack                 │
│                                               │
│    ┌──┐   ┌──┐   ┌──┐   ┌──┐   ┌──┐         │
│    │A1│───│A2│───│  │───│A3│───│A4│         │
│    └──┘   └──┘   │  │   └──┘   └──┘         │
│                   │ME│                        │
│    ┌──┐   ┌──┐   │  │   ┌──┐   ┌──┐         │
│    │A5│───│A6│───│  │───│A7│───│A8│         │
│    └──┘   └──┘   └──┘   └──┘   └──┘         │
│                                               │
│  (ALL connections controlled by attacker)     │
│  Attacker can: feed fake blocks, hide txs,    │
│  double-spend against the victim              │
└──────────────────────────────────────────────┘

What an eclipse attacker can do:

• Double-spend against the victim — show the victim a fake chain while spending the same coins on the real chain
• Delay or hide transactions — the victim never sees certain transactions
• Waste a miner’s hashpower — trick an eclipsed miner into extending a stale chain
• Selfish mining amplification — combine eclipse attacks with selfish mining strategies

Countermeasures in Bitcoin Core

The defense against eclipse attacks is a multi-layered strategy:

1. Diverse peer selection — Bitcoin Core uses a bucketed address table with randomization. Addresses are bucketed by source network group (/16 for IPv4), ensuring connections are drawn from diverse network ranges rather than a single attacker-controlled subnet.

2. Outbound connection priority — Your node initiates 8 outbound full-relay connections and 2 block-relay-only connections. Outbound connections are harder to attack than inbound because the node chooses whom to connect to.

3. Anchor connections — On restart, your node reconnects to the peers it had before shutdown, preventing an attacker from filling all connection slots during the restart window.

4. Block-relay-only connections — These 2 connections don’t relay transactions, making them invisible to transaction-graph analysis. An attacker who monitors transaction relay patterns to identify your connections won’t detect these.

5. Feeler connections — Periodic short-lived connections to random addresses in the address book, testing whether they’re reachable. This keeps the address book fresh and makes it harder for an attacker to fill it with stale addresses.

6. Tor and I2P connections — Running connections over multiple network layers forces an attacker to control infrastructure on all of them simultaneously.

7. Stale tip detection — If your node hasn’t received a new block in an unusually long time, it opens additional outbound connections to check if it’s being eclipsed.

# Check your network connection diversity
bitcoin-cli getnetworkinfo
# "networks" array shows: ipv4, ipv6, onion, i2p, cjdns
# "connections" — total peer count
# "connections_in" — inbound connections
# "connections_out" — outbound connections

Sybil Resistance

Eclipse attacks are a specific form of Sybil attack — where an adversary creates many fake identities to gain disproportionate influence. In Bitcoin’s P2P network, the cost of running many nodes is:

• Hardware/bandwidth for each node
• IP addresses (IPv4 addresses are increasingly scarce and expensive)
• Tor/I2P identities (cheaper, but less effective at eclipsing clearnet nodes)

Bitcoin’s connection limits (8 outbound + 2 block-relay-only = 10 controlled connections out of a potentially large network) mean an attacker needs to control a significant fraction of reachable nodes. With ~20,000 reachable nodes, that’s expensive. But for a state-level attacker with access to a large IP range, it’s not impossible — hence the layered defenses.

Part VI: Privacy in Transaction Relay

Bitcoin transactions are pseudonymous — addresses are not linked to real identities. But the P2P network can leak identity information through timing analysis: if you can observe when a node first broadcasts a transaction, you can infer that the node’s operator likely created that transaction.

This is not a theoretical concern. Chain analysis companies (Chainalysis, Elliptic) and intelligence agencies operate networks of listening nodes specifically to deanonymize transaction origins.

Tor Support

Bitcoin Core has included built-in Tor support since version 0.12.0 (2016). Running Bitcoin over Tor:

• Hides your node’s IP address from peers
• Prevents your ISP from seeing that you’re running a Bitcoin node
• Makes it harder to correlate your node with your real-world identity

# bitcoin.conf settings for Tor
proxy=127.0.0.1:9050          # Route all connections through Tor SOCKS proxy
listen=1                       # Accept incoming connections
bind=127.0.0.1                 # Bind to localhost
onion=127.0.0.1:9050          # Use Tor for .onion connections

# Or for a Tor-only node (no clearnet at all):
onlynet=onion
proxy=127.0.0.1:9050

Bitcoin Core can also create a Tor hidden service automatically, giving your node a .onion address that other Tor-enabled nodes can connect to. This allows inbound connections without exposing your IP.

I2P Support

Added in Bitcoin Core 22.0 (2021), I2P (Invisible Internet Project) is an alternative anonymity network. Unlike Tor, which is designed for accessing the regular internet anonymously, I2P is designed as a self-contained darknet — optimized for services hosted within the I2P network itself.

# bitcoin.conf settings for I2P
i2psam=127.0.0.1:7656         # Connect to local I2P SAM bridge

Running Bitcoin over both Tor and I2P simultaneously provides defense in depth: if one anonymity network is compromised, the other still protects your connections.

Dandelion++ (BIP Proposal)

Dandelion++ is a transaction relay protocol designed to hide which node originally broadcast a transaction. In standard relay, a node broadcasts its transaction to all peers simultaneously — creating a “fluff” pattern that propagates outward from the source. Timing analysis can trace this pattern back to the origin.

Dandelion++ adds a stem phase before the fluff phase:

┌─────────────────────────────────────────────────────────┐
│              Dandelion++ Protocol                        │
│                                                          │
│  STEM PHASE (private):                                   │
│  Tx passes through a random chain of nodes               │
│  Each node forwards to exactly ONE random peer            │
│                                                          │
│  [Origin] → [Node A] → [Node B] → [Node C]              │
│                                         │                │
│                                         ▼                │
│  FLUFF PHASE (public):                                   │
│  Node C broadcasts normally to all its peers              │
│                                                          │
│  Observers see Node C as the apparent origin,             │
│  not the actual origin                                    │
│                                                          │
└─────────────────────────────────────────────────────────┘

During the stem phase, the transaction is forwarded through a random chain of nodes, each passing it to exactly one peer. After a random number of hops (determined probabilistically), the transaction enters the fluff phase and is broadcast normally. Network observers see the fluff origin (Node C) as the apparent broadcaster — but the real origin could be any node in the stem.

Dandelion++ has been implemented in some altcoins (Zcash, Grin) but has not yet been merged into Bitcoin Core. It remains a BIP proposal with ongoing discussion about implementation complexity and interaction with other relay optimizations. Some privacy-focused Bitcoin node implementations (like Bitcoin Knots) have experimented with it.

Why Transaction Origin Privacy Matters

A concrete scenario: you live in a country where Bitcoin is restricted or surveilled. You broadcast a transaction from your home node. A government-operated listening node observes that your IP address was the first to relay that transaction. Now your IP is linked to that transaction — and potentially to your real identity.

Even in jurisdictions where Bitcoin is legal, origin-IP data combined with blockchain analysis can:

• Link pseudonymous addresses to real identities
• Reveal spending patterns (timing, amounts, destinations)
• Enable targeted phishing or physical attacks (“$5 wrench attacks”)

Running over Tor/I2P, using Dandelion++ (when available), and connecting through diverse network paths are all defenses against this surveillance vector.

Part VII: AssumeUTXO

The Sync Time Problem

Syncing a new Bitcoin full node from scratch — initial block download (IBD) — means downloading and validating every block since January 3, 2009. On consumer hardware, this takes 6-24 hours depending on CPU, disk speed, and bandwidth. That’s a significant barrier to running a full node.

The AssumeUTXO Solution (Bitcoin Core 28.0+)

AssumeUTXO lets a new node start validating immediately by loading a UTXO snapshot — a serialized copy of the UTXO set at a specific block height. The node:

1. Downloads the UTXO snapshot (a few GB, much smaller than the full blockchain)
2. Verifies the snapshot’s hash matches a value hardcoded in the Bitcoin Core binary
3. Begins validating new blocks from the snapshot height — immediately usable
4. In the background, downloads and validates all historical blocks from genesis to the snapshot height
5. When background validation completes, verifies that the UTXO set it computed matches the snapshot

┌───────────────────────────────────────────────────────────┐
│                   AssumeUTXO Flow                          │
│                                                            │
│  Step 1: Load snapshot (block 840,000)                     │
│  ┌──────────────────────────────────┐                      │
│  │  UTXO Set @ block 840,000        │  Verify hash         │
│  │  ~170M UTXOs, ~7 GB              │  matches hardcoded   │
│  └──────────────────────────────────┘  value                │
│                                                            │
│  Step 2: Start validating from block 840,001               │
│  ┌──────────────────────────────────────────────────┐      │
│  │  840,001 → 840,002 → ... → current tip           │      │
│  │  (Node is USABLE — can verify new transactions)   │      │
│  └──────────────────────────────────────────────────┘      │
│                                                            │
│  Step 3: Background validation (IBD in background)         │
│  ┌──────────────────────────────────────────────────┐      │
│  │  Block 0 → Block 1 → ... → Block 840,000         │      │
│  │  (Validates full history; proves snapshot honest)  │      │
│  └──────────────────────────────────────────────────┘      │
│                                                            │
│  Step 4: Compare — computed UTXO set == snapshot?          │
│  If yes: full validation complete, trustless from genesis   │
│  If no: snapshot was dishonest, node rejects it            │
└───────────────────────────────────────────────────────────┘

How It Differs from Trusting a Checkpoint

This is the key question. “Isn’t AssumeUTXO just trusting a checkpoint?”

No, and here’s why:

• A checkpoint says “this block hash is valid — don’t bother checking anything before it.” It permanently skips validation. If the checkpoint is wrong, the node is permanently wrong.
• AssumeUTXO says “assume this UTXO set is valid for now — but verify it in the background.” The node eventually validates everything from genesis. If the snapshot was dishonest, background validation will detect the mismatch and the node will reject it.

The trust model during background validation is temporarily weaker — you’re trusting the hardcoded hash for the first few hours/days until background sync completes. But the hash is hardcoded in the same binary you’re already trusting to validate blocks correctly. And the trust is time-bounded: once background validation finishes, you’re fully trustless.

# Load a UTXO snapshot (Bitcoin Core 28.0+)
bitcoin-cli loadtxoutset /path/to/utxo-snapshot.dat

# Check background validation progress
bitcoin-cli getblockchaininfo
# "background_validation" field shows sync progress

Practical Impact

AssumeUTXO reduces the time from “install Bitcoin Core” to “usable full node” from hours to minutes. The node can validate incoming transactions, check balances, and participate in relay almost immediately. Background validation catches up over the next several hours without blocking the user.

This directly addresses Satoshi’s concern about the burden of running a node. If syncing takes 20 minutes instead of 20 hours, more people will run nodes.

Part VIII: Compact Block Filters (BIP 157/158)

The SPV Privacy Problem

Satoshi’s original SPV design used Bloom filters (BIP 37) for lightweight clients. The idea: a light client sends a Bloom filter to a full node, specifying which addresses/scripts it cares about. The full node applies the filter to each block and returns only the matching transactions.

The problem: Bloom filters leak privacy catastrophically. The filter reveals which addresses the client is interested in. A malicious full node can analyze the filter to determine exactly which addresses the client holds. Worse, the client has no way to verify that the server is returning all relevant transactions — the server could lie by omission.

Neutrino: Client-Side Filtering

Compact block filters (BIP 157/158), also known as the Neutrino protocol, flip the model:

1. The full node computes a compact filter for each block — a deterministic summary of all the scripts/addresses in that block
2. The light client downloads these filters (small — roughly 20 KB per filter for GCS filters)
3. The client checks each filter locally to see if it matches any of its own addresses
4. If a filter matches, the client downloads the full block and extracts its transactions

┌─────────────────────────────────────────────────────────┐
│           Bloom Filter (BIP 37) — OLD WAY                │
│                                                          │
│  Light client → sends filter to server                   │
│  Server → applies filter, returns matching txs           │
│                                                          │
│  PROBLEMS:                                               │
│  • Server sees your filter → knows your addresses        │
│  • Server can lie by omission (hide transactions)        │
│  • Server can DoS you by returning false positives       │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│        Compact Block Filters (BIP 157/158) — NEW WAY     │
│                                                          │
│  Full node → computes filter for each block              │
│  Light client → downloads filters                        │
│  Light client → checks filters locally (private!)        │
│  If match → downloads full block from ANY peer           │
│                                                          │
│  ADVANTAGES:                                             │
│  • Server never learns what addresses you care about     │
│  • Client can verify filter against full block           │
│  • Client downloads full blocks — can verify txs         │
└─────────────────────────────────────────────────────────┘

Why This Matters for Lightning

The Neutrino protocol is the default light client backend for LND (Lightning Labs’ Lightning Network implementation). Lightning wallets need to monitor the blockchain for:

• Channel open/close transactions
• Breach remediation (justice transactions if a counterparty tries to cheat)
• HTLC timeout transactions

Using Bloom filters for this would leak which channels you have open. Compact block filters keep that information private while still allowing the wallet to react quickly to on-chain events.

Filter Types

BIP 158 defines the basic filter type, which covers all scriptPubKeys (output scripts) and all scripts being spent in each block. This is sufficient for wallet operations. The filter uses a Golomb-Rice Coded Set (GCS) — a space-efficient probabilistic data structure similar to a Bloom filter but deterministic and more compact.

# Get a compact block filter (if your node serves them)
# Requires blockfilterindex=1 in bitcoin.conf
bitcoin-cli getblockfilter "000000000000000000024bead8df69990852c202db0e0097c1a12ea637d7e96d"
# Returns: {"filter": "<hex>", "header": "<hex>"}

Part IX: Current Network Statistics

Reachable Nodes

As of early 2026, according to Bitnodes and similar monitoring services:

The “reachable” count only captures nodes that accept inbound connections on port 8333 (or equivalent for Tor/I2P). Many node operators run behind NATs or firewalls and don’t accept inbound connections. These nodes are fully functional for their operators but invisible to network crawlers.

Geographic Distribution

Bitcoin node distribution is heavily concentrated in wealthy, internet-connected countries:

This geographic concentration is a real centralization concern. If a single jurisdiction’s government ordered ISPs to block Bitcoin P2P traffic (port 8333), a significant portion of the network’s connectivity would be disrupted. Tor and I2P provide some mitigation, but a coordinated multi-country crackdown could meaningfully impact the network.

Network Protocol Breakdown

# Check your node's network breakdown
bitcoin-cli getnetworkinfo

Typical output includes:

Software Versions

The network runs a mix of Bitcoin Core versions and alternative implementations:

• Bitcoin Core 27.x-28.x — The large majority of nodes
• Bitcoin Core 25.x-26.x — Older but still common
• Bitcoin Core <25.0 — Outdated; lacks recent security fixes
• Bitcoin Knots — Luke Dashjr’s fork with stricter policy defaults (see Chapter 6)
• btcd — Go implementation (Decred team, used by LND for some functions)
• libbitcoin — Alternative C++ implementation
• Bitcoin Unlimited, Bitcoin Classic — Legacy big-block forks; nearly extinct on the network

The dominance of Bitcoin Core is itself a centralization concern — a critical bug in Core could affect the vast majority of nodes simultaneously. Alternative implementations provide some resilience, but in practice, Core’s review process and test coverage make it the safest option by a wide margin. The mono-culture risk is real but difficult to solve without lowering the quality bar.

Part X: Network Commands and Diagnostics

Bitcoin Core provides extensive RPC commands for inspecting network state. These are essential for diagnosing connectivity issues, verifying peer diversity, and understanding what your node sees.

Essential Commands

# Network overview
bitcoin-cli getnetworkinfo
# Returns: version, subversion, protocol version, connections, networks, relay fee,
#          local addresses, warnings

# Detailed peer information
bitcoin-cli getpeerinfo
# For each peer: addr, services, lastsend, lastrecv, bytessent, bytesrecv,
#                conntime, pingtime, version, subver, inbound/outbound,
#                synced_headers, synced_blocks, minfeefilter

# How many connections of each type
bitcoin-cli getconnectioncount
# Simple integer — total connections

# Add a peer manually
bitcoin-cli addnode "192.168.1.100:8333" "add"

# Disconnect a specific peer
bitcoin-cli disconnectnode "192.168.1.100:8333"

# Ban a misbehaving peer
bitcoin-cli setban "192.168.1.100" "add" 86400  # Ban for 24 hours

# List banned peers
bitcoin-cli listbanned

# Check blockchain sync status
bitcoin-cli getblockchaininfo
# "chain", "blocks", "headers", "verificationprogress", "pruned",
# "size_on_disk", "initialblockdownload"

# Mempool statistics
bitcoin-cli getmempoolinfo
# "size" (tx count), "bytes", "usage", "total_fee",
# "mempoolminfee", "minrelaytxfee"

Diagnosing Common Issues

Node not syncing:

# Check if you're in IBD (Initial Block Download)
bitcoin-cli getblockchaininfo | grep initialblockdownload
# true = still syncing; false = caught up

# Check peer count — if 0, you have no connections
bitcoin-cli getconnectioncount

# Check if network is reachable
bitcoin-cli getnetworkinfo
# Look at "networkactive" — should be true

High orphan rate (for miners):

# Check the chaintips — multiple tips suggest reorgs
bitcoin-cli getchaintips
# "status": "active" = current best chain
# "status": "valid-fork" = valid alternative chain
# "status": "invalid" = invalid chain (rejected)

Peer misbehavior:

# Check for peers with high ban scores
bitcoin-cli getpeerinfo
# Look at "banscore" (deprecated in newer versions, but concept persists)
# Peers that send invalid data get disconnected automatically

The Design Philosophy

The Bitcoin P2P network is not optimized for speed, bandwidth efficiency, or user experience. It is optimized for resilience. Every design decision — the redundant connections, the gossip-based propagation, the lack of a central relay, the support for multiple transport networks — exists to make the system as hard to shut down as possible.

A government can block port 8333. Bitcoin runs on Tor. A government can block Tor. Bitcoin runs on I2P. An ISP can deep-packet-inspect Bitcoin traffic. The v2 transport protocol (BIP 324, implemented in Core 26.0) encrypts peer-to-peer connections, making traffic indistinguishable from random noise.

The network doesn’t need to be fast. It needs to be unkillable. Ten minutes per block is plenty of time for a block to propagate to every node on Earth, even through multiple layers of anonymity networks. The P2P layer is engineered for that design constraint.

Satoshi understood this from the beginning. The decision to use a gossip protocol rather than a centralized relay was not laziness — it was the only architecture compatible with a system that has no administrator, no coordinator, and no authority that can be coerced.

Key Takeaways

1. Full nodes are the security backbone — they validate everything and trust no one. Pruned nodes are equally secure for their operators; they just can’t serve historical data to peers.

2. SPV is not trustless — lightweight clients trust miners to validate correctly. Compact block filters (BIP 157/158) fix SPV’s privacy leak but don’t fix the trust model.

3. Peer discovery bootstraps from DNS seeds and then relies on address gossip (addr/addrv2). Multiple connection types (full-relay, block-relay-only, feeler) provide defense against eclipse attacks.

4. Compact blocks (BIP 152) reduce block relay bandwidth by ~99% — instead of sending full blocks, nodes send short transaction IDs and reconstruct blocks from their mempools.

5. Mempool policy is not consensus — nodes can enforce stricter relay rules than the consensus allows. This distinction matters enormously for protocol politics.

6. Package relay (BIP 331) fixes CPFP propagation — critical infrastructure for Lightning Network fee bumping.

7. Eclipse attacks are the primary P2P threat — Bitcoin Core uses diverse connection types, anchor peers, bucketed address tables, and multi-network support to resist them.

8. Tor and I2P integration protect node operator privacy — hiding your IP address from peers and your ISP. Dandelion++ (not yet in Core) would further hide transaction origin.

9. AssumeUTXO (Core 28.0+) reduces sync time from hours to minutes — load a UTXO snapshot, validate immediately, verify the snapshot in the background. Not a checkpoint — trust is time-bounded and self-verifying.

10. The network is designed for resilience, not speed — gossip propagation, multi-network support, encrypted transport (BIP 324), and no central coordinator make Bitcoin’s P2P layer extremely difficult to disrupt.

Previous: Chapter 10 — Mining & Hardware — From Satoshi’s CPU to 1,160 TH/s hydro-cooled ASICs: the mining arms race and its economics.

Next: Chapter 12 — The Future of Bitcoin — CTV, OP_CAT, covenants, Silent Payments, BitVM, RGB, Ark, and the ossification debate.

Chapter 12: The Future of Bitcoin

In Satoshi’s Words

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.”

— Satoshi Nakamoto, BitcoinTalk, June 17, 2010

And four months later:

“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit”

— Satoshi Nakamoto, BitcoinTalk, October 4, 2010

These two statements are not contradictory. They represent the central tension that defines Bitcoin development in 2025 and beyond: the core design is permanent, but the protocol must evolve within that design. The monetary policy is immutable. The consensus mechanism is settled. The UTXO model is foundational. But the scripting system, the transaction relay logic, the privacy tooling, the Layer 2 infrastructure — these are all active construction sites.

This chapter is about what’s being built and debated right now. Not speculation. Not roadmaps from 2018 that never shipped. The actual state of Bitcoin protocol development as of early 2026.

Part I: The Next Soft Fork — CTV, CSFS, and OP_CAT

The last consensus-level change to Bitcoin was Taproot, activated in November 2021. As of early 2026, over four years have passed without a soft fork. That is both a sign of Bitcoin’s conservatism and an increasingly uncomfortable gap for developers who need new primitives to build better second layers.

Three proposals dominate the conversation. Two of them are being pushed as a package.

CTV (OP_CHECKTEMPLATEVERIFY, BIP 119)

CTV is the longest-running soft fork campaign in Bitcoin’s post-Taproot era. Proposed by Jeremy Rubin in 2019, it does one thing: it allows an output to commit to the exact template of the transaction that spends it. When you create a CTV-encumbered output, you’re saying: “This coin can only be spent by a transaction that looks exactly like this — these outputs, this locktime, this version.”

Technically, CTV replaces OP_NOP4 with a new opcode that takes a 32-byte hash and verifies that the spending transaction matches it. The commitment covers:

• Transaction version
• Locktime
• Number of inputs and outputs
• The outputs themselves (amounts and scriptPubKeys)
• The input’s position in the spending transaction
• Signature scripts hash (if non-null)
• Sequences hash

What this enables:

• Vaults: Pre-commit your coins to a spending path that requires a time delay before final withdrawal. If someone steals your keys, you have a window to claw back funds.
• Congestion control: A single on-chain transaction can commit to a tree of future transactions, batching payouts without requiring all recipients to be online simultaneously.
• Channel factories: Create many Lightning channels from a single on-chain transaction.
• Payment pools: Multiple users share a single UTXO and can exit independently.

Jeremy Rubin spent years pushing CTV through the community. He ran a CTV-specific mailing list, published extensive documentation, organized review sessions, and at one point in 2022 attempted to push toward activation — which was rejected as premature by other developers. Rubin stepped away from active Bitcoin Core development for a period after the pushback. But CTV never died.

In June 2025, James O’Beirne — the author of OP_VAULT (BIP 345) and a longtime CTV supporter — published a letter to the Bitcoin Development Mailing List advocating for final review and activation of CTV alongside CSFS. O’Beirne had been listed as a co-author of CTV at one point, having championed it for over three years, and his vault proposal explicitly depends on CTV as a building block.

By December 2025, pseudonymous developer /dev/fd0 organized a meeting to discuss activation strategy for BIP 119. The tentative plan: a BIP 9-style soft fork activation with conservative parameters, giving the community one year starting January 9, 2026, to signal support. The approach was deliberately slow — no flag days, no ultimatums, no UASF threats. Just miner signaling with ample time.

CSFS (OP_CHECKSIGFROMSTACK, BIP 348)

CSFS is CTV’s companion opcode. Where CTV constrains what a transaction can look like, CSFS enables verifying a signature against arbitrary data — not just the transaction itself.

Normal OP_CHECKSIG verifies a signature against the hash of the spending transaction. CSFS removes that restriction: you push a message, a signature, and a public key onto the stack, and the opcode verifies the signature against the message. Any message.

This sounds abstract. Its implications are concrete:

• Oracle-verified data: A trusted oracle signs a piece of data (a price feed, a sports score, an election result). A Bitcoin script can verify that signature and conditionally release funds. This is the foundation for on-chain DLCs (Discreet Log Contracts).
• Delegation: Sign a message authorizing someone else to spend your coins under specific conditions, without giving them your private key.
• Vaults with recovery: Combined with CTV, CSFS enables vault constructions where a recovery key can override the pre-committed spending path.

CTV + CSFS Together

The combination is more powerful than either opcode alone. Together, they enable:

The political dynamics are worth understanding. CTV has had both passionate supporters and vocal detractors. The detractors fall into two camps: those who think CTV is too limited (they want something more general, like OP_CAT or CCV), and those who think any new opcode is a mistake and Bitcoin should ossify. The June 2025 letter acknowledged both positions and argued that CTV + CSFS hit a pragmatic sweet spot: powerful enough to enable vaults and better L2s, constrained enough to be analyzable and safe.

OP_CAT (BIP 347)

OP_CAT is the wildcard. It does one thing: concatenate two stack elements. Pop two items, push back their concatenation. Maximum result size: 520 bytes. That’s it.

It’s also, arguably, the most powerful proposed opcode change in Bitcoin’s history.

OP_CAT was originally in Bitcoin. Satoshi included it in the initial Script implementation. He removed it in September 2010 as a precaution — large concatenations could create memory-exhaustion attacks. BIP 347, authored by Ethan Heilman and Armin Sabouri in October 2023, proposes re-enabling it within Tapscript only (as a redefinition of OP_SUCCESS126), with the 520-byte limit preventing the original attack vector.

What OP_CAT enables:

The power comes from combining concatenation with OP_CHECKSIG. By constructing a transaction hash piece-by-piece on the stack using CAT, then verifying a signature against it, you can achieve transaction introspection — the script can inspect and constrain arbitrary fields of the spending transaction.

This unlocks:

• Recursive covenants: Outputs that constrain not just the next spend, but the spend after that, and the spend after that — indefinitely. This is something CTV explicitly cannot do.
• STARK verification on Bitcoin: Concatenation enables Merkle proof verification on the stack, which enables verifying zero-knowledge proofs, which enables verifying arbitrary computation.
• Vaults: Different construction than CTV vaults, but achievable.
• On-chain verification of off-chain state: Any system that can produce a Merkle proof can have that proof checked in Bitcoin Script.

The controversy:

OP_CAT’s power is precisely the objection. Recursive covenants could enable things that some Bitcoiners believe Bitcoin “shouldn’t” do:

• Token protocols that are enforced at the consensus level (not just by convention, like Ordinals)
• MEV-like behavior where transaction ordering becomes extractable value
• Complex smart contract interactions that could make Bitcoin Script harder to reason about

The counter-argument: OP_CAT was already in Bitcoin. Satoshi included it. The 520-byte limit constrains the practical attack surface. And the alternative — not enabling these capabilities — forces developers onto less elegant paths (like BitVM’s massive on-chain footprint for dispute resolution).

As of early 2026, OP_CAT is active on Bitcoin’s default signet via Bitcoin Inquisition (the signet fork used for testing proposed consensus changes). Real testing is happening. Bitcoin Inquisition 27.0 began enforcing OP_CAT on signet in 2024, and Inquisition 29.2 (February 2026) continues active testing.

The relationship between CTV and OP_CAT is politically charged. Some developers see them as complementary — activate CTV now for immediate use cases, activate OP_CAT later after more study. Others see them as competitors — if you’re going to do a soft fork, pick the more powerful primitive. Still others want neither, or want a different opcode entirely (like OP_CCV, a more general covenant verification opcode that needs more scrutiny).

Part II: Covenants — The General Concept

All three opcodes above are different approaches to the same idea: covenants. A covenant is a restriction on how a UTXO can be spent in the future. Today, Bitcoin Script can restrict who can spend a coin (via signatures and timelocks). Covenants add the ability to restrict where the coin goes and how it gets there.

Why Covenants Matter

Without covenants, every spending condition in Bitcoin is “checked and forgotten.” Once you satisfy the script (provide a valid signature, wait for a timelock), you can send the coins anywhere. There’s no way for an output to say “these coins must go to address X” or “these coins must be split into exactly three outputs.”

This limitation makes it impossible to build certain things natively:

OP_VAULT (BIP 345)

James O’Beirne’s OP_VAULT proposal is the most targeted covenant design. Rather than adding a general-purpose opcode, it adds two opcodes (OP_VAULT and OP_VAULT_RECOVER) specifically designed for vault use cases.

A vault built with OP_VAULT works like this:

1. You deposit coins into a vault output
2. To spend, you first trigger an unvaulting process, specifying the destination
3. A time delay begins (e.g., 24 hours)
4. During the delay, you can send the coins to a recovery address (the “clawback”)
5. After the delay, the coins go to the specified destination

This is arguably the single most important self-custody improvement possible for Bitcoin. Hardware wallet compromises, $5 wrench attacks, social engineering — all of these become survivable if you have a 24-hour clawback window.

OP_VAULT requires CTV to function. If CTV activates, OP_VAULT can be built on top of it. This is one of the strongest practical arguments for CTV.

The Philosophical Debate

Should Bitcoin outputs have “memory”? Should the protocol care where coins go after they leave your control?

The ossification camp says no. Bitcoin’s simplicity is its strength. Every new opcode is a new attack surface. Every covenant is a potential for unintended emergent behavior. Bitcoin works. Don’t break it.

The pragmatic camp says Bitcoin’s current Script system is crippled in specific, known ways that prevent building critical infrastructure — particularly vaults and better Layer 2 systems. The question isn’t whether to change Bitcoin, but whether to make careful, conservative changes that unlock specific, well-understood capabilities.

Both camps invoke Satoshi. Both have a point.

Part III: Privacy and Quantum Resistance

Silent Payments (BIP 352)

Silent Payments are the most significant Bitcoin privacy improvement that doesn’t require a soft fork.

The problem: To receive Bitcoin privately, you need a fresh address for every payment. This requires interaction — the receiver must generate and communicate a new address to each sender. For donation pages, tip jars, or any scenario where a static address is published, this is impossible. The result: address reuse, which destroys privacy by linking all payments to the same entity.

The solution: Silent Payments use ECDH (Elliptic Curve Diffie-Hellman) to let senders derive a unique, one-time address from the recipient’s static public key. The sender combines their input keys with the recipient’s scan key to produce a shared secret, then uses that secret to tweak the recipient’s spend key into a unique output address.

The recipient’s published address (starting with sp1...) never appears on-chain. Each payment creates a unique Taproot output that only the recipient can identify by scanning the blockchain and performing the reverse ECDH calculation.

How it works, step by step:

1. Alice publishes her Silent Payment address: a pair of public keys (scan key + spend key)
2. Bob wants to pay Alice. He takes the sum of his input private keys and Alice’s scan key, performs ECDH
3. The shared secret is used to derive a tweak
4. Bob creates an output to Alice’s spend key + tweak. This is a standard-looking Taproot output
5. Alice scans the blockchain. For each transaction, she takes the sum of the sender’s input public keys, performs ECDH with her scan private key, and checks if any output matches
6. If a match is found, Alice can spend it using her spend private key + the derived tweak

The cost: Scanning. Unlike BIP 32 wallets that check the UTXO set for known scriptPubKeys, Silent Payment wallets must scan every transaction and perform ECDH. This is computationally more expensive, though optimizations exist (light client support, Nostr-based notifications).

Deployment status (early 2026):

• BIP 352 merged into the BIPs repository
• Cake Wallet: shipping with Silent Payment support (send and receive)
• Silentium: dedicated Silent Payment wallet
• Nunchuk: added Silent Payment support in early 2026
• Bitcoin Core: PSBT support for Silent Payments under active development (BIP 375 merged for sending)
• Draft BIP for Silent Payment output descriptors published
• Electrum server implementation for testing available

Silent Payments are a wallet-level upgrade. No soft fork needed. No miner signaling. No activation drama. Just better wallet software. This is the category of improvement that can ship without anyone’s permission.

BIP 360: Quantum Resistance (P2QRH / P2MR)

Quantum computers cannot break Bitcoin today. But “today” is the wrong timeframe for a protocol designed to last centuries.

BIP 360, authored by Hunter Beast (MARA senior protocol engineer) and Ethan Heilman (co-author of OP_CAT), with Isabel Foxen Duke joining as co-author, introduces Pay-to-Quantum-Resistant-Hash (P2QRH), now rebranded as Pay-to-Merkle-Root (P2MR).

The threat model:

Bitcoin’s security relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures, both based on the secp256k1 curve. Shor’s algorithm, running on a sufficiently powerful quantum computer, could derive private keys from public keys. Two attack scenarios:

1. Long-exposure attack: Public keys that are permanently visible on-chain (P2PK outputs, reused addresses, Taproot key-path outputs) can be targeted at leisure. As of 2025, over 6 million BTC sit in quantum-exposed addresses.
2. Short-exposure attack: A quantum computer fast enough to derive a private key while a transaction is in the mempool (between broadcast and confirmation). This is much harder but not impossible in the distant future.

How P2MR works:

P2MR operates like Taproot but removes the key-path spend entirely. Instead of committing to a public key (which becomes quantum-vulnerable when revealed), P2MR commits only to the Merkle root of the script tree. Every spend goes through the script path. This eliminates long-exposure vulnerability — no public key is ever revealed until the moment of spending.

The proposal is designed as a foundation. Future BIPs can layer in post-quantum signature algorithms — candidates include:

• ML-DSA (Dilithium): Lattice-based, NIST-standardized
• SLH-DSA (SPHINCS+): Hash-based, very conservative security assumptions, large signatures
• SQIsign: Isogeny-based, compact signatures but newer and less studied

Current status:

• BIP 360 merged to the BIP repository in 2025
• Active discussion on Delving Bitcoin
• Not yet implemented in Bitcoin Core
• No activation timeline — this is preparatory work

The pragmatic view: We don’t know when quantum computers will threaten secp256k1. IBM, Google, Microsoft, PsiQuantum, and others are investing billions. The US government has mandated phasing out ECDSA cryptography by 2035. Whether the timeline is 5 years or 50, having the BIP written, reviewed, and ready to implement is prudent engineering. Bitcoin’s upgrade process is slow by design — you don’t want to start designing quantum resistance after a quantum computer can steal coins.

Part IV: Protocol Infrastructure

Cluster Mempool (Bitcoin Core 28–30+)

The mempool — the waiting room where unconfirmed transactions sit before being included in blocks — got a fundamental rearchitecture. Cluster Mempool, developed by Suhas Daftuar and Pieter Wuille, was merged into Bitcoin Core on November 25, 2025 (PR #33629), and ships in Bitcoin Core 30.0.

The problem it solves:

Prior to cluster mempool, Bitcoin Core maintained two separate transaction orderings:

1. Ancestor feerate — looking backward from a transaction to its parents, computing the combined feerate of the “ancestor set” (everything you need to confirm to confirm this transaction)
2. Descendant feerate — looking forward to child transactions

These two orderings served different purposes: ancestor feerate for block construction (what should a miner include?), descendant feerate for eviction (what should be dropped when the mempool is full?). The problem: they could disagree. A transaction might be high-priority for inclusion but low-priority for eviction, or vice versa. This created:

• Suboptimal block templates (miners leaving money on the table)
• Inaccurate fee estimation (users overpaying or underpaying)
• Pinning attacks on Layer 2 protocols (attackers exploiting the inconsistency between what gets accepted and what gets mined)

The solution:

Cluster mempool groups related unconfirmed transactions into “clusters” — connected components of parent-child relationships. Each cluster is then subdivided into “chunks” sorted by feerate. All mempool operations — acceptance, eviction, replacement, block building — use the same unified ordering.

This is not a consensus change. It’s a node implementation change. But it has profound effects on Lightning Network reliability (more predictable fee bumping), mining profitability (better block templates), and user experience (more accurate fee estimation).

Part V: Lightning Network Evolution

Lightning is not standing still. Multiple improvements are shipping or in late-stage development.

BOLT 12 / Offers

BOLT 12 introduces “offers” — reusable payment requests that replace the single-use invoices of BOLT 11. An offer is a static string (or QR code) that a payer uses to fetch a fresh invoice from the payee, automatically, without human interaction.

Why this matters: BOLT 11 invoices expire. You can’t put one on a website and leave it. BOLT 12 offers are permanent. A streamer, a merchant, a donation page — any entity that needs to receive Lightning payments — can publish a single offer and receive payments indefinitely. Offers also support:

• Blinded paths: The payee doesn’t reveal their node identity to the payer
• Recurring payments: Subscribe to a service with a single offer
• Refunds: Built-in mechanism for the payee to send money back

Core Lightning shipped full BOLT 12 support in 2024 — the first new BOLT addition since 2017. Adoption is spreading across other implementations. Human-readable Bitcoin addresses (like user@domain.com resolving to a BOLT 12 offer) are gaining traction, improving the payment UX dramatically.

Splicing

Splicing solves one of Lightning’s most persistent UX problems: channel capacity is fixed after creation. If you open a channel with 0.1 BTC and need 0.2 BTC of capacity, you have to close the channel and open a new one — two on-chain transactions, downtime, and fees.

Splicing allows you to:

• Splice in: Add funds to an existing channel without closing it
• Splice out: Remove funds from a channel (sending them on-chain) without closing it

The channel stays live during the splice. The funding transaction is updated on-chain, but the channel never goes offline. Phoenix Wallet (ACINQ) has been the pioneer implementation, and the protocol changes are working their way into the Lightning BOLTs specification.

The deeper implication: with splicing, a Lightning wallet can present a unified balance to the user. No more “on-chain balance” vs. “Lightning balance.” Funds move seamlessly between the two layers as needed, with the user seeing a single number.

Taproot Channels

Taproot channels use P2TR (Pay-to-Taproot) outputs for the channel funding transaction instead of P2WSH. The benefits:

• Privacy: Cooperative closes look like ordinary single-sig Taproot spends — indistinguishable from normal transactions on-chain
• Efficiency: Schnorr signature aggregation reduces the on-chain footprint
• Future-proofing: Taproot’s script tree enables more complex channel constructions

LND and other implementations have been rolling out Taproot channel support. This is incremental but meaningful — every Lightning channel that looks like a normal transaction improves the privacy of both Lightning users and non-Lightning users (by increasing the anonymity set).

LN-Symmetry (formerly eltoo)

LN-Symmetry is a proposed simplification of Lightning channel state management. Current Lightning channels use a “penalty” mechanism: if your counterparty broadcasts an old channel state, you can take all their funds. This works but is complex and requires storing every previous channel state.

LN-Symmetry replaces this with a simpler model: any newer state can override any older state. No penalty required. No need to store old states. The latest state always wins.

The catch: LN-Symmetry requires a new sighash flag, SIGHASH_ANYPREVOUT (APO), which is itself a soft fork proposal. Without APO, LN-Symmetry cannot be deployed. This creates a dependency chain: APO soft fork → LN-Symmetry → simpler Lightning channels.

LSPs (Lightning Service Providers)

LSPs are the practical solution to Lightning’s onboarding problem. Opening a Lightning channel requires an on-chain transaction, understanding of liquidity, and technical knowledge. LSPs abstract this away:

• They open channels to new users (providing inbound liquidity)
• They use Just-in-Time (JIT) channels — creating a channel the moment a payment arrives
• They handle routing, rebalancing, and watchtower duties

The tradeoff: LSPs are typically non-custodial (you keep your keys), but they can see your payment metadata. This is better than custodial Lightning wallets (where someone else holds your keys) but worse than running your own node.

Greenlight managed over 200,000 nodes by end of 2024 (20x growth). Voltage powers enterprise Lightning for BitGo, Unocoin, and Braiins. The LSP ecosystem is maturing rapidly.

Lightning Agent Tools (February 2026)

On February 11, 2026, Lightning Labs released lightning-agent-tools — an open-source toolkit that gives AI agents the ability to send and receive Bitcoin payments over Lightning autonomously. No API keys. No signup. No identity.

The toolkit uses the L402 protocol (built on HTTP’s 402 “Payment Required” status code). A website sends a Lightning invoice to an AI agent; the agent pays it; the agent receives a cryptographic receipt (a macaroon) that grants access to the resource.

Seven composable skills ship with the toolkit:

1. Running a Lightning node
2. Isolating private keys with a remote signer
3. Baking scoped credentials (macaroons with spending limits)
4. Paying for L402-gated APIs
5. Hosting paid endpoints
6. Querying node state via MCP (Model Context Protocol)
7. Orchestrating buyer/seller workflows

This is significant because it identifies a use case that only Lightning can serve. Credit cards require identity. Bank transfers require KYC. PayPal requires an email. Lightning requires none of these. For autonomous software agents that need to pay for API calls, compute, or data — Lightning is the only payment rail that works without human-in-the-loop authentication.

The toolkit works with any agent framework that can execute shell commands, including Claude Code and Codex.

Part VI: BitVM — Computation Without a Soft Fork

BitVM is Robin Linus’s answer to the question: “Can Bitcoin verify arbitrary computation without changing the protocol?”

The answer, published in his October 2023 paper “BitVM: Compute Anything on Bitcoin,” is yes — with caveats.

How BitVM Works

BitVM uses an optimistic verification model (similar to optimistic rollups on Ethereum):

1. A Prover claims to have executed a computation correctly
2. A Verifier can challenge the claim
3. If challenged, the computation is bisected on-chain until a single gate-level operation is identified
4. Bitcoin Script verifies that single operation
5. If the Prover lied, they lose their collateral

The key insight: Bitcoin doesn’t need to execute the computation. It only needs to verify a single step if there’s a dispute. Since any computation can be decomposed into binary gate operations, and Bitcoin Script can verify individual gates, Bitcoin can act as the final arbiter for any computation.

BitVM2 (the optimized version, with a peer-reviewed paper presented at the Science of Blockchain Conference at Berkeley) dramatically reduced the on-chain footprint. Where BitVM required hundreds of on-chain transactions for dispute resolution, BitVM2 reduces this to a handful. On June 3, 2025, the full unhappy path was validated on Bitcoin mainnet — Claim, Challenge, Assert, Disprove — confirming in 42 blocks (about 7 hours) at a total cost of approximately 14.9 million sats (~$16,000 at the time). This path is unlikely in practice, since honest operators avoid losing collateral.

BitVM Bridge

The most immediate application: trustless Bitcoin bridges. The BitVM Bridge allows BTC to move between Bitcoin and other chains without relying on a federation or multisig committee.

How it differs from existing bridges:

With a BitVM Bridge, any single honest verifier can prevent theft by executing a challenge. You don’t need to trust a majority — you only need one honest participant. This is a fundamentally different security model.

Mainnet status: Bitlayer launched its BitVM Bridge mainnet beta in 2025 as the first functional application of the BitVM paradigm. Citrea, the first ZK rollup using BitVM for proof verification, went live on mainnet in early 2026. The BitVM Alliance — including Alpen, Babylon, Bitlayer, BOB, Citrea, Element, Fiamma, GOAT Network, and ZeroSync — coordinates development.

BitVM is funded as open-source software under the ZeroSync nonprofit, with grants from Spiral, StarkWare, OpenSats, Fedi, and community contributions. Robin Linus is now a PhD student at Stanford, focusing on Bitcoin scalability, privacy, and usability.

Part VII: RGB + Tether on Bitcoin

RGB Protocol

RGB is a system for client-side validated smart contracts on Bitcoin and Lightning. Unlike Inscriptions or BRC-20 tokens (which store data on-chain), RGB keeps all state off-chain. The blockchain is used only for commitments — cryptographic anchors that prove the off-chain state existed at a specific point in time.

How RGB works:

1. Contract state is stored by the participants (client-side)
2. State transitions are validated by each participant independently
3. A hash of the state transition is committed to a Bitcoin transaction (using an OP_RETURN or Taproot tweak)
4. The blockchain proves ordering and prevents double-spends
5. Lightning compatibility: RGB state can be transferred over Lightning channels

This is fundamentally different from the Ordinals/Inscriptions approach. RGB doesn’t bloat the blockchain. It doesn’t require full nodes to store or validate token data. It uses Bitcoin as a timestamping and anti-double-spend layer, nothing more.

The LNP/BP Standards Association maintains the RGB specification.

Tether on RGB

On August 28, 2025, Tether announced the launch of USDT on RGB. This is the largest stablecoin (over $167 billion in circulation) running natively on Bitcoin’s actual protocol layer.

Paolo Ardoino (Tether CEO): “Bitcoin deserves a stablecoin that feels truly native — lightweight, private, and scalable.”

Why this matters:

• USDT on RGB is private by default (client-side validation means transaction details aren’t on-chain)
• It works over Lightning (near-instant settlement, negligible fees)
• It doesn’t bloat the blockchain
• Users can hold BTC and USDT in the same wallet

This is distinct from USDT on the Lightning Network via Taproot Assets (announced earlier, using Lightning Labs’ protocol). RGB and Taproot Assets are competing approaches to the same goal: assets on Bitcoin. RGB is the older specification with a more conservative, standards-body-driven development process.

Part VIII: Ark — A New Layer 2

Ark is a Layer 2 protocol designed by Burak Keceli to solve a problem that Lightning has never fully addressed: onboarding.

The Lightning Onboarding Problem

To use Lightning, you need a channel. A channel requires an on-chain transaction. At $50 per on-chain transaction (during fee spikes), onboarding a new Lightning user costs real money. And the channel needs inbound liquidity — someone has to commit BTC on the other side. LSPs solve this partially but add complexity and counterparty awareness.

Ark takes a different approach.

How Ark Works

1. An Ark Service Provider (ASP) periodically creates shared on-chain transactions called “rounds”
2. Users receive virtual UTXOs (VTXOs) — shares in the shared UTXO, backed by a tree of pre-signed off-chain transactions
3. Payments within Ark are transfers of VTXOs: the sender’s VTXO is consumed, the recipient gets a new one
4. Any user can unilaterally exit at any time by broadcasting their branch of the pre-signed transaction tree. No ASP cooperation needed.
5. VTXOs expire (currently ~4 weeks) and must be refreshed by participating in a new round

The user experience is closer to on-chain Bitcoin than Lightning: you have UTXOs (virtual ones), you make payments by consuming and creating them, and you can exit to the chain whenever you want.

Trust Model

Out-of-round transfers are instant but require trusting that the sender and ASP don’t collude to double-spend. In-round transfers are trustless but take a few seconds. Users can designate multiple delegates for VTXO refresh, shifting the liveness requirement to a 1-of-N assumption.

CTV Dependency

Ark currently operates in a trust-minimized mode. With CTV, the protocol becomes more fully trustless — CTV can enforce the structure of the VTXO trees at the consensus level, removing some of the interactive signing requirements. This is another strong argument for CTV activation.

Two implementations are in active development:

• Second (second.tech)
• Arkade (arkadeos.com)

Ark complements Lightning; it doesn’t replace it. Ark users can send and receive Lightning payments through Lightning Gateways, which atomically swap VTXOs for Lightning payments.

Part IX: The Ossification Debate

Is Bitcoin “done”?

This is the deepest philosophical question in Bitcoin development, and there is no consensus answer. Both sides argue from first principles, and both have historically been correct about different things.

The Case for Ossification

1. Stability is the feature: Bitcoin’s value proposition is that it doesn’t change. The rules you agree to today are the rules that exist tomorrow. Every soft fork, no matter how conservative, introduces risk. Taproot introduced Inscriptions — an unintended consequence. CTV could introduce unintended consequences we can’t predict.

2. The Lindy effect: Bitcoin has survived for 17 years with relatively few consensus changes. Each year without a breaking change increases confidence. Stopping changes extends the Lindy clock indefinitely.

3. Attack surface minimization: Every new opcode is new code in the consensus path. New code means new bugs. Consensus bugs in Bitcoin are catastrophic — they can cause chain splits, inflation events, or fund theft.

4. L2 innovation doesn’t require L1 changes: BitVM proves that arbitrary computation is possible without a soft fork. Lightning works today. Build on what exists.

The Case Against Ossification

1. Missing critical features: Bitcoin cannot do vaults today. Self-custody security is stuck at “don’t lose your keys.” Covenants would make self-custody dramatically safer for ordinary users. Denying this upgrade is a policy choice that costs users real money when their keys are compromised.

2. Layer 2 limitations: Lightning requires on-chain transactions for channel opens and closes. Without better L1 primitives (CTV, APO), L2 protocols remain more complex, more interactive, and more expensive than they need to be. The “build on what exists” argument ignores the genuine engineering limitations.

3. Quantum threat: secp256k1 will eventually be broken. The question is when, not if. Having P2MR (BIP 360) reviewed, tested, and ready to deploy is not optional — it’s a survival requirement. Ossification before quantum resistance is reckless.

4. The ossification paradox: If you ossify now, you also ossify the ability to respond to emergencies. A truly ossified Bitcoin cannot be patched. This may be fine in a world without quantum computers and without clever attacks on Script. We don’t live in that world.

Jameson Lopp articulated this well: “I believe that Bitcoin has far greater potential than what we have achieved thus far. I view the Bitcoin blockchain as a cryptographic accumulator for a wide variety of systems that can anchor into it. But we have barely scratched the surface of what is possible.”

The Pragmatic Middle

The actual practice of Bitcoin development already occupies a middle ground: conservative, extremely high consensus bar, with changes only when the benefit clearly outweighs the risk. Taproot took years. CTV has been debated since 2019. No one is shipping fast and breaking things.

Christine Kim (Galaxy Research, BTC Before Light newsletter) captured the reality well in January 2026:

“Based on the recent discourse over these proposals, you might think, ‘Wow, Bitcoin is going to change a ton this year!’ The thing is, it probably won’t. Bitcoin is extremely resistant to change, even in the face of multiple soft fork attempts.”

Development Roadmap (As of Early 2026)

Key Takeaways

1. The next soft fork, whenever it comes, will likely include CTV (BIP 119). It has the broadest developer support, the longest review history, and concrete use cases (vaults, channel factories, congestion control). BIP 9 signaling was proposed to begin January 2026, but activation requires overwhelming consensus — which hasn’t been reached yet.

2. OP_CAT is more powerful but more controversial. It enables recursive covenants, STARK verification, and general computation checks. Whether that power is a feature or a risk is the central debate. Active testing on signet continues.

3. Silent Payments are shipping now without anyone’s permission. BIP 352 is the most important privacy upgrade Bitcoin has received since Taproot, and it’s a wallet-level change. No soft fork drama. Just better software.

4. Cluster Mempool is a quiet revolution. It doesn’t change consensus rules, but it fundamentally improves how nodes handle transactions — better fee estimation, more optimal block building, more predictable RBF and CPFP behavior. It makes Lightning more reliable.

5. BitVM proves that Bitcoin can verify arbitrary computation today. No soft fork required. The tradeoff is on-chain cost for disputes, but the BitVM Bridge provides the first truly trust-minimized Bitcoin bridge (1-of-N honesty assumption).

6. Lightning is maturing into real infrastructure. BOLT 12 offers, splicing, Taproot channels, LSPs, and AI agent tooling are transforming Lightning from a developer toy into a production payments system.

7. Quantum resistance is being prepared, not deployed. BIP 360 (P2MR) lays the groundwork. The timeline for quantum threats is uncertain, but the engineering work must happen before the threat materializes.

8. The ossification debate is healthy. Bitcoin’s resistance to change is a feature, not a bug. But resistance to change is different from inability to change. The protocol must retain the capacity to upgrade when the need is clear and the consensus is overwhelming.

9. Satoshi designed Bitcoin to work without him. He also designed it to evolve. Both quotes at the top of this chapter are true simultaneously. The core design is set in stone. The implementation keeps getting better. That tension is what makes Bitcoin durable.

Previous: Chapter 11 — The Bitcoin Network — How the P2P layer actually works: node types, block propagation, transaction relay, and eclipse attack resistance.

Related: Satoshi’s Words — Every Satoshi quote in this guide, with full context.

Bitcoin Protocol Tools

A collection of Python tools for querying and analyzing a local Bitcoin node. These tools complement the guide — every concept discussed in the chapters can be verified using these scripts against your own node.

Install

pip install bitcoinlib-rpc

Requirements: A fully synced Bitcoin Core or Bitcoin Knots node with server=1 and txindex=1, Python 3.10+.

Source: github.com/Bortlesboat/bitcoinlib-rpc

The Toolkit

Quick Start

pip install bitcoinlib-rpc

# CLI tools (auto-detect node via cookie authentication)
bitcoin-status
bitcoin-mempool
bitcoin-block 939290
bitcoin-tx a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
bitcoin-fees --once
bitcoin-nextblock

Python API

from bitcoinlib_rpc import BitcoinRPC
from bitcoinlib_rpc.mempool import analyze_mempool
from bitcoinlib_rpc.blocks import analyze_block

rpc = BitcoinRPC()  # auto-detects cookie auth

mempool = analyze_mempool(rpc)
print(f"Congestion: {mempool.congestion}")
print(f"Next block min fee: {mempool.next_block_min_fee:.1f} sat/vB")

block = analyze_block(rpc, 939290)
print(f"Mined by: {block.pool_name}")
print(f"Taproot adoption: {block.taproot_pct:.1f}%")

Architecture

All tools share a common RPC client (rpc.py) that handles authentication via Bitcoin’s cookie file. The tools are read-only — they query the node but never send transactions or modify state.

┌─────────────────────┐
│   Your Bitcoin Node  │
│  (Core or Knots)     │
│  server=1, txindex=1 │
└──────────┬──────────┘
           │ JSON-RPC (port 8332)
           │ Cookie authentication
           ▼
┌─────────────────────┐
│      rpc.py          │ ← Shared RPC client
└──────────┬──────────┘
     ┌─────┼─────┬──────────┬──────────┐
     ▼     ▼     ▼          ▼          ▼
  mempool  tx   block    fee_tracker  next_block

Ecosystem

These tools are part of a larger Bitcoin product suite:

• bitcoinlib-rpc — The pip-installable Python library powering these tools (available now)
• bitcoin-mcp — MCP server: 20 tools for AI agents to query your node (available now)
• Bitcoin Fee Observatory — A Streamlit dashboard for fee market analytics (coming soon)

Mempool Analyzer

Snapshot the current mempool: transaction count, total fees, fee rate distribution by bucket, congestion level, and a plain-English summary.

What It Shows

• Total unconfirmed transactions and their combined size
• Fee rate distribution across buckets (1-2, 2-5, 5-10, 10-20, 20-50, 50-100, 100+ sat/vB)
• Minimum fee rate to enter the next block
• Congestion assessment (low/moderate/high/extreme)
• Estimated blocks needed to clear the mempool

Usage

python mempool_analyzer.py

How It Works

1. Calls getrawmempool(true) to get all unconfirmed transactions with metadata
2. Calls getmempoolinfo for aggregate stats
3. Buckets transactions by fee rate (fee / vsize)
4. Estimates next-block entry fee from the top 4M weight units of pending transactions
5. Generates a natural-language summary

Protocol Context

The mempool is Bitcoin’s fee market — a real-time auction for block space. Every full node maintains its own mempool (there is no single “the mempool”), though they converge because transactions propagate across the P2P network.

Fee rates are measured in satoshis per virtual byte (sat/vB). Virtual bytes account for the SegWit weight discount: witness data costs 1 weight unit per byte vs 4 for non-witness data, and vsize = weight / 4. This is why SegWit transactions pay lower fees for the same economic activity — see Chapter 3.

The mempool is the core input to the block template that miners build. Rational miners select the highest-feerate transactions that fit within the 4M weight unit limit. The cluster mempool architecture (Bitcoin Core 28+, see Chapter 12) improves this selection by grouping related transactions.

Transaction Decoder

Decode any Bitcoin transaction into a human-readable analysis: inputs, outputs, script types, fee rate, SegWit savings, and inscription detection.

Usage

python tx_decoder.py <txid>

# Example: decode the genesis coinbase
python tx_decoder.py 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

What It Shows

• Transaction version, size, vsize, weight
• Each input: previous txid, vout, script type
• Each output: value (BTC + sats), script type, address
• Fee in satoshis and fee rate in sat/vB
• SegWit discount percentage (how much the sender saved)
• Whether the transaction contains an Ordinals inscription

How It Works

1. Calls getrawtransaction(txid, 2) to get the fully decoded transaction
2. Parses each input’s scriptSig and witness to identify the script type
3. Parses each output’s scriptPubKey to identify the address type
4. Computes fee = sum(input values) - sum(output values)
5. Scans witness data for the Ordinals inscription marker (ord)

Requires txindex=1 in your bitcoin.conf to decode arbitrary transactions (not just those in your wallet).

Protocol Context

This tool demonstrates the core concepts from Chapter 1 (UTXOs) and Chapter 2 (Script) in action. Every transaction consumes UTXOs (inputs) and creates new ones (outputs). The script types visible in the output show the evolution of Bitcoin’s address formats:

• pubkeyhash = P2PKH (1… addresses, 2009)
• scripthash = P2SH (3… addresses, 2012)
• witness_v0_keyhash = P2WPKH (bc1q…, 2017 SegWit)
• witness_v1_taproot = P2TR (bc1p…, 2021 Taproot)

The inscription detection shows how Ordinals embed data in the witness field using the OP_FALSE OP_IF envelope — see Chapter 5.

Block Analyzer

Analyze any block by height or hash: mining pool identification, SegWit/Taproot adoption percentages, fee distribution, weight utilization, and subsidy vs fee breakdown.

Usage

# By height
python block_analyzer.py 939000

# By hash
python block_analyzer.py 0000000000000000000123abc...

What It Shows

• Block metadata: height, hash, timestamp, size, weight, transaction count
• Mining pool identification (parsed from coinbase text)
• Weight utilization (% of 4M WU limit)
• Subsidy vs fees breakdown (the “security budget” split)
• Transaction type distribution: % SegWit, % Taproot
• Fee rate distribution across transactions in the block
• Top 5 highest-fee transactions

How It Works

1. Resolves height to hash via getblockhash if needed
2. Calls getblock(hash, 2) for the full block with decoded transactions
3. Parses the coinbase transaction’s scriptSig for pool identification strings (matches against known pools: Foundry, AntPool, ViaBTC, F2Pool, etc.)
4. Iterates all transactions, classifying inputs/outputs by script type
5. Computes fee rate for each transaction and builds the distribution

Protocol Context

This tool brings Chapter 10 (Mining) to life. The weight utilization shows how close miners get to the 4M weight unit limit from Chapter 3 (SegWit). The subsidy-vs-fees ratio is the “security budget” question discussed in Chapter 12 — as halvings continue, transaction fees must increasingly fund network security.

Pool identification works because miners include their name in the coinbase transaction’s scriptSig field. This is a convention, not a protocol requirement — miners can put anything in the coinbase (Satoshi famously put a newspaper headline in the genesis block, see Chapter 8).

Fee Tracker

Monitor Bitcoin fee estimates across multiple confirmation targets. Can run as a one-shot snapshot or a continuous polling loop that logs to CSV.

Usage

# One-shot: current fee estimates
python fee_tracker.py --once

# Continuous: poll every 60 seconds, log to CSV
python fee_tracker.py

What It Shows

For each target, displays the estimated fee rate in sat/vB with a plain-English urgency label.

How It Works

1. Calls estimatesmartfee(target, "ECONOMICAL") for each confirmation target
2. Converts the result from BTC/kvB to sat/vB (multiply by 100,000)
3. Calls getmempoolinfo for current mempool size and minimum relay fee
4. In continuous mode, appends a timestamped row to fee_history.csv

Protocol Context

Bitcoin’s fee estimation is one of the hardest problems in the protocol. estimatesmartfee uses historical data about how long transactions at various fee rates took to confirm. It does NOT look at the current mempool — it’s a backward-looking statistical model.

This is why mempool-based fee estimation (looking at what’s currently pending) can sometimes be more accurate for near-term predictions. The Mempool Analyzer provides that complementary view.

The fee market is the long-term security model for Bitcoin. As the block subsidy halves every ~4 years (see Chapter 10), transaction fees must increasingly compensate miners for securing the network. Understanding fee dynamics is understanding Bitcoin’s economic sustainability.

Next Block Predictor

See exactly what a miner would mine right now: the block template with revenue breakdown, weight utilization, fee rate distribution, and the highest-fee transactions.

Usage

python next_block.py

What It Shows

• Next block height
• Total weight utilization (% of 4M WU limit)
• Miner revenue: subsidy (3.125 BTC) + total fees
• Transaction count in the template
• Fee rate distribution (min, median, max, percentiles)
• Top 5 highest-fee transactions with their txids and fee rates

How It Works

1. Calls getblocktemplate({"rules": ["segwit"]}) to get the current candidate block
2. Parses all transactions in the template
3. Computes weight utilization, fee totals, and rate distribution
4. Sorts by fee rate to identify the highest-paying transactions

Protocol Context

The block template is what mining pools distribute to their hashers via the Stratum protocol (see Chapter 10). In the default configuration, the pool’s node constructs the template — this is the block template centralization problem.

Stratum V2’s Job Declaration protocol allows individual miners to construct their own templates, partially decentralizing transaction selection. This tool shows you what YOUR node would include, which may differ from what a pool’s node selects.

The block template is also where the fee market meets reality. The getblocktemplate RPC returns transactions sorted by effective feerate (accounting for parent-child relationships via ancestor feerate in pre-cluster-mempool versions, and chunk feerate in cluster mempool). This is the optimal ordering for miner revenue maximization — see Chapter 12 for how cluster mempool improves this.

Satoshi Nakamoto: Primary Sources Reference

Verbatim quotes from the white paper and Satoshi’s public writings, organized by protocol topic. All quotes are sourced from bitcoin.org/bitcoin.pdf and nakamotoinstitute.org (the Nakamoto Institute’s curated archive of Satoshi’s posts and emails — the canonical reference for researchers).

Satoshi’s BitcoinTalk profile (575 posts, last active December 13, 2010): https://bitcointalk.org/index.php?action=profile;u=3

1. UTXO Model / Transactions / Chain of Ownership

White Paper — Section 2 (Transactions)

“We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.”

Source: Bitcoin white paper, Section 2 “Transactions” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: This is the foundational definition of how value moves in Bitcoin. “Chain of digital signatures” is Satoshi’s own framing — not “chain of ownership of coins” but ownership verified through a cryptographic chain. The UTXO model flows directly from this: a coin IS its history of signatures, not a balance in an account.

White Paper — Section 9 (Combining and Splitting Value)

“Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.”

Source: Bitcoin white paper, Section 9 “Combining and Splitting Value” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: Satoshi explicitly designed multi-input/multi-output transactions from day one. The “at most two outputs” pattern (payment + change) is the original description of what every basic Bitcoin transaction does — and why UTXO dust and change management matter.

P2P Foundation Forum — Introducing Bitcoin (Feb 11, 2009)

“One of the fundamental building blocks for such a system is digital signatures. A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership. It works well to secure ownership, but leaves one big problem unsolved: double-spending.”

Source: P2P Foundation forum post, “Bitcoin open source implementation of P2P currency” February 11, 2009 https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/

Why it matters: Satoshi’s public introduction of Bitcoin to the P2P research community. He leads with the digital signature / chain of ownership explanation before addressing the double-spend problem — showing that the UTXO model was always the conceptual starting point, not an implementation detail.

2. Script System

BitcoinTalk — “Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG”

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender’s conditions are met.”

Source: BitcoinTalk, “Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG” June 17, 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/

Why it matters: This is Satoshi’s clearest explanation of WHY Script exists and why it is stack- based and predicate-oriented. He explicitly chose a generalized scripting approach over hard-coded special cases to keep the design extensible without changing the core protocol. The phrase “set in stone for the rest of its lifetime” is his own framing of Bitcoin’s immutability rationale.

“The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.”

Source: BitcoinTalk, “Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG” June 17, 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/

Why it matters: Satoshi’s own etymology. He chose the word “script” as an accessible label for what is formally a boolean predicate evaluator. This matters for understanding why Bitcoin Script is intentionally not Turing-complete — it evaluates to true or false, full stop.

“The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.”

Source: BitcoinTalk, “Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG” June 17, 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/

Why it matters: Satoshi anticipated multisig, escrow, and smart contract-like constructs from the very start. Taproot and Lightning were not departures from his vision — they were what he was pointing at when he said “explore in the future.”

3. Block Size / Scaling / SPV

White Paper — Section 8 (Simplified Payment Verification)

“It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.”

Source: Bitcoin white paper, Section 8 “Simplified Payment Verification” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: Satoshi built SPV (light clients) into the white paper from the beginning. He explicitly did NOT expect all users to run full nodes. This is the canonical source for the node security model debate.

BitcoinTalk — Scalability and Transaction Rate (July 2010)

“The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate.”

Source: BitcoinTalk, “Re: Scalability and transaction rate” July 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/127/

Why it matters: Satoshi’s explicit prediction that at scale, full nodes would be run by server farms, not ordinary users. He was not describing this as a failure mode — it was his anticipated end state. This quote is central to the block size debate: Satoshi did not assume every participant would run a full node.

BitcoinTalk — [PATCH] increase block size limit (October 2010)

“It can be phased in, like:

if (blocknumber > 115000) maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.

When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.“

Source: BitcoinTalk, “Re: [PATCH] increase block size limit” October 4, 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/233/

Why it matters: Satoshi explicitly described a mechanism to raise the block size limit via a scheduled hard fork — showing he viewed 1MB as a temporary anti-spam measure, not a permanent cap. He also said in the same thread: “We can phase in a change later if we get closer to needing it.” This is the key Satoshi quote in the block size wars.

White Paper — Section 7 (Reclaiming Disk Space)

“A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore’s Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.”

Source: Bitcoin white paper, Section 7 “Reclaiming Disk Space” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: Satoshi’s own scaling analysis. He assumed Moore’s Law would handle growth. His 4.2MB/year figure for headers-only storage shows he was thinking explicitly about long-term node resource requirements from day one.

4. Privacy

White Paper — Section 10 (Privacy) — Full Section

“The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the ‘tape’, is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.“

Source: Bitcoin white paper, Section 10 “Privacy” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: This is the complete Bitcoin privacy model from the white paper. Satoshi’s design was pseudonymous, not anonymous — public keys serve as pseudonyms. He explicitly acknowledged the common-input-ownership heuristic as a known privacy leak. The phrase “additional firewall” for fresh keys per transaction is the origin of Bitcoin’s address reuse guidance.

5. Data in Transactions / Non-Financial Use

BitcoinTalk — “Suggestion: Allow short messages to be sent together with bitcoins?” (October 2010)

“ECDSA can’t encrypt messages, only sign signatures.

It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.

If there’s going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they’re from.“

Source: BitcoinTalk, “Re: Suggestion: Allow short messages to be sent together with bitcoins?” October 23, 2010 https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/239/

Why it matters: Satoshi explicitly opposed storing non-financial data on-chain. He viewed the blockchain as a transaction ledger, not a general-purpose data store. This is the primary canonical Satoshi quote in the Ordinals/inscription debate — he called permanently recorded messages “an accident waiting to happen.”

6. Mining Incentives / Fee Transition

White Paper — Section 6 (Incentive)

“By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.”

Source: Bitcoin white paper, Section 6 “Incentive” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: The gold-mining analogy is Satoshi’s own. He framed block rewards not as “printing money” but as the cost of securing the network (CPU + electricity), analogous to the cost of gold mining. This is the origin of the “digital gold” framing.

“The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.”

Source: Bitcoin white paper, Section 6 “Incentive” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: Satoshi explicitly designed the subsidy-to-fees transition. Bitcoin was never intended to have permanent block rewards — he expected fees to eventually replace subsidies entirely. The phrase “completely inflation free” is his own description of the post-subsidy endgame.

7. Network Security / 51% Attack / Honest Majority

White Paper — Section 6 (Incentive) — 51% Game Theory

“The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.”

Source: Bitcoin white paper, Section 6 “Incentive” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: This is Satoshi’s game-theoretic argument for why a rational 51% attacker would NOT attack. The argument is economic: an attacker with majority hash power earns MORE from honest mining than from attacking, and attacking would destroy the value of their own holdings. This is not a cryptographic guarantee — it is an incentive argument.

White Paper — Abstract

“The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.”

Source: Bitcoin white paper, Abstract (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: The “honest majority” assumption stated in the very first paragraph. Satoshi never claimed Bitcoin was unconditionally secure — he stated a precise security condition. Everything in the white paper’s security model flows from this single assumption.

White Paper — Conclusion (Section 12)

“The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.”

Source: Bitcoin white paper, Section 12 “Conclusion” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: “Vote with their CPU power” — Satoshi’s description of how consensus works. The conclusion is also the source of the “robust in its unstructured simplicity” framing. Note the explicit statement that nodes can leave and rejoin freely — designed for intermittent connectivity.

8. The Genesis Block Message

“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”

Source: Coinbase transaction of Block 0 (the genesis block), mined January 3, 2009 Block hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Why it matters: This message, encoded in the scriptSig of the genesis block’s coinbase transaction, is simultaneously a timestamp proof (the block could not have been mined before this date, as it references that day’s Times headline), a political statement (the banking system bailout was the context for creating Bitcoin), and an aesthetic act. It is the only “message” Satoshi definitively wrote into the blockchain itself.

The hexadecimal encoding in the raw transaction: 5468652054696d65732030332f4a616e2f323030392043... decodes directly to this ASCII string.

The genesis block is unique: its 50 BTC coinbase reward is unspendable by protocol design — there is no prior block for the coinbase to reference.

9. Satoshi’s Last Known Public Communications

Second-to-Last Forum Post — PC World Article on Bitcoin (December 11, 2010)

“It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet’s nest, and the swarm is headed towards us.”

Source: BitcoinTalk, “Re: PC World Article on Bitcoin” December 11, 2010, 11:39:16 PM https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/259/

Why it matters: This was Satoshi’s second-to-last public post. WikiLeaks had just begun accepting Bitcoin donations after being cut off by Visa/Mastercard/PayPal. Satoshi was alarmed that high-profile attention — especially from governments targeting WikiLeaks — would focus scrutiny on Bitcoin before it was mature enough to survive it. The “hornet’s nest” quote is his most widely cited expression of concern about Bitcoin’s political exposure.

Final Public Forum Post — Version 0.3.19 / DoS Limits (December 12, 2010)

“There’s more work to do on DoS, but I’m doing a quick build of what I have so far in case it’s needed, before venturing into more complex ideas. The build for this is version 0.3.19.”

Source: BitcoinTalk, “Added some DoS limits, removed safe mode (0.3.19)” December 12, 2010 (last active: December 13, 2010) https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/260/

Why it matters: This technical release note was Satoshi’s final public post. He did not write a farewell. He simply stopped posting. His last words on the public forum were about software reliability. His BitcoinTalk profile shows last active: December 13, 2010.

Final Known Private Communication — Email to Mike Hearn (April 23, 2011)

“I’ve moved on to other things. It’s in good hands with Gavin and everyone.”

Source: Private email to developer Mike Hearn, April 23, 2011 (Hearn has publicly confirmed and quoted this email)

Why it matters: This is the closest thing to a farewell Satoshi ever sent. When Hearn asked whether Satoshi might return to the project, this was the reply. No dramatics, no manifesto — just a handoff. The phrase “good hands with Gavin” refers to Gavin Andresen, who Satoshi had designated as the lead maintainer. After this email, no further confirmed Satoshi communications have been authenticated.

Note: In March 2014, a message appeared on the P2P Foundation forum from Satoshi’s account stating “I am not Dorian Nakamoto” in response to a Newsweek article. Its authenticity is disputed — the account may have been compromised.

10. White Paper — Key Section Quotes

Abstract (Complete)

“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.”

Source: Bitcoin white paper, Abstract (October 2008) https://bitcoin.org/bitcoin.pdf

Section 5 — Network Steps (Complete)

“The steps to run the network are as follows:

1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.“

Source: Bitcoin white paper, Section 5 “Network” (October 2008) https://bitcoin.org/bitcoin.pdf

Why it matters: This is the simplest complete description of how Bitcoin works. Six steps. No mention of miners, pools, fees, wallets, or addresses — just the raw protocol. Step 5 is particularly important: validity is a prerequisite for acceptance. This is the foundation of the full node’s role.

11. Additional High-Value Quotes

Cryptography Mailing List — Announcing the White Paper (October 31, 2008)

“I’ve been working on a new electronic cash system that’s fully peer-to-peer, with no trusted third party.”

Source: Cryptography Mailing List, “Bitcoin P2P e-cash paper” October 31, 2008, 18:10:00 UTC https://satoshi.nakamotoinstitute.org/emails/cryptography/1/

Why it matters: Bitcoin’s first public announcement. Satoshi’s opening line. The date is Halloween 2008 — two months before the genesis block, two months after the financial crisis Lehman moment. The phrase “no trusted third party” is the core thesis in six words.

P2P Foundation — On the Root Problem with Conventional Currency (February 2009)

“The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve.”

Source: P2P Foundation forum, “Bitcoin open source implementation of P2P currency” February 11, 2009 https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/

Why it matters: Satoshi’s most politically explicit statement. He names monetary debasement, fractional reserve banking, and the trust model as the problems Bitcoin solves. This is the foundational text for understanding Bitcoin as a political/economic project, not just a technical one.

BitcoinTalk — On Lost Coins (June 21, 2010)

“Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone.”

Source: BitcoinTalk, “Re: Dying bitcoins” June 21, 2010, 05:48:26 PM UTC https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/71/

Why it matters: Satoshi’s elegantly concise take on the economic effect of lost coins under a fixed supply. He reframes a perceived flaw (coins being permanently destroyed) as a feature that benefits all remaining holders via mild deflation.

BitcoinTalk — On Bitcoin’s Design History (2010)

“Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn’t resist to keep thinking about it. Much more of the work was designing than coding.”

Source: BitcoinTalk (quoted in “The Quotable Satoshi,” Nakamoto Institute) https://satoshi.nakamotoinstitute.org/quotes/bitcoin-design/

Why it matters: Satoshi worked on Bitcoin’s design for at least two years before the white paper. The ratio of design to coding work (“much more designing than coding”) explains why the protocol had such unusual conceptual coherence at launch.

BitcoinTalk — On the 20-Year Horizon (2010)

“I’m sure that in 20 years there will either be very large transaction volume or no volume.”

Source: BitcoinTalk (quoted in multiple sources, original post 2010) https://bitcointalk.org/index.php?topic=400623.0

Why it matters: Satoshi was not naive about Bitcoin’s prospects. He explicitly acknowledged it could fail entirely. This binary framing — massive adoption or zero — shows he understood Bitcoin needed network effects to survive; there was no stable middle ground.

Source Index

A Note on Authenticity

All quotes in this document are sourced from:

1. The white paper PDF at bitcoin.org (unchanged since publication)
2. The Nakamoto Institute’s archive (nakamotoinstitute.org), which curates Satoshi’s writings from primary sources including the Cryptography Mailing List archives and BitcoinTalk
3. BitcoinTalk forum posts under account satoshi (user ID 3, the first registered user)

Quotes attributed to Satoshi from secondary sources (media articles, Reddit posts) that do not appear in the above primary sources should be treated with skepticism. The Nakamoto Institute archive is the gold standard reference.

The Mike Hearn email (April 2011) is authenticated by Hearn’s public statements but is a private communication — no primary text URL exists.

Bitcoin CLI Command Reference

Quick reference for bitcoin-cli commands useful for exploring the protocol. All commands assume a running node with server=1 and txindex=1.

Setup

# Set up an alias (add to ~/.bashrc)
alias btc='"C:/Program Files/Bitcoin/daemon/bitcoin-cli.exe"'

Node Status

# Quick status overview
btc -getinfo

# Detailed blockchain info
btc getblockchaininfo

# Network connections and version
btc getnetworkinfo

# Connected peers
btc getpeerinfo

Blocks

# Get block hash by height
btc getblockhash 0                    # Genesis block
btc getblockhash 481824               # First SegWit block
btc getblockhash 709632               # First Taproot block

# Get block details (verbosity: 0=hex, 1=JSON, 2=JSON with tx details)
btc getblock <blockhash> 1            # Block header + txid list
btc getblock <blockhash> 2            # Full block with decoded transactions

# Get current block count
btc getblockcount

# Get block header only
btc getblockheader <blockhash>

Transactions

# Decode a transaction (requires txindex=1 for non-wallet txs)
btc getrawtransaction <txid> 2

# Get raw hex (for manual decoding)
btc getrawtransaction <txid> 0

# Decode raw hex without looking up the blockchain
btc decoderawtransaction <hex>

# Decode a script
btc decodescript <hex>

UTXO Set

# UTXO set statistics (takes a moment)
btc gettxoutsetinfo

# Check if a specific output is unspent
btc gettxout <txid> <vout>
# Returns null if spent, JSON if unspent

Mempool

# Mempool overview
btc getmempoolinfo

# List all transactions in mempool
btc getrawmempool

# Detailed mempool entries (with fees, size, time)
btc getrawmempool true

# Get specific mempool entry
btc getmempoolentry <txid>

# Fee estimation (target: blocks until confirmation)
btc estimatesmartfee 1     # Next block
btc estimatesmartfee 6     # Within ~1 hour
btc estimatesmartfee 144   # Within ~1 day

Mining Info

# Current mining/difficulty info
btc getmininginfo

# Current network difficulty
btc getdifficulty

# Get block template (what a miner would build)
btc getblocktemplate '{"rules": ["segwit"]}'

Network

# Peer info
btc getpeerinfo

# Add a peer manually
btc addnode <ip:port> add

# Get network totals (bytes sent/received)
btc getnettotals

# Ban a peer
btc setban <ip> add

Index Status

# Check indexing progress (txindex, blockfilterindex, etc.)
btc getindexinfo

Historic Transactions to Explore

# Genesis block coinbase (the first ever Bitcoin transaction)
btc getblockhash 0
# Then: btc getblock <hash> 2 | look at tx[0]

# The Pizza Transaction (10,000 BTC for two pizzas)
btc getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 2

# First SegWit transaction (block 481824)
btc getblockhash 481824
# Then explore transactions in that block

# First Taproot spend (block 709632)
btc getblockhash 709632

# Hal Finney's transaction (first non-Satoshi transaction, block 170)
btc getblockhash 170

Useful Patterns

# Get the coinbase text from a block (miners often embed messages)
btc getblockhash <height> | xargs btc getblock - 2 | jq -r '.tx[0].vin[0].coinbase' | xxd -r -p

# Count transactions in a block
btc getblock <hash> 1 | jq '.nTx'

# Get all output values from a transaction
btc getrawtransaction <txid> 2 | jq '[.vout[].value] | add'

# Check weight vs size of a transaction
btc getrawtransaction <txid> 2 | jq '{size, vsize, weight}'

# See script types in a transaction's outputs
btc getrawtransaction <txid> 2 | jq '.vout[].scriptPubKey.type'

Tips

• jq is your best friend for parsing JSON output
• Pipe to | less for long outputs
• The 2 in getrawtransaction <txid> 2 means “verbose JSON” (0 = raw hex, 1 = JSON without prevout details)
• getblock <hash> 2 with verbosity 2 includes full transaction details (large output for big blocks)
• Use mempool.space as a visual complement to CLI exploration

The Pizza Transaction

The most expensive pizza in history: 10,000 BTC for two large pizzas.

The Story

On May 22, 2010, Laszlo Hanyecz paid 10,000 BTC to Jeremy Sturdivant (jercos) for two Papa John’s pizzas. This was the first known real-world transaction using Bitcoin as payment. May 22 is now celebrated as “Bitcoin Pizza Day.”

At the time, 10,000 BTC was worth roughly $41. At $100,000/BTC, it would be worth $1 billion.

The Transaction

txid: a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d

View on mempool.space

Summary

What’s Interesting About This Transaction

1. 131 inputs, 1 output — UTXO consolidation

Laszlo was an early miner. He had accumulated hundreds of small UTXOs from mining (many worth just 0.01 BTC — mining dust from early blocks). This transaction consolidates all 131 UTXOs into a single 10,000 BTC output.

This is a perfect illustration of the UTXO model: you can’t partially spend a UTXO, so to make a 10,000 BTC payment you need to gather enough UTXOs to cover it.

2. No change output

The inputs totaled ~10,000.99 BTC and the single output was exactly 10,000 BTC. The ~0.99 BTC difference went entirely to the miner as a fee. This was before fee-awareness was built into wallets.

A modern wallet would create a change output to send the excess back to the sender. See Chapter 1 on change outputs.

3. P2PKH script type

This transaction predates SegWit and Taproot by many years. All scripts are P2PKH (Pay-to-Public-Key-Hash) — the original Bitcoin script type.

Output scriptPubKey:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Recipient address: 17SkEw2md5avVNyYgj6RiXuQKNwkXaxFyQ

4. All inputs from one address

All 131 inputs came from: 1XPTgDRhN8RFnzniWCddobD9iKZatrvH4

This was Laszlo’s mining address. Input values ranged from 0.01 BTC (mining dust) up to 3,753.88 BTC. The large inputs were likely from successful block mining (the block reward was 50 BTC in 2010).

5. The fee was enormous (percentage-wise)

~0.99 BTC as a fee — about 0.01% of the total transaction value. In 2010, fees were essentially irrelevant (blocks were nearly empty), so nobody optimized for them. The wallet simply didn’t create a change output.

Verify It Yourself

# Decode the full transaction
bitcoin-cli getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 2

# Check the output (single P2PKH output, 10,000 BTC)
bitcoin-cli getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 2 | jq '.vout'

# Count the inputs
bitcoin-cli getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 2 | jq '.vin | length'
# Returns: 131

# Check the block it was in
bitcoin-cli getrawtransaction a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 2 | jq '.blockhash'

Protocol Concepts Illustrated

• UTXO consolidation — many inputs → single output
• No change output — excess becomes miner fee
• P2PKH script — the original lock/unlock mechanism
• Implicit fees — no fee field, just inputs minus outputs
• Early mining — many small UTXOs from solo mining

Back to: Examples Index | Chapter 1: UTXO Model

First BRC-20 Token Deploy: ordi

The transaction that launched Bitcoin’s fungible token ecosystem.

The Story

On March 8, 2023, an anonymous developer known as “domo” deployed the first BRC-20 token: ordi. The deploy inscription set a max supply of 21,000,000 (mirroring Bitcoin’s supply cap) with a mint limit of 1,000 per transaction. Within weeks, the entire supply was minted and the token reached a market cap exceeding $1 billion.

The Transaction

txid: b61b0172d95e266c18aea0c624db987e971a5d6d4ebc2aaed85da4642d635735

View on mempool.space

Summary

The Inscription Content

Embedded in the witness via the ordinals envelope:

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "ordi",
  "max": "21000000",
  "lim": "1000"
}

Content-type: text/plain;charset=utf-8

What’s Interesting About This Transaction

1. Taproot script-path spend

Both the input and output are P2TR (Taproot) addresses:

• Input: bc1pt87kqa72x0v2qq3xlxuw0muz94umgqmcmk3eqq06hr8tcasjgppqd5r04w
• Output: bc1pxaneaf3w4d27hl2y93fuft2xk6m4u3wc4rafevc6slgd7f5tq2dqyfgy06

This is the reveal transaction of a commit-reveal pair. The witness contains the script-path data including the inscription envelope.

2. The witness data breakdown

The transaction has 3 witness elements:

Element 0: <signature>                    (64 bytes — Schnorr)
Element 1: <inscription script>           (contains the BRC-20 JSON)
Element 2: <control block>                (33 bytes — internal key + parity)

Element 1 decoded contains:

<internal_pubkey>
OP_CHECKSIG
OP_FALSE
OP_IF
  OP_PUSH3 "ord"
  OP_1
  OP_PUSH "text/plain;charset=utf-8"
  OP_0
  OP_PUSHDATA1 <BRC-20 JSON payload>
OP_ENDIF

3. Tiny transaction, massive impact

The entire transaction is only 362 bytes (644 WU). The inscription content is a 94-byte JSON string. This tiny payload created a token system with billions of dollars in trading volume.

Compare this to the pizza transaction at 23,620 bytes — this is 65× smaller but arguably more consequential for Bitcoin’s ecosystem.

4. The fee was negligible

4,830 sats (~$1.50 at the time). In the weeks following, as BRC-20 mania took hold, inscription fees regularly exceeded 100+ sat/vB as users competed for block space.

5. How BRC-20 actually works (and doesn’t)

The JSON is just data — Bitcoin nodes don’t parse or validate it. BRC-20 balances exist only in off-chain indexers that:

1. Scan every inscription for BRC-20 JSON
2. Validate operations (deploy → mint → transfer)
3. Track balances per address

If an indexer has a bug, BRC-20 balances can disagree between services. This is fundamentally different from Bitcoin’s UTXO model where consensus is enforced by the protocol.

The Witness Hex (Decoded)

Witness element 1 (hex):
209e2849b90a2353691fccedd467215c88eec89a5d0dcf468e6cf37abed344d746
ac                              → OP_CHECKSIG
00                              → OP_FALSE
63                              → OP_IF
036f7264                        → OP_PUSH3 "ord"
01                              → OP_1 (content type tag)
18                              → OP_PUSH24
746578742f706c61696e3b636861727365743d7574662d38
                                → "text/plain;charset=utf-8"
00                              → OP_0 (body tag)
4c5e                            → OP_PUSHDATA1 94 bytes
7b200a2020...                   → BRC-20 JSON payload
68                              → OP_ENDIF

Verify It Yourself

# Decode the full transaction
bitcoin-cli getrawtransaction b61b0172d95e266c18aea0c624db987e971a5d6d4ebc2aaed85da4642d635735 2

# Extract the witness data
bitcoin-cli getrawtransaction b61b0172d95e266c18aea0c624db987e971a5d6d4ebc2aaed85da4642d635735 2 | jq '.vin[0].txinwitness'

# The second witness element contains the inscription script
# Decode the hex to see the BRC-20 JSON
echo "7b200a2020227022..." | xxd -r -p

Protocol Concepts Illustrated

• Taproot script-path — inscription data in the witness via MAST
• Schnorr signature — 64-byte fixed-size sig (element 0)
• OP_FALSE OP_IF envelope — data present but never executed
• Witness discount — 644 WU for 362 bytes (data is cheap in witness)
• Commit-reveal pattern — this is the reveal; commit TX came first
• Off-chain indexing — Bitcoin doesn’t know this is a “token”

Back to: Examples Index | Chapter 5: Ordinals

Large Image Inscription

When the witness discount meets digital art: a 395 KB image that nearly fills a block.

What This Demonstrates

This example illustrates the extreme case of witness data usage. A single inscription can occupy nearly an entire block’s worth of witness space — the scenario that drives the BIP-110 debate.

The Mechanics

How large inscriptions fit in blocks

The block weight limit is 4,000,000 WU. For a large image inscription:

Block weight budget:        4,000,000 WU
─────────────────────────────────────────
Typical block overhead:        ~10,000 WU  (coinbase tx, headers)
Image in witness:             ~395,000 WU  (395 KB × 1 WU/byte)
Transaction non-witness:         ~500 WU  (inputs, outputs × 4)
                              ─────────
Total for inscription:        ~405,500 WU
Remaining for other txs:    ~3,594,500 WU

A 395 KB image consumes roughly 10% of a block’s weight capacity. At the witness discount rate, this costs the same as ~100 KB of non-witness data.

The inscription structure

For a large image, the data is split across multiple pushes (max 520 bytes each):

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_1
  OP_PUSH "image/png"
  OP_0
  OP_PUSH <bytes 0-519>       // chunk 1
  OP_PUSH <bytes 520-1039>    // chunk 2
  OP_PUSH <bytes 1040-1559>   // chunk 3
  ... (760+ pushes for a 395 KB image)
OP_ENDIF
<pubkey>
OP_CHECKSIG

Cost calculation

At 20 sat/vB (moderate fee environment):

Inscription weight:    ~395,500 WU
Virtual size:          ~395,500 / 4 = ~98,875 vB
Fee:                   98,875 × 20 = 1,977,500 sats
                       ≈ 0.0198 BTC
                       ≈ $1,980 at $100K/BTC

Without the SegWit discount, the same image would cost 4× more (~$7,920) because it would count as 395,500 × 4 = 1,582,000 WU.

Why This Is Controversial

The “abuse” argument

Critics call large inscriptions “witness abuse” because:

1. The witness discount was meant for signatures — A typical Schnorr signature is 64 bytes. A 395 KB image is ~6,172 signatures worth of data
2. It displaces financial transactions — Block space used for images can’t be used for payments
3. The data persists forever — Every full node must store this data permanently (unless pruning)

The “legitimate use” counter

Defenders argue:

1. The fee was paid at market rate — No discount beyond what the protocol provides to all witness data
2. Witness data CAN be pruned — Unlike UTXO data, old witness data is only needed for initial validation
3. Block fullness varies — Most blocks aren’t consistently full; inscriptions fill otherwise-empty space
4. The protocol allows it — If the rules permit it, restricting it requires a consensus change (soft fork)

The Numbers in Practice

During peak inscription activity (2023-2024):

Verify It Yourself

# Find a block with a large inscription (look for blocks near 4M weight)
bitcoin-cli getblock <blockhash> 1 | jq '{weight, size, nTx}'

# Decode a large transaction and check its witness size
bitcoin-cli getrawtransaction <large-inscription-txid> 2 | jq '{size, vsize, weight}'

# Compare: weight should be much less than size * 4
# (because witness data dominates and gets the discount)

You can find large inscriptions by browsing ordinals.com or checking block explorers for blocks with unusually high weight-to-transaction-count ratios.

Protocol Concepts Illustrated

• Witness discount economics — 1 WU/byte vs 4 WU/byte makes a 4× cost difference
• Block weight limits — 4M WU constrains total block content
• Data chunking — 520-byte push limit requires splitting large content
• The BIP-110 trigger — large inscriptions are the primary target of the proposal
• Fee market dynamics — inscriptions competing with payments for block space

Back to: Examples Index | Chapter 6: BIP-110 Debate