From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 729864A6 for ; Mon, 30 Apr 2018 23:00:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 461AE148 for ; Mon, 30 Apr 2018 23:00:57 +0000 (UTC) Received: by mail-qt0-f169.google.com with SMTP id e8-v6so8044108qth.0 for ; Mon, 30 Apr 2018 16:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KB1whuGgKcjN30zeLkGVxRGGVqJHgR1HZCF0AngPti4=; b=aLq2SV9csEkaMxY8oIm8X+jwM96Zaxly5V79e9rX9kTokIR578l8VnemeUBl6o1mK0 Sjnz413H8SwEM+dEa1Of0v+9E1wB1xVFkwJYl6XSWg0R6j4zlhVoiZmiE7LtO2OsQZ/v dGuKbN9nnX3NKFvfgUnGHiXuhTRyrl3FHpXw4Ky6QwdNaHlQ2kRWiXs8AXJN9J4faymJ 2z7jMkixnzOyN8sYsF5R/QpAf7nlWhFaF+YeGxvUUQ+z7AEwpkyCJyL9enhSvQ9u89fG E+cf06HAqKpRXTdksAuitdKcfr+gW0mDMywuPivgKuJ5GeB+huwDUBeZ4aYeAnlPEzRS r6ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KB1whuGgKcjN30zeLkGVxRGGVqJHgR1HZCF0AngPti4=; b=sGNjdm+4RyaKDcIpFJqd8Le8YWH8ZSMUj4Q91g6Ma6F5TC5rBmfTD9G1Txm4oiuJI2 sdPEH7+clsSjRlAZ/Fs2Jwm39s+2FKhl3gPaQwsQ8baZSrp4mPtXmIyIczKXfqZ3WSDZ Wa5pEWNsBlXvOfm630JUWv9MweToohnxP1JCDDsvVsROe4sEkqtXDqo5MGJkDafQyHkI qsZTZ8jEXf4Q8Pd2vCERazBmAGTYHwrCMBAhhR8r+4uBXsuCLw2JREeqYeDojWeEMWnV kLu3aHHvm5iA4QqAYf2cA2c+O8I5DEgLczHKtLYvQyKIrMElZwtw9QV08oiMWYiNYhaV Pr6w== X-Gm-Message-State: ALQs6tDRIJUtNPRsVmN5KvqunyyL2VNrnLDxU/lz6m2gyiOoWhiBGXnU Fw8M5dwrB7pGcvW9SIkMK2IB5KafetwBxvvcf2k= X-Google-Smtp-Source: AB8JxZobbkXisPvPw9I3zyEXwQZtKIhs6NCjEY6xO+cEYz+QD6A7bBfS6M3VqszVMjfDfHRyDdYsSbuqAxdEruDQbpY= X-Received: by 2002:a0c:946c:: with SMTP id i41-v6mr12026528qvi.139.1525129256140; Mon, 30 Apr 2018 16:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.50.92 with HTTP; Mon, 30 Apr 2018 16:00:55 -0700 (PDT) In-Reply-To: <874ljsitvx.fsf@gmail.com> References: <874ljsitvx.fsf@gmail.com> From: Jim Posen Date: Mon, 30 Apr 2018 16:00:55 -0700 Message-ID: To: Christian Decker , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008c8363056b18d320" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 01 May 2018 04:00:08 +0000 Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 23:00:58 -0000 --0000000000008c8363056b18d320 Content-Type: text/plain; charset="UTF-8" This construction is pretty neat and seems to solve a lot of problems. I find the use of CLTV with past timestamps to provide ordering in particular to be quite clever. If my understanding is correct though, this construction would significantly increase the safe CLTV delta requirements because HTLCs cannot be timed out immediately on the settlement transaction. Consider a case where node B receives an HTLC from A and forwards to C. If the HTLC offered to C times out and C does not fail the HTLC off-chain, Lightning currently guarantees that the CLTV delta is sufficient that I may close the channel to C on-chain and claim the timed-out HTLC before my upstream HTLC to A times out. If the CLTV delta is too small, I may fail the upstream HTLC as soon as it times out, and then C may still claim the downstream HTLC with the preimage on-chain. With eltoo, when B closes the downstream channel on-chain, it must wait the CSV timeout on the update transaction before locking in the timed-out HTLC. This effectively means the CLTV delta has to be greater than the CSV timeout, plus some extra (whereas it is currently safe to make it significantly shorter). Is that true or am I missing something? On Mon, Apr 30, 2018 at 8:41 AM, Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > (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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000008c8363056b18d320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This construction is pretty neat and seems to solve a lot = of problems. I find the use of CLTV with past timestamps to provide orderin= g in particular to be quite clever.

If my understanding = is correct though, this construction would significantly increase the safe = CLTV delta requirements because HTLCs cannot be timed out immediately on th= e settlement transaction. Consider a case where node B receives an HTLC fro= m A and forwards to C. If the HTLC offered to C times out and C does not fa= il the HTLC off-chain, Lightning currently guarantees that the CLTV delta i= s sufficient that I may close the channel to C on-chain and claim the timed= -out HTLC before my upstream HTLC to A times out. If the CLTV delta is too = small, I may fail the upstream HTLC as soon as it times out, and then C may= still claim the downstream HTLC with the preimage on-chain. With eltoo, wh= en B closes the downstream channel on-chain, it must wait the CSV timeout o= n the update transaction before locking in the timed-out HTLC. This effecti= vely means the CLTV delta has to be greater than the CSV timeout, plus some= extra (whereas it is currently safe to make it significantly shorter). Is = that true or am I missing something?
=
On Mon, Apr 30, 2018 at 8:41 AM, Christian D= ecker via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
(cross-posti= ng 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 proto= cols,
> 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 a= n
off-chain update mechanism to renegotiate a new state and ensure that the o= ld
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 th= e
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 f= ull
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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--0000000000008c8363056b18d320--