Old-State Prevention in Payment Channels: From Bitcoin Spilman to Cashu

1. The Core Problem

A payment channel lets two parties exchange value without committing every update to a blockchain (or, in the ecash world, to a mint). Instead, they sign new states off-chain and only settle the final result. This is what makes channels fast and cheap.

But it creates a problem. Both parties hold signed copies of past states. When the channel settles, only the latest state should count. If a party can publish an older state where they held a larger balance, they can steal.

Consider a simple example. Alice opens a channel funded with 100 sat. She pays Bob 30 sat, creating state N+1 where Bob holds 30 and Alice holds 70. But state N, where Alice still held the full 100, was also a valid signed state. If Alice can publish state N at settlement time, she gets her 30 sat payment back. She stole from Bob.

Every payment channel design must answer one question: how do we ensure that old states cannot be settled? The answer has changed over time, and the evolution tells a story about trade-offs between complexity and structural guarantees.

2. The Original: Bitcoin Spilman Channels (2013)

In April 2013, Jeremy Spilman posted a proof-of-concept to the Bitcoin forum for a unidirectional payment channel built on Bitcoin. It was one of the earliest concrete designs for off-chain payments, and it solved the old-state problem in a way so simple that many later designs overlooked it.

How It Worked

• The channel was unidirectional: money flowed in one direction, from sender to receiver.
• Both parties locked funds in a 2-of-2 multisig address on the Bitcoin blockchain.
• Before funding, the sender created a refund transaction with an nLockTime that would return funds after a timeout. This ensured the sender could recover money if the receiver disappeared.
• For each payment, the sender created a new transaction spending the funding output. They signed it with SIGHASH_SINGLE, which commits to a single output but leaves room for the receiver to add their own output. The sender sent this partially-signed transaction to the receiver.
• The receiver added their output, signed the complete transaction with SIGHASH_ALL, and kept the fully-signed transaction. They did not send it back to the sender.

Why Old States Were Not a Problem

The old-state prevention was structural, built into the protocol by design. The sender never received fully-signed transactions back from the receiver. Each new payment created a transaction where the sender had less money and the receiver had more. The receiver held all the signed transactions, and they always preferred the latest one because it paid them more.

Spilman's design made it impossible for the sender to cheat, because the sender could not publish any state on their own. The receiver, who held the complete transactions, had no incentive to publish old states since those paid them less. No explicit revocation was needed because the structure itself prevented cheating.

The limitation was real, though. Money could only flow one way. Once the sender exhausted their capacity, the channel was done. No refunds, no back-and-forth. That constraint motivated the next generation of channel designs.

3. Lightning Network: Explicit Revocation (2015 – Present)

The Lightning Network, described in the 2015 whitepaper by Poon and Dryja, introduced bidirectional payment channels. Both parties could send and receive. This was a huge capability upgrade, but it broke the structural old-state prevention that Spilman relied on.

Why Bidirectional Changes Everything

In a bidirectional channel, either party might have more funds in an older state. Consider: Bob pays Alice 0.5 BTC in state N+1. But state N shows Bob holding 1 BTC. Bob now has a clear incentive to publish state N, because doing so would give him 0.5 BTC more than the honest state N+1. The structural guarantee vanishes the moment both directions are possible.

The Solution: Revocation with Penalties

Lightning solved this with asymmetric commitment transactions and a revocation protocol. The mechanism works as follows:

• Each state update produces two commitment transactions, one for each party. They are asymmetric: Alice's commitment includes a time-locked path for her and a revocable path for Bob, and vice versa.
• When both parties agree to move from state N to state N+1, they exchange the private keys that would let the other party spend from their old commitment transaction (state N).
• If Alice later publishes her old commitment for state N, Bob now holds the revocation key that lets him claim all of Alice's funds as a penalty.

The security model shifts from "can't cheat" to "cheating is economically irrational." Publishing an old state is always possible. But doing so triggers a penalty that costs more than the cheat gains. As the Lightning specification states, when a party publishes a revoked commitment, "their peer is able to use the previously exchanged revocation secret to claim the funds of the malicious actor."

This penalty-based approach is powerful but adds complexity. Each party must store a growing set of revocation secrets, watch the blockchain for old-state publications, and respond within a time window to claim penalties. The cost of this complexity is real: Lightning implementations must handle edge cases around penalty transactions, justice transactions, and watchtower protocols.

4. The "Magic 1 Sat" — An Explicit Mutual Exclusivity Attempt

During early Cashu Spilman prototyping, an idea was floated that would have added an explicit mutual exclusivity mechanism to the channel design. It was called the "magic 1 sat."

The Concept

The idea was straightforward. A special 1 sat token would be included in every commitment swap, acting as a "state marker." Only the latest state's magic token would be spendable at the mint. When the receiver settles the latest state, the magic token from that swap gets spent. This immediately invalidates all previous states, because their magic tokens have already been consumed.

This would have created an explicit mutual exclusivity guarantee. Spending the latest state automatically invalidates all previous states, because the magic tokens from those older states were already spent as part of progressing to the current state.

Why It Was Not Adopted

The magic 1 sat idea never made it into cdk-spilman or the Cashu Spilman specification proposal (PR cashubtc/nuts#296). The reason is simple: the structural guarantee of unidirectional channels makes it unnecessary. The Cashu Spilman design inherits the original Spilman insight that old-state prevention is built into the protocol structure.

5. Cashu Spilman: Back to Structural Guarantees (2024 – Present)

Cashu Spilman channels return to the original 2013 insight: unidirectional channels do not need explicit revocation. The design maps Bitcoin Spilman concepts into the ecash world:

• 2-of-2 multisig becomes P2PK with SIG_ALL (NUT-11), where the sender signs all inputs and outputs atomically.
• Funding transaction becomes a funding token, a set of Cashu proofs locked to the channel.
• Commitment states become signed balance updates. Each update specifies how much the receiver gets and how much the sender gets back.

SIG_ALL: The Atomic Commitment

The key cryptographic tool is SIG_ALL from NUT-11. When the sender creates a balance update (a "commitment swap"), they sign all inputs and all outputs as a single atomic unit. The commitment is indivisible. You cannot take the sender's refund outputs without also taking the receiver's payment outputs, because they are all bound together under one signature.

Old-State Prevention, Back to Structural

The old-state prevention in Cashu Spilman mirrors the 2013 Bitcoin Spilman design:

1. Unidirectional: the receiver (the mint, in the settlement role) always prefers the latest state, because it pays them more.
2. Sender can't publish unilaterally: the mint holds the verified commitments. The sender does not receive fully-signed commitments back.
3. No penalty mechanism needed: there is no incentive to publish old states because no party can benefit from doing so.

Cashu Spilman proves that for unidirectional channels, structural mutual exclusivity is not just sufficient. It is more elegant than any explicit mechanism. No revocation secrets to store, no penalty transactions to watch for, no justice protocols to implement. The protocol structure itself guarantees that only the latest state matters.

6. Comparison

7. Timeline

8. Key Takeaway