CHIP-2025-03: Merkle Header Commitment for Enhanced SPV Scalability

Contents

[placeholder, ignore for now]

Summary

This CHIP proposes embedding a Merkle tree commitment of all past block headers in each Bitcoin Cash coinbase transaction.
It enables SPV clients to sync trustlessly with a user-chosen header segment of fixed size (e.g., ~800 kB) instead of downloading the full header chain (~72 MB, March 2025), trusting hard-coded checkpoints, or trusting a server.
This offers scalable and trustless security without external dependencies.

Deployment

TBD after feedback.

Motivation

SPV clients today can download all headers (~72 MB, growing at ~4.2 MB/year) for trustless verification of proof-of-work (PoW) mined on top of some transaction.
Alternatively, they use checkpoint roots hard-coded in the client and server-provided proofs, requiring trust in client developers, or completely skip any checks and simply trust a server.
There is no option in between full header verification and trust.
This CHIP’s root commitment lets clients pick a security level they’re comfortable with and then trustlessly verify a root backed by the chosen level of accumulated proof-of-work (e.g., 10,000 headers, ~800 kB).

Benefits

• Trustless Flexibility: Unlike full header sync (~72 MB) or trusting checkpoints/servers, clients verify a chosen segment (e.g., ~800 kB) against a chain-enforced root—trustless security at any scale.
• Scalable Sync Size: Replaces the growing full chain (~4.2 MB/year) with a fixed-size sync, keeping SPV lightweight as Bitcoin Cash scales.
• No External Dependencies: Eliminates trust in developers or servers by embedding the root in the chain—security stays blockchain-native.
• Future-Proofing: Mitigates header growth (e.g., ~21 MB/year at 2-minute intervals), supporting future scalability without burdening clients.

Technical Description

Block Header Merkle Tree Construction

A binary Merkle tree hashes all block headers (32 bytes each, double SHA-256 of 80-byte headers), ordered by height (0, 1, 2, ...).
Paired leaves hash into parents; unpaired leaves move up as-is.
For 3 blocks: H0 and H1 form H01, H2 moves up, and the root is H01 || H2 hashed.
Miners commit this root in each block’s coinbase via a zero-value OP_RETURN output.

Figure 1: Header Merkle Tree with 3 Blocks (Committed in 4th Block)

Block Header Merkle Tree Updates

New blocks append rightward, so updates recompute only the right-most path, which is log2(height) hashes (e.g., ~20 for 1M blocks).
Nodes caching headers (~72 MB at 1M blocks) add ~72 MB for internal nodes, tiny next to the chain UTXO state (~4 GB as of March 2025).

Figure 2: Updating Header Merkle Tree with a New Block

Specification

1. Merkle Tree:
   • Leaves: H_i = SHA256(SHA256(header_i)).
   • Parents: H_{parent} = SHA256(H_{left} || H_{right}), unpaired promoted as-is.
   • Root: Topmost hash.
2. Coinbase Commitment:
   • Last output: OP_RETURN OP_DATA_32 {32-byte root} (e.g., 6a20{hex}).
3. Validation Rule:
   • Post-activation, the coinbase commits headers 0 to (height - 1).

Security Analysis

This analysis first examines the security of the existing Simplified Payment Verification (SPV) model. Then it sets the stage for comparing it to a proposed model to highlight key differences.

Status Quo SPV Security

Simplified Payment Verification (SPV) offers a lightweight method for verifying transaction inclusion in a blockchain. It’s ideal for users who don’t want to run a full node. SPV clients can connect directly to the peer-to-peer (P2P) network to fetch header chains and relevant transactions. They can query a third-party server. Or they can operate offline, relying on occasional user or admin interaction to sync state. By using block headers instead of the entire blockchain, SPV clients verify transactions efficiently. But this efficiency comes with security trade-offs. Let’s break down what SPV can and can’t verify, how it handles majority and minority forks, and where attackers might exploit its weaknesses.

What SPV Can Verify

With just a chain of block headers, a transaction, and its Merkle path, an SPV client can confirm a few essentials:

• Header Continuity: It checks that each header links to the previous one, forming a valid chain back to the genesis block (where the first block references a "zero" previous hash).
• Transaction Inclusion: Using the Merkle path (the transaction plus sibling nodes up the tree), it computes the Merkle root and verifies it matches the header’s root, confirming the transaction’s inclusion.
• Chainwork Progression: It calculates the cumulative proof-of-work (PoW) by summing the difficulty across headers, tracking the chain’s growth.
• Timestamp Progression: It ensures timestamps in headers increase logically, flagging obvious inconsistencies.
• Difficulty Adjustments: It verifies that difficulty targets in headers adjust as expected.

What SPV Can't Verify

SPV's simplicity leaves gaps that can't be filled without online checks:

• Forgery Risk: Without the full blockchain, an SPV client can’t tell if a header chain is from the real network or an expensive fake crafted by a malicious actor with enough hash power.
• Consensus Rule Changes: It can’t detect if rules (e.g., new opcodes) changed mid-chain, as it doesn’t validate transactions or blocks against the full rule set.
• True Chain Dominance: Has no way to tell whether the presented header chain is the heaviest chainwork chain.
• Complete Header Set: Can't know whether it has all the headers for the blockchain it thinks it’s following.
• Fork Awareness; Can't tell whether the original network has permanently split (hard forked).
• Complete Transaction Set: Can't know whether it has all the transactions of interest (e.g. when requesting all transactions involved with a particular address).

Majority vs. Minority Forks

SPV's limitations become evident during blockchain forks, splits where chains diverge:

• Majority Forks: In a persistent fork (e.g., Bitcoin vs. Bitcoin Cash in 2017), SPV clients follow the majority fork. This is the chain with the most accumulated PoW, as reported by peers. Without intervention, an SPV wallet stuck with BTC because miners backed it overwhelmingly. This aligns with the "heaviest chain" heuristic.
• Minority Forks: For a minority fork, the chain with less PoW (e.g., Bitcoin Cash initially), SPV clients won’t switch unless manually directed. This requires connecting to nodes supporting it or anchoring with a checkpoint (a known block hash). Otherwise, it ignores the minority chain as if it is just an orphaned chain in blockchain reorganization (accidental split).

Temporary forks (e.g., two miners racing to extend the chain) resolve as SPV clients shift to the chain with more work. They assume it’s the winner.

Attack Vectors

SPV's reliance on external data opens it to specific attacks that exploit its lightweight design:

• Forgery Attack: An attacker with significant hash power could craft a fake header chain, tricking an SPV client into accepting invalid transactions or a false recent history. This requires outpacing the legitimate chain's PoW, which is costly but feasible for well-funded adversaries.
• Eclipse Attack: An attacker controlling all peer connections can withhold the winning chain, forcing the SPV client to accept a stale or fake chain. This is especially effective if the client has limited or no external validation sources.

Thanks to proof-of-work mechanism, SPV is NOT vulnerable to Sybil attacks. because one honest peer is enough for the target to learn about a heavier header chain.

CHIP SPV Security

Key distinction is losing direct proof of ancestry, which has nuanced implications on security.

Consider a header chain between 0 and N (current tip) and some block M between. A partial tip segment from M to N proves that transactions in M had (N-M) worth of PoW mined on top of them, indicating that the segment likely comes from a legitimate network. The segment 0 to M directly proves ancestry, but with CHIP's scheme we discard it and replace it with a Merkle root of past headers and record it in M+1, which is a weaker proof because it depends on blocks M+1 to N belonging to a network that actually enforces the consensus rule of committing the correct Merkle root. This makes the system more sensitive to blockchain forks, in multiple ways.

If there are multiple networks with similar blockchain specification then an offline client has no way to tell to which blockchain the segment belongs to. Imagine if Litecoin had 10-minute block target and same SHA256D PoW algorithm. The client would have no way to tell whether the segment belongs to Litecoin network or to Bitcoin network, despite the two networks starting from different genesis blocks.

This amplifies the existing problem of forks being indistinguishable, because now it's not just blockchain forks (shared ancestry) that can't be distinguished but all code forks that share the key properties (blockchain format and PoW algorithm).

With full header chain, client could simply hard-code a post-fork checkpoint to select the chain they want. But if client is asking only for a tip segment of fixed height, then he can't rely on the fork checkpoint because the segment he's using to verify transactions will eventually become disconnected (e.g. client is using 1000-block segments, but fork happened 2000 blocks ago).

Mitigation is to make the checkpoint rolling and regularly update it.

It is critical to somehow anchor the tip segment to a particular blockchain. Failure to reliably do that opens the door to new classes of attacks:

• Pre-made Forgery: Adversary could simply start a chain off an imaginary header in the future (lie about timestamps) then slowly build a fabricated tip segment on top of it. When the real network reaches that timestamp, adversary could start releasing his pre-made headers to unsuspecting clients, who could be fooled to think that adversary's tip has outpaced the legitimate network.
• Transplanting: Adversary could make a TX on blockchain A and then try to use blockchain A's tip segment to convince a client that a TX happened on blockchain B.
• Reduced Cost Full History Forgery: Adversary could make use of some other legitimate blockchain (A) which DOESN'T commit header roots to get that network to unknowingly assist in a full history forgery of blockchain B's history. Adversary would mine a single block on A where he commits a forged commitment and then waits for legitimate miners to extend it and then use that tip to attempt a transplanting attack against blockchain B.
• Abuse of Sunset of Headers Commitment Consensus Rule: If network should change consensus again to remove the commitments rule, then clients still following such network and relying on coinbase commitments would expose themselves to fixed-cost full history forgery.
• Sybil Attack: If client has no checkpoint to pin the segment to a particular blockchain, he'd have to ask his peers. Adversary could attempt to fool the client into mismatching which tip segment belongs to which network and combine that with reduced cost full history forgery.

Thankfully, all of the above can be mitigated with a checkpointing strategy, which is already employed by status quo due to Bitcoin Cash being a minority fork.

• Status Quo: Known block checkpoint has to be updated only after a hard-fork.
• CHIP: Known block checkpoint has to be updated on regular time intervals, depending on default tip segment length.

This leaves us with the same attack vectors as status quo (forgery and eclipse), with only 1 difference: the forgery attack could forge more than just recent transactions. If forgery is longer than requested segment it could forge the commitment and with that forge the entire history. This is mitigated simply by requesting long enough segments for the initial sync, so that forgery becomes too costly and impractical.

We recommend a 1-year long tip segment for the initial sync. With 10-minute target this would be a fixed size initial sync of 4.2MB, more than enough for reliable security and much lighter than currently required 72MB+. With known block pinning (header segment easily verifiable against block hashes reported by block explorers) this will be practically as reliable as current SPV. Full history forgery would both be prohibitively costly (~$55M as of March '25) and impractical (race condition VS real network).

Implementations

[placeholder, ignore for now]

Test Cases

[placeholder, ignore for now]

Activation Costs

[placeholder, ignore for now]

Ongoing Costs

The additional computational cost is approximately 20 hash operations per block (~log2 of the chain height), which is equivalent to processing one or two standard transactions.
This overhead is negligible compared to the normal block validation process.

Risk Assessment

[placeholder, ignore for now]

Evaluation of Alternatives

Status Quo (Today’s SPV)

1. Full Sync Option:
   • Clients download all headers (~72 MB, growing at ~4.2 MB/year).
   • Trustless—verifies PoW and timestamps back to genesis.
   • Heavy: requires significant bandwidth/storage, impractical for lightweight devices.
2. Checkpoint Option:
   • Clients use hard-coded roots (e.g., developer-set checkpoints) and server proofs.
   • Lighter: skips full header chain sync, uses less data.
   • Trust-heavy: relies on devs for the root’s accuracy—vulnerable to human error or malice.
3. Server Trust Option:
   • Clients skip checks and trust a server for transactions.
   • Lightest: minimal data and effort.
   • Fully trusted: no security unless the server’s honest—useless for trustless design.

CHIP Benefits vs. Status Quo

1. Trustless Flexibility:
   • Status Quo: Only choices are extremes—full sync (trustless but heavy) or checkpoints/server (light but trusted).
   • CHIP: Clients pick a segment (e.g., 10,000 headers, ~800 kB) and verify it against chain-enforced PoW—no trust in devs or servers, just the blockchain.
   • Benefit: Middle ground—trustless sync at a user-chosen size, not all-or-nothing.
2. Scalable Sync Size:
   • Status Quo: Full sync grows indefinitely (~72 MB now, ~100 MB in 5 years); checkpoints are light but static—devs must update them, or the header chain segment after the checkpoint piles on.
   • CHIP: Fixed-size sync (e.g., ~800 kB for 10,000 headers) scales with security needs, not chain length—always current, no manual updates needed.
   • Benefit: Predictable, lightweight sync that doesn’t balloon over time.
3. No External Dependencies for Light Sync:
   • Status Quo: Checkpoints need dev trust; trusted servers need availability and honesty—both pull security outside the chain.
   • CHIP: Root’s in the coinbase—miners enforce it, nodes verify it, clients use it; all trust stays in the blockchain.
   • Benefit: Self-contained security, no third-party weak links.
4. Future-Proofing:
   • Status Quo: Shorter block intervals (e.g., 2 minutes) would spike header growth (~21 MB/year), making full sync worse and checkpoints less viable as they’d require more frequent updates.
   • CHIP: Mitigates growth impact—clients sync a fixed segment regardless of interval; supports scalability tweaks without breaking SPV.
   • Benefit: Ready for BCH’s evolution, not a bottleneck.

Others

• Utreexo: Compacts UTXOs, not headers; orthogonal to this proposal.
• Merkle Patricia Trie: Considered but rejected—sequential block hashes don’t benefit from MPT’s sparse key compression, and proofs may be larger.

Discussions

[placeholder, ignore for now]

Statements

[placeholder, ignore for now]

Acknowledgements

xAI’s Grok 3 and Anthropic’s Claude 3.7 Sonnet for analytical assistance; NanoGPT app for model access, with inference tokens paid in Bitcoin Cash.

Changelog

[placeholder, ignore for now]

Copyright

MIT No Attribution.