MIME-Version: 1.0
In-Reply-To: <874ljsitvx.fsf@gmail.com>
References: <874ljsitvx.fsf@gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Mon, 30 Apr 2018 16:00:55 -0700
Message-ID: <CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008c8363056b18d320"
Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for
 Lightning and Off-Chain Contracts
Precedence: list

--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

<div dir=3D"ltr">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.<div><br></div><div>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?</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Mon, Apr 30, 2018 at 8:41 AM, Christian D=
ecker via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(cross-posti=
ng to bitcoin-dev since this serves as motivation behind the<br>
sighash_noinput proposal)<br>
<br>
&gt; TL;DR: we announce a new, simple, update mechanism for off-chain proto=
cols,<br>
&gt; see the announcement [1] and the paper [2] :-)<br>
<br>
A little over a year ago, the three Lightning Network implementation<br>
teams joined forces to work on a common specification for the protocol<br>
stack. Now that both that specification and our three implementations<br>
are becoming stable and usable, it is time to look forward: to further<br>
improve the protocol, to add new features, to simplify, and to fix<br>
downsides.<br>
<br>
One of the core innovations that enabled Lightning in the first place was a=
n<br>
off-chain update mechanism to renegotiate a new state and ensure that the o=
ld<br>
state can not be settled on-chain. Today, we&#39;re excited to release our =
latest<br>
research paper on a new, simplified, update mechanism for layer 2 protocols=
,<br>
called eltoo.<br>
<br>
eltoo is a drop-in replacement for the penalty based invalidation<br>
mechanism that is used today in the Lightning specification. It is<br>
similar in many ways to the sequence number mechanism that was already<br>
present in the original Bitcoin implementation. But, while sequence<br>
numbers were unenforceable on the blockchain, eltoo is enforceable by<br>
overriding subsequent states on-chain.<br>
<br>
Unlike the current mechanism used in Lightning so far, it is not penalty<br=
>
based, i.e., publishing an old state does not result in the faulty node<br>
to automatically lose funds, and is most similar to the duplex<br>
micropayment channels construction. It is a symmetric scheme, i.e., all<br>
participants share an identical set of transactions, and it ensures that th=
e<br>
last agreed upon state is settled on-chain, with similar tradeoffs as<br>
today&#39;s Lightning (timelock vs. online requirement).<br>
<br>
eltoo addresses some of the issues we encountered while speficying and<br>
implementing the Lightning Network. For example outsourcing becomes very<br=
>
simple since old states becoming public can&#39;t hurt us anymore. We<br>
completely remove the need to estimate fees ahead of time. The<br>
construction allows us to attach fees when settling, and even allows for<br=
>
fees to be bumped using CPFP or RBF.<br>
<br>
Beyond Lightning, eltoo can be used as a generic update mechanism for an<br=
>
off-chain contract, for a larger number of participants. This was not<br>
possible in the current update mechanism since reactions to a<br>
misbehaving participant needed to be tailore to that participant. This<br>
enables other protocols such as the channel factories, and in<br>
combination with Schnorr signatures allows for very large off-chain<br>
contracts with minimal on-chain footprint.<br>
<br>
Before we can implement eltoo, we need a minor change to Bitcoin: the<br>
introduction of the SIGHASH_NOINPUT flag for signatures. This was first<br>
discussed a few months ago in the context of watchtowers to help secure<br>
Lightning channels, but was not formally proposed. A formal proposal may<br=
>
now be found in the eltoo paper.<br>
<br>
We invite the community to consider our proposal and to participate in<br>
its discussion. We hope to arrive at a consensus for the usage of<br>
SIGHASH_NOINPUT, so that it can be accepted and included in a future<br>
soft fork of Bitcoin Script. Doing so will put us on the road to a more<br>
reliable and simpler Lightning Network, incorporating a new update<br>
mechanism that can also be used for many other applications.<br>
<br>
The full official announcement can be found at [1] and the paper with the f=
ull<br>
details can be found at [2].<br>
<br>
Looking forward to the communities feedback,<br>
Christian<br>
<br>
[1] <a href=3D"https://blockstream.com/2018/04/30/eltoo-next-lightning.html=
" rel=3D"noreferrer" target=3D"_blank">https://blockstream.com/2018/<wbr>04=
/30/eltoo-next-lightning.<wbr>html</a><br>
[2] <a href=3D"https://blockstream.com/eltoo.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://blockstream.com/eltoo.<wbr>pdf</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>

--0000000000008c8363056b18d320--