Eltoo paper proposed a latest-state model for Bitcoin Lightning channels

Christian Decker of Blockstream, Rusty Russell of Blockstream and Olaoluwa Osuntokun of Lightning Labs released “eltoo: A Simple Layer2 Protocol for Bitcoin” on April 30, 2018. The paper proposed a different way for Bitcoin payment channels to decide which off-chain balance state could ultimately settle on the blockchain.

The proposal mattered because Lightning’s security model required participants to invalidate old channel states through penalties. Eltoo instead aimed to make a newer agreed state override an older one. That was a research advance, not a Bitcoin upgrade: the design depended on a new signature-hash capability and therefore could not operate on Bitcoin under the consensus rules in force on April 30, 2018.

Replacing punishment with the latest state

A Lightning channel lets participants revise balances away from the blockchain and later settle the result on-chain. The hard problem is preventing an obsolete, more favorable balance from being enforced after the parties have agreed to a replacement.

The Lightning construction available in 2018 addressed that problem with revocation and punishment. Old states became dangerous to publish because a counterparty holding the relevant revocation information could claim the channel funds. The eltoo authors described those invalidated commitments as “toxic” information: accidental disclosure or restoration from an outdated backup could create loss risk.

Eltoo proposed a different ordering rule. Each channel state would have an enforceable state number and would be represented by an update transaction plus a settlement transaction. If an old update reached the blockchain, a participant could respond during the settlement delay with a later update. The latest valid state would prevail, without imposing a confiscatory penalty merely because an obsolete state appeared.

That structure also changed the storage burden. Under the authors’ design, a participant would retain the latest update and settlement data rather than preserve the revocation material associated with every superseded state. The paper further argued that this symmetry could make multiparty off-chain contracts and channel factories easier to construct.

The required consensus change

Eltoo’s simplifying idea rested on what the paper called a “floating transaction”: a signed update that could be rebound to a compatible earlier output. Ordinary Bitcoin signatures commit to the specific output being spent, so the authors proposed a new flag named `SIGHASH_NOINPUT`.

The flag would let a signature omit that previous-output commitment under defined conditions. A later update could then attach to an earlier compatible state and skip intermediate updates. The authors also described combining the mechanism with `SIGHASH_SINGLE` so fees could be added when settlement occurred rather than fixed far in advance.

This dependency was the proposal’s central limitation on April 30, 2018. Blockstream’s contemporaneous announcement explicitly said implementation required a Bitcoin change and invited discussion toward possible inclusion in a future soft fork. No activation, release schedule or network consensus had been secured. Claims about simpler backups, safer recovery, multiparty channels and flexible fees were properties argued by the paper, not demonstrated production outcomes.

Why the release was consequential

Eltoo separated Lightning’s routing and payment stack from its channel-state enforcement mechanism. Its authors presented it as a possible drop-in replacement for that layer, not as a replacement for Lightning as a whole. That distinction made the paper institutionally important: teams from two prominent Bitcoin infrastructure companies jointly described a path for changing a foundational security tradeoff while preserving the broader network architecture.

The event was therefore consequential as protocol research rather than market news. It placed a concrete consensus proposal behind a simpler “latest state wins” model and exposed the design to public technical review.

Later context

Later work renamed and revised the signature-hash idea as BIP 118 `SIGHASH_ANYPREVOUT` for Taproot scripts. That standards document remains marked Draft in the Bitcoin BIPs repository. This later record clarifies the proposal’s lineage; it must not be read as functionality that Bitcoin or Lightning possessed on April 30, 2018.