From: Christian Decker <decker.christian@gmail.com>
To: lightning-dev@lists.linuxfoundation.org,
	bitcoin-dev@lists.linuxfoundation.org
Date: Mon, 30 Apr 2018 17:41:38 +0200
Message-ID: <874ljsitvx.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning
	and Off-Chain Contracts
Precedence: list

(cross-posting to bitcoin-dev since this serves as motivation behind the
sighash_noinput proposal)

> TL;DR: we announce a new, simple, update mechanism for off-chain protocols,
> see the announcement [1] and the paper [2] :-)

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.

eltoo is a drop-in replacement for the penalty based invalidation
mechanism that is used today in the Lightning specification. It is
similar in many ways to the sequence number mechanism that was already
present in the original Bitcoin implementation. But, while sequence
numbers were unenforceable on the blockchain, eltoo is enforceable by
overriding subsequent states on-chain.

Unlike the current mechanism used in Lightning so far, it is not penalty
based, i.e., publishing an old state does not result in the faulty node
to automatically lose funds, and is most similar to the duplex
micropayment channels construction. It is a symmetric scheme, i.e., all
participants share an identical set of transactions, and it ensures that the
last agreed upon state is settled on-chain, with similar tradeoffs as
today's Lightning (timelock vs. online requirement).

eltoo addresses some of the issues we encountered while speficying and
implementing the Lightning Network. For example outsourcing becomes very
simple since old states becoming public can't hurt us anymore. We
completely remove the need to estimate fees ahead of time. The
construction allows us to attach fees when settling, and even allows for
fees to be bumped using CPFP or RBF.

Beyond Lightning, eltoo can be used as a generic update mechanism for an
off-chain contract, for a larger number of participants. This was not
possible in the current update mechanism since reactions to a
misbehaving participant needed to be tailore to that participant. This
enables other protocols such as the channel factories, and in
combination with Schnorr signatures allows for very large off-chain
contracts with minimal on-chain footprint.

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.

The full official announcement can be found at [1] and the paper with the full
details can be found at [2].

Looking forward to the communities feedback,
Christian

[1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[2] https://blockstream.com/eltoo.pdf