MIME-Version: 1.0
References: <874ljsitvx.fsf@gmail.com>
	<CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
	<87vac7hakf.fsf@gmail.com>
In-Reply-To: <87vac7hakf.fsf@gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Tue, 01 May 2018 15:50:27 +0000
Message-ID: <CADZtCShihv1PR4yD_xATD2mv5CSMqH385HWVLdZQSG_9ZyJ7Jw@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008a045e056b26ee59"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for
 Lightning and Off-Chain Contracts
Precedence: list

--0000000000008a045e056b26ee59
Content-Type: text/plain; charset="UTF-8"

Can you explain why a fixed offset along the whole circuit is enough to
ensure safely as opposed to an increased delta at each hop?

On Tue, May 1, 2018, 5:05 AM Christian Decker <decker.christian@gmail.com>
wrote:

> Jim Posen <jim.posen@gmail.com> writes:
> > 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?
>
> That's a good point Jim. We need to make sure that the CLTVs are far
> enough in the future for the CSV timeout to expire and to grab any
> preimage downstream and insert it upstream. Overall this results in an
> offset of all the CLTVs to (less than) the maximum CSV timeout along the
> path. This would be a fixed offset for each channel and can be announced
> using the gossip protocol, so senders can take it into consideration
> when computing the routes. Notice that this is not really the CLTV
> delta, which would accumulate along the path, but an offset on which the
> CLTV deltas build on.
>
> In today's network we have many nodes that have a CLTV delta of 144
> blocks, which quickly results in HTLC funds unavailable for several days
> depending on the route length, so I don't think that adding a fixed
> offset is much worse. Once we have watch-towers we can reduce both the
> offset as well as the CLTV deltas. Since eltoo makes watch-towers less
> expensive, given the reduced storage costs, I'd argue that it's a net
> positive for the Lightning network (but then again I'm biased) :-)
>

--0000000000008a045e056b26ee59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Can you explain why a fixed offset along the whole circui=
t is enough to ensure safely as opposed to an increased delta at each hop?<=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, May 1, 2018, 5=
:05 AM Christian Decker &lt;<a href=3D"mailto:decker.christian@gmail.com">d=
ecker.christian@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Jim Posen &lt;<a href=3D"mailto:jim.posen@gmail.com" target=3D"_blank=
" rel=3D"noreferrer">jim.posen@gmail.com</a>&gt; writes:<br>
&gt; If my understanding is correct though, this construction would<br>
&gt; significantly increase the safe CLTV delta requirements because HTLCs<=
br>
&gt; cannot be timed out immediately on the settlement transaction. Conside=
r a<br>
&gt; case where node B receives an HTLC from A and forwards to C. If the HT=
LC<br>
&gt; offered to C times out and C does not fail the HTLC off-chain, Lightni=
ng<br>
&gt; currently guarantees that the CLTV delta is sufficient that I may clos=
e the<br>
&gt; channel to C on-chain and claim the timed-out HTLC before my upstream =
HTLC<br>
&gt; to A times out. If the CLTV delta is too small, I may fail the upstrea=
m<br>
&gt; HTLC as soon as it times out, and then C may still claim the downstrea=
m<br>
&gt; HTLC with the preimage on-chain. With eltoo, when B closes the downstr=
eam<br>
&gt; channel on-chain, it must wait the CSV timeout on the update transacti=
on<br>
&gt; before locking in the timed-out HTLC. This effectively means the CLTV =
delta<br>
&gt; has to be greater than the CSV timeout, plus some extra (whereas it is=
<br>
&gt; currently safe to make it significantly shorter). Is that true or am I=
<br>
&gt; missing something?<br>
<br>
That&#39;s a good point Jim. We need to make sure that the CLTVs are far<br=
>
enough in the future for the CSV timeout to expire and to grab any<br>
preimage downstream and insert it upstream. Overall this results in an<br>
offset of all the CLTVs to (less than) the maximum CSV timeout along the<br=
>
path. This would be a fixed offset for each channel and can be announced<br=
>
using the gossip protocol, so senders can take it into consideration<br>
when computing the routes. Notice that this is not really the CLTV<br>
delta, which would accumulate along the path, but an offset on which the<br=
>
CLTV deltas build on.<br>
<br>
In today&#39;s network we have many nodes that have a CLTV delta of 144<br>
blocks, which quickly results in HTLC funds unavailable for several days<br=
>
depending on the route length, so I don&#39;t think that adding a fixed<br>
offset is much worse. Once we have watch-towers we can reduce both the<br>
offset as well as the CLTV deltas. Since eltoo makes watch-towers less<br>
expensive, given the reduced storage costs, I&#39;d argue that it&#39;s a n=
et<br>
positive for the Lightning network (but then again I&#39;m biased) :-)<br>
</blockquote></div>

--0000000000008a045e056b26ee59--