path: root/a9/2ecc16a6e34c132f3e4ff0d07283c7835c85cd

Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F29DE728
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  2 May 2018 01:15:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
	[209.85.216.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0ED7D675
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  2 May 2018 01:15:12 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id q6-v6so16525938qtn.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 01 May 2018 18:15:12 -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
	:cc; bh=2BEv/fWJvYFeo3fwbwIagVaoXbtkdUHeq5ESuOoh0QY=;
	b=evYcNasUH8RLuZqdyY8lI6q5crh3uj9US7DLZYNEs1Dw1jgMVMrrY3JpPD8wQuofCQ
	Sx1/ds5pYSPOjoIIcPeyUhmD5bOSG5wpgrh6NBEMBZ/NhaojTxtlG8dsJM54tQp58DaB
	8tyw1icIeuRXRZdbw8KWxvZIYgoDw+7h5ZVTmKwWug7IW2x6GRvvJRIrqGk39aJ0iKlk
	fsN1dFvuFBJ/zb0J6zT5rQAtQozrsJB11ZUZ/Qs/TqQxyNC1WQ/rdKy6iifjg2j+E/TT
	aRUHZ4sCBqJXavfi+I5l5c0NHMDcx2AJJN07jEyo7k80AnidtEIMyw3vAgZ+ICcYO5eo
	chlw==
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:cc;
	bh=2BEv/fWJvYFeo3fwbwIagVaoXbtkdUHeq5ESuOoh0QY=;
	b=b+WvXEduKdSJsNrgTh5+TqFCmZN3FQnYJvBEJJ0g/omj2v2rhgloGe9KlRXsC/4IiF
	LmmcX0SLQA3rddjry/DZUo7G9Xpd1sIJQ9eqIVXwiVfF56MIT5UoRrRxd3GXcRtxD/qU
	rvormSGdg96vTzVL6Hb2fRhIJYGj2KvXanTh1m1TL0c50KOimKzWeI4JYUMJlOhaVy2M
	HuIpl8XJ7nKJ+ik8srlUzmH4wJxqV7BMaeusmJOKBosvVXk8KZLuhOOmPxEDM8H5fPZg
	zalqpqvRmDl4WGiWQjxniwL+2hsiwClVMtxEPiGzcQsQrrZdXz/YCZqo39rUOaz3heVp
	mvSg==
X-Gm-Message-State: ALQs6tDIT0OfKMx5n9rkm1RK0yQdugWiLvuFlp34yJo69QvM5aEGoOL3
	cn9Fl2L0YP8FmHDTI/5FnBPUJrDGd3+wXQH1AU8=
X-Google-Smtp-Source: AB8JxZqVdNIJ15F1WGFxzLx3o0eztd3MTu8wmT4/NjyJwGPuu49hhLdnaPeZMx2kUg2gq4nrGqDEXY9xZWbr290KwKo=
X-Received: by 2002:a0c:b691:: with SMTP id
	u17-v6mr14934116qvd.92.1525223711938; 
	Tue, 01 May 2018 18:15:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Tue, 1 May 2018 18:15:10 -0700 (PDT)
In-Reply-To: <87bmdzgu4v.fsf@gmail.com>
References: <874ljsitvx.fsf@gmail.com>
	<CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
	<87vac7hakf.fsf@gmail.com>
	<CADZtCShihv1PR4yD_xATD2mv5CSMqH385HWVLdZQSG_9ZyJ7Jw@mail.gmail.com>
	<87in87gx0q.fsf@gmail.com>
	<CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.gmail.com>
	<87bmdzgu4v.fsf@gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Tue, 1 May 2018 18:15:10 -0700
Message-ID: <CADZtCSgHmyYbumDw6bwfYpoqc9b-0JmHM5-22=Y1FXNDiTghrA@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008d9e47056b2ed19d"
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: Wed, 02 May 2018 01:15:32 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2018 01:15:14 -0000

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

OK, I see what you are saying. You are effectively suggesting pipelining
the broadcasts of the update transactions. I think this introduces a
problem that a node in the circuit that withholds the preimage for too long
can force all upstream channels to be closed, at only the expense of their
one upstream channel being closed. I believe such an attack could
significantly disrupt the network.

Let me elaborate on the way I'm thinking about this:

So say I'm a routing node with an upstream HTLC with CLTV = X. I need to
ensure that if I learn the preimage, that I have time to broadcast and
confirm an HTLC-success transaction before height X. We'll call this number
of blocks D_success. So if I know the preimage, let's say X - D_success is
the latest height that I can safely broadcast the HTLC-success transaction,
assuming the settlement transaction is already final (ie. the update
transaction is confirmed and the CSV delay has passed). So now I also need
to know when to close the channel with the update transaction. I'll assume
it will take at most D_update blocks from the time I broadcast the update
transaction for it to be mined. So unless the downstream HTLC is already
failed, I should always close the upstream channel at height X - D_success
- CSV_update - D_update.

Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize
the safe delta between the upstream and downstream CLTVs, I will want to
broadcast and confirm an HTLC-timeout transaction as soon after height Y as
possible. So assuming that the downstream settlement transaction is final
at height Y and it takes at most D_timeout blocks for the HTLC timeout
transaction to confirm once it is final assuming no double spends, then Y +
D_timeout is very latest I might learn the payment preimage from the
downstream channel on-chain. So I should be safe as long as X - D_success >
Y + D_timeout. This assumes that the update transaction for the downstream
channel is already mined and the CSV has passed. However, we know from
above that I had to close the upstream channel at time X - D_success -
CSV_update - D_update, which may very well be before Y. So if the
downstream hop waits until just before Y to publish the preimage, they can
force me to close my upstream channel. This applies transitively for
further upstream hops, assuming a large enough CSV value.

Granted, upstream hops can watch the blockchain for preimage reveals in
other closings transaction and perhaps fulfill off-chain if there is
sufficient time. This would not be possible with payment decorrelation
through scriptless scripts or the like.

Does that logic sound right to you?

On Tue, May 1, 2018 at 10:31 AM, Christian Decker <
decker.christian@gmail.com> wrote:

> Jim Posen <jim.posen@gmail.com> writes:
> > I'm still not following why this doesn't accumulate.
> >
> > In the example route, let's look at it from the point of view of C. C
> sees
> > the following regardless of whether D or E or someone behind E is the
> last
> > hop in the route:
> >
> > B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
> >
> > So D is not required to reveal the preimage before time X, and in the
> case
> > of an on-chain settle, C needs to be able to redeem the HTLC output
> through
> > the timeout clause before time X + delta. C can't redeem the HTLC (with
> > sufficient confirmations) at least until the settlement transaction is
> > confirmed. So it seems to me that regardless of the overall route and the
> > maximum CSV on it, the delta for the C hop has to be greater than the CSV
> > delay on the update transaction. And that this must be true at every hop
> > for the same reason.
>
> That'd be a purely reactionary behavior, i.e., chosing the delta in such
> a way that I can both settle the channel and have enough time to react
> to turn around and reveal the preimage. So with the assumptions we had
> before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
> 288 on each hop, yes. That's basically the case in which each channel
> reacts serially.
>
> You can trivially parallelize these closures by looking ahead and
> noticing that each hop really just cares about its own closure deadline,
> i.e., each node just cares to close 288 blocks before the CLTV expires,
> not that its delta w.r.t. to the downstream channel is that far in the
> future. So all we care about is that once we are due to give the
> upstream hop the preimage we've already closed the downstream channel
> and can now read the HTLC preimage from that channel.
>
> The CSV timeout isn't part of the delta on each hop, but we need to
> implement the deadline computation as:
>
> ```
> CLTV - CLTV delta - CSV
> ```
>
> instead of LN-penaltiy's
>
> ```
> CLTV - CLTV delta
> ```
>

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

<div dir=3D"ltr">OK, I see what you are saying. You are effectively suggest=
ing pipelining the broadcasts of the update transactions. I think this intr=
oduces a problem that a node in the circuit that withholds the preimage for=
 too long can force all upstream channels to be closed, at only the expense=
 of their one upstream channel being closed. I believe such an attack could=
 significantly disrupt the network.<div><br></div><div>Let me elaborate on =
the way I&#39;m thinking about this:<br><div><br></div><div>So say I&#39;m =
a routing node with an upstream HTLC with CLTV =3D X. I need to ensure that=
 if I learn the preimage, that I have time to broadcast and confirm an HTLC=
-success transaction before height X. We&#39;ll call this number of blocks =
D_success. So if I know the preimage, let&#39;s say X - D_success is the la=
test height that I can safely broadcast the HTLC-success transaction, assum=
ing the settlement transaction is already final (ie. the update transaction=
 is confirmed and the CSV delay has passed). So now I also need to know whe=
n to close the channel with the update transaction. I&#39;ll assume it will=
 take at most D_update blocks from the time I broadcast the update transact=
ion for it to be mined. So unless the downstream HTLC is already failed, I =
should always close the upstream channel at height X - D_success - CSV_upda=
te - D_update.</div></div><div><br></div><div>Now we&#39;ll look at the dow=
nstream HTLC with CLTV =3D Y. In order to minimize the safe delta between t=
he upstream and downstream CLTVs, I will want to broadcast and confirm an H=
TLC-timeout transaction as soon after height Y as possible. So assuming tha=
t the downstream settlement transaction is final at height Y and it takes a=
t most D_timeout blocks for the HTLC timeout transaction to confirm once it=
 is final assuming no double spends, then Y + D_timeout is very latest I mi=
ght learn the payment preimage from the downstream channel on-chain. So I s=
hould be safe as long as X - D_success &gt; Y + D_timeout. This assumes tha=
t the update transaction for the downstream channel is already mined and th=
e CSV has passed. However, we know from above that I had to close the upstr=
eam channel at time X - D_success - CSV_update - D_update, which may very w=
ell be before Y. So if the downstream hop waits until just before Y to publ=
ish the preimage, they can force me to close my upstream channel. This appl=
ies transitively for further upstream hops, assuming a large enough CSV val=
ue.</div><div><br></div><div>Granted, upstream hops can watch the blockchai=
n for preimage reveals in other closings transaction and perhaps fulfill of=
f-chain if there is sufficient time. This would not be possible with paymen=
t decorrelation through scriptless scripts or the like.</div><div><br></div=
><div>Does that logic sound right to you?</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Tue, May 1, 2018 at 10:31 AM, Christ=
ian Decker <span dir=3D"ltr">&lt;<a href=3D"mailto:decker.christian@gmail.c=
om" target=3D"_blank">decker.christian@gmail.com</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"><span class=3D"">Jim Posen &lt;<a href=3D"mai=
lto:jim.posen@gmail.com">jim.posen@gmail.com</a>&gt; writes:<br>
&gt; I&#39;m still not following why this doesn&#39;t accumulate.<br>
&gt;<br>
&gt; In the example route, let&#39;s look at it from the point of view of C=
. C sees<br>
&gt; the following regardless of whether D or E or someone behind E is the =
last<br>
&gt; hop in the route:<br>
&gt;<br>
&gt; B -&gt; HTLC(expire =3D X + delta) -&gt; C -&gt; HTLC(expire =3D X) -&=
gt; D<br>
&gt;<br>
&gt; So D is not required to reveal the preimage before time X, and in the =
case<br>
&gt; of an on-chain settle, C needs to be able to redeem the HTLC output th=
rough<br>
&gt; the timeout clause before time X + delta. C can&#39;t redeem the HTLC =
(with<br>
&gt; sufficient confirmations) at least until the settlement transaction is=
<br>
&gt; confirmed. So it seems to me that regardless of the overall route and =
the<br>
&gt; maximum CSV on it, the delta for the C hop has to be greater than the =
CSV<br>
&gt; delay on the update transaction. And that this must be true at every h=
op<br>
&gt; for the same reason.<br>
<br>
</span>That&#39;d be a purely reactionary behavior, i.e., chosing the delta=
 in such<br>
a way that I can both settle the channel and have enough time to react<br>
to turn around and reveal the preimage. So with the assumptions we had<br>
before (CSV =3D 144 and CLTV delta =3D 144) you&#39;d have an effective del=
ta of<br>
288 on each hop, yes. That&#39;s basically the case in which each channel<b=
r>
reacts serially.<br>
<br>
You can trivially parallelize these closures by looking ahead and<br>
noticing that each hop really just cares about its own closure deadline,<br=
>
i.e., each node just cares to close 288 blocks before the CLTV expires,<br>
not that its delta w.r.t. to the downstream channel is that far in the<br>
future. So all we care about is that once we are due to give the<br>
upstream hop the preimage we&#39;ve already closed the downstream channel<b=
r>
and can now read the HTLC preimage from that channel.<br>
<br>
The CSV timeout isn&#39;t part of the delta on each hop, but we need to<br>
implement the deadline computation as:<br>
<br>
```<br>
CLTV - CLTV delta - CSV<br>
```<br>
<br>
instead of LN-penaltiy&#39;s<br>
<br>
```<br>
CLTV - CLTV delta<br>
```<br>
</blockquote></div><br></div>

--0000000000008d9e47056b2ed19d--