CHIP-2026-02: Simplified Header Verification for Bitcoin Cash

While working on the faster blocks CHIP and wanting to solve the problem of SPV light wallet header chain growth, I independently discovered a data structure called “History Tree” (Crosby and Wallach, 2009), later called “Merkle Mountain Range” (Todd, 2012). While working on implementation with Claude, he recognized the pattern and pointed me to existing literature. Having reviewed the literature, I learned that the data structure is even better than I originally thought: it is the optimal accumulator and commitment for append-only data (Bonneau et al., 2025), which our headers happen to be. The accumulator enables this:

  • The server can cache just the latest MMR structure (O(n log n) in size) and efficiently produce on-demand proofs against any past root.
  • The client can hold just the latest accumulator state (O(log n) hashes), which lets him verify the server’s proofs and independently extend it with new headers in O(m) time, where m is the number of headers added.

So I started drafting a CHIP, hoping to get this implemented in light wallet client architectures.
Some sections are still missing, but my goal is to produce a complete specification and reference implementation, so everyone can have an easier time implementing it.

Adopting this would remove the one really annoying technical obstacle to faster blocks (header sync and storage for SPV light clients), which was my main motivation for this research avenue.

Electrum servers already produce these proofs! All that’s needed is for clients to implement the accumulator and extension logic, and they can maintain a self-validated root!


CHIP-2026-02: Simplified Header Verification for Bitcoin Cash

    Title: CHIP-2026-02 Simplified Header Verification for Bitcoin Cash
    First Submission Date: 2026-02-25
    Owners: bitcoincashautist (ac-A60AB5450353F40E)
    Type: Technical
    Layers: SPV
    Status: Draft
    Last Edit Date: 2026-03-02

Contents

Summary

This CHIP proposes a header commitment scheme for Bitcoin Cash that enables light clients to verify blockchain state without storing the full header chain.
By maintaining a compact cryptographic “Merkle Mountain Range” (MMR) accumulator over block headers, clients can reduce storage requirements from linear to logarithmic in chain height.
The MMR can be reduced to a fixed-size root (a single hash) for checkpointing.
We show that every Bitcoin Merkle tree contains an MMR: for backwards-compatibility with Electrum, we exploit this to use Bitcoin’s existing Merkle tree construction.
For new infrastructure, a more efficient recursive MMR root construction is proposed, minimizing proof sizes for recent headers.
The scheme allows clients to verify any historical header against a trusted root or accumulator using inclusion proofs, enabling flexible trust models ranging from fully trustless self-verification to checkpoint-based bootstrapping.
Servers benefit from efficient state caching, allowing them to serve header proofs for any block against any past accumulator state or root.
This proposal complements existing Simplified Payment Verification (SPV) by addressing its storage overhead, making light wallet implementations more practical for resource-constrained devices.


Rest of it can be found in the CHIP’s repository: ac-0353f40e / mmr · GitLab

6 Likes

Today I learned of another name for it: “forest of perfect Merkle trees” and found that Gavin Andersen had independently discovered it, too (back in 2019): Balanced Merkle Forest design · GitHub
The Utreexo paper (Dyra, T., 2019) uses it as a primitive, too!

1 Like

Today I implemented the “extend” function for Bitcoin-style Merkle tree construction. It’s the same principle as with MMR: we keep the “peaks” as the accumulator’s state, and when a new leaf is appended we recompute the set of peaks.

Both MMR and Bitcoin-style commitment schemes work pretty much the same, because the same MMR structure is actually part of both constructions. I edited the CHIP and opening post to incorporate this insight.

Layered MMRs Construction

    Second bag MMR:                         **root**
                                    __________/ |
                                   /            |
    First bag MMR:             ((I))            |
                         _______/ \______       |
                        /                \      |
    Base MMR:         (H)                |      |
                   _ /   \ _             |      |
                 /           \           |      |
                F             G          |      |
              /    \        /    \       |      |
             A      B      C      D     (E)     |
            / \    / \    / \    / \    / \     |
           0   1  2   3  4   5  6   7  8   9  ((10))
Bitcoin Merkle Tree Construction

                                 **root**
                         __________/  \________
                        /                      \
                      (H)                       K
                   _ /   \ _                   / \
                 /           \                /   \
                F             G              J     J'
              /    \        /    \        /     \
             A      B      C      D     (E)      I
            / \    / \    / \    / \    / \     /  \
           0   1  2   3  4   5  6   7  8   9  (10)  10'

Proof of concept implementation and tests:

3 Likes