eltoo: A Simplified Update Mechanism for Lightning and Off-Chain Contracts

A little over a year ago, the three Lightning Network implementation teams joined forces to work on a common specification for the protocol stack. Now that both that specification and our three implementations are becoming stable and usable, it is time to look forward: to further improve the protocol, to add new features, to simplify, and to fix downsides.

One of the core innovations that enabled Lightning in the first place was an off-chain update mechanism to renegotiate a new state and ensure that the old state can not be settled on-chain. Today, we’re excited to release our latest research paper on a new, simplified, update mechanism for layer 2 protocols, called eltoo.

How does eltoo work?

We can imagine off-chain negotiation as a contractual agreement between a number of parties and settlement as presenting the case to a court that will decide the final state — the court in this case being the blockchain. Since all updates happen off-chain, we need a way for the on-chain court to hear all sides of the argument before making a final judgement. In the case of a participant initiating settlement of the contract, we need a mechanism that defers final settlement, to give the counterparty a chance to provide a more recent state. The court must continue to wait for new state, until eventually it decides to settle the last one it heard. Surprisingly most of the requirements to create this blockchain tailor-made for layer 2 protocols are already fulfilled by the Bitcoin blockchain.

Figure 1: An example execution of the eltoo protocol, showing how intermediate states can be skipped by rebinding a later update transaction to an earlier one, or directly to the setup transaction. Only the last settlement transaction can ever be confirmed on the blockchain.

In eltoo every state is represented as a set of two transactions: an update transaction that spends the contract’s output and creates a new output, and a settlement transaction that spends the newly created update output and splits the funds according to the agreed-upon distribution. The outputs have a script that allows a new update transaction to be attached immediately or else a settlement transaction to be attached after a configurable timeout. Should the participants agree on an update before the timeout expires, they will create a new update transaction, spending the previous output and doublespending the corresponding settlement, effectively invalidating it.

The repeated invalidation of prior state to agree on a new state builds a long chain of update transactions that will eventually be terminated by the latest settlement transaction. However, this has a major disadvantage: should we want to settle, we would have to replay the entire chain of updates on the blockchain. At that point we could have simply performed the entire protocol on-chain. The key insight in eltoo is that we can skip intermediate updates, basically connecting the final update transaction to the contract creation. In order to enable this short-circuiting of updates, we propose a new SIGHASH flag, SIGHASH_NOINPUT, which allows a transaction input to be bound to any transaction output with a matching script. Since all output scripts of prior update-transaction outputs match later input scripts, we can bind a later update to any prior update, allowing us to skip any number of intermediate updates. The paper contains the full construction of the protocol, including the details on how the scripts are built.

Improving Lightning

What we presented above is an update mechanism that allows the endpoints of a payment channel to repeatedly adjust their balances and to attach more advanced constructs such as HTLCs to the state.

The main contribution of the original Lightning paper was one such update mechanism, so are we trying to replace Lightning with this proposal? Absolutely not!

Figure 2: A diagram of the various sub-protocols that are part of the Lightning Stack.

The Lightning Network specification is no longer the specification of a single protocol, but rather a full stack of protocols, each fulfilling its own responsibilities. eltoo doesn’t aim to replace the entirety of the Lightning stack; rather it is a drop-in replacement for the original update mechanism that maintains backward compatibility with the other parts of the stack.

eltoo has fundamentally different tradeoffs than the mechanism presented in the original Lightning paper, which we’ll call LN-penalty; while LN-penalty used a penalty system to punish a misbehaving party, eltoo simply enforces the latest agreed-upon state of the off-chain contract. This has important implications for the applicability and safety of the protocols that are built on top of the update mechanism.

Some of this arises from the fact that in eltoo all participants share a common set of transactions, unlike LN-penalty, which requires asymmetry in which participant has access to which transactions, in order to tailor the reaction to the misbehaving party. This change eliminates what we call toxic information in Lightning. Toxic information comes from transactions belonging to outdated states, which if leaked will result in the loss of funds. This happens not only if a party misbehaves, but also if a node forgets about an update (e.g., when being restored from a backup). With eltoo this is no longer possible because only agreed-upon states can be settled (i.e., eltoo is penalty-less).

The data management for the participants is also simplified under the new paradigm: they no longer need to store hash preimages for invalidated states, and they no longer need to store HTLCs that were invalidated, since the settlement transaction to which they were attached can never be committed to the blockchain. All they need to store is the latest update transaction, its corresponding settlement transaction, and potentially the HTLCs that spend from that settlement. Furthermore the settlement is simplified to just binding the latest update transaction to the setup output and letting the timeout expire before broadcasting the settlement transaction.

We can combine the update outputs with SIGHASH_SINGLE to allow the attachment of additional inputs and outputs to the update transaction at the time of settlement. While this might seem like a minor change, it allows the attachment of fees to the update transactions at the time of settlement, freeing us from having to commit to a fixed fee ahead of time. In the current implementations, we would have to agree on, and commit to, a fixed fee potentially months before we attempt to confirm the transactions on-chain, forcing us to predict how the fee-market will evolve; this can result in massive overcommitment, to be on the safe side. With deferred fee selection we no longer have to agree on a fee, and we can even bump fees should they turn out to be insufficient.

Thanks to the use of feature flags, which allow a node to signal support for a new feature when first connecting to a peer, eltoo can be deployed incrementally on top of today’s network. There is no need to spin up a completely new network.

Beyond Lightning

As a generic Layer 2 update mechanism, eltoo can be used for any number of systems beyond Lightning. For example, it allows for the creation of multiparty off-chain contracts that currently could have up to seven participants, and that could have any number of participants in combination with Schnorr signatures.

One such multiparty off-chain contract is the channel factories presented by Burchert et al. as a scalable way to fund any number of payment channels on top of a single on-chain transaction and to rebalance or reallocate them dynamically without ever touching the blockchain.

The road to eltoo

Before we can implement eltoo, we need a minor change to Bitcoin: the introduction of the SIGHASH_NOINPUT flag for signatures. This was first discussed a few months ago in the context of watchtowers to help secure Lightning channels, but was not formally proposed. A formal proposal may now be found in the eltoo paper.

We invite the community to consider our proposal and to participate in its discussion. We hope to arrive at a consensus for the usage of SIGHASH_NOINPUT, so that it can be accepted and included in a future soft fork of Bitcoin Script. Doing so will put us on the road to a more reliable and simpler Lightning Network, incorporating a new update mechanism that can also be used for many other applications.