1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
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 6FE8AAF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 17:07:25 +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 CCDE36E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 17:07:23 +0000 (UTC)
Received: by mail-qt0-f169.google.com with SMTP id g13-v6so15250826qth.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 May 2018 10:07:23 -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=KfGVPbqfziXbf3iY47lAPIW8ZPTfbhu03WAHWAfGAAQ=;
b=BWKV6mQ3kXFxUOdAVAWe1pKBi+ChAXs1cKdOnES+khthOAiWWTfIOtchK0kPxb+uUm
RM1lPUPEgXICKBikaK8su6XSi3uiXmCu2ZRCvHM/eKVifHr1kD1ij4J4bRtrVXYk41eG
/7nFxsnF7041hqLtVnJoPU6bEiBJE6CLO+r4iRy7S7QUhPFNAfqee8EOVjfykdYO1PMR
kmgW2gMokECKothY4Vs5CRYAIb0i6uok6fdsfN5OqgbebBlNFTiZwl5j6fvmAj3RS0Cn
RNpd7Aqo2H5lv6YkVW5yFwpF423h2T5YhrNMB/ihanUgW19iKV01+cjQdqKsjDUi9Uxg
kHSg==
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=KfGVPbqfziXbf3iY47lAPIW8ZPTfbhu03WAHWAfGAAQ=;
b=FthCKLLMFAyypHmrnVadRum52TE1OVS06x3I+SfAbpWvqWRV3LawLy3mmdu++0e+or
ZAkpFFIMwD8O/0/mSYl7p5xFxp5KWTfZZvp6Jvhbhp9F7vJF2pASk7QSE6yyPzqittZm
Oam9MTFUO0Ebf5qiW5kC0HT/ekaX+z/Svzb6xCses7Qdw5WjBMd9bF8XwlxYn03Q+sOG
xcy+1epnsp86zFQDaC0WZYM02igVmR4TsoPgGSb0OY0mppKAFF6tWVmMG3+eAsiaY8Rp
TVy2bi01akPEDUuXOZAXnM5pJl2xvopB47xxUDGavViKk9uLCJ4aPKhef6m+jwh/7/Sb
zsKA==
X-Gm-Message-State: ALQs6tBZk9vJSQtIyFRHZRHnBGlud9Q9A8NspcW573Z+h5u8yBOLfSaE
r249ZHxiKeXGSIZwdustsZtul8z9h5sKkk8WtmmlY7xc
X-Google-Smtp-Source: AB8JxZrp7lWLgJ3nyvKxhPluBo7mFe0Uu2zaSJMm8Tug8t2fz0jmnUaDgMvTGAymp5KIcBLXZHAo0o4U6Nmt4RyAPLg=
X-Received: by 2002:ac8:35f0:: with SMTP id
l45-v6mr14134245qtb.317.1525194442742;
Tue, 01 May 2018 10:07:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Tue, 1 May 2018 10:07:22 -0700 (PDT)
In-Reply-To: <87in87gx0q.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>
From: Jim Posen <jim.posen@gmail.com>
Date: Tue, 1 May 2018 10:07:22 -0700
Message-ID: <CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f91f89056b2800f2"
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no 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 18:14:17 +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: Tue, 01 May 2018 17:07:25 -0000
--000000000000f91f89056b2800f2
Content-Type: text/plain; charset="UTF-8"
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.
On Tue, May 1, 2018 at 9:29 AM, Christian Decker <decker.christian@gmail.com
> wrote:
> Jim Posen <jim.posen@gmail.com> writes:
> > 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?
>
> Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
> let's assume they all have a CLTV delta of 144 blocks (lnd's default
> setting). Furthermore let's assume that the CSV timeout for the channels
> is also 144.
>
> This means that with the current LN-penalty mechanism you'd have the
> following CLTV deltas in the HTLC:
>
> ```
> A -(576)-> B -(432)-> C -(288)-> D -(144)-> E
> ```
>
> Meaning that if the current time is approaching the absolute CLTV we
> need initiate a channel closure to safely fetch the preimage on-chain,
> and be able to turn around and send it on the upstream channel.
>
> This is minimal, but can be arbitrarily higher, if you follow the best
> practice of obfuscating the final destination by building a shadow route
> behind the real recipient, and add it's CLTV deltas and fees to your
> route.
>
> With eltoo you'd need to make sure that you have the settlement
> transaction confirmed before your desired CLTV timeout delta begins to
> count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV
> delta` you need to initiate a close, whereas Lightning allows you to
> wait for time `now + CLTV delta`. Effectively this results in the
> following time deltas:
>
> ```
> A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E
> ```
>
> Taking the last hop for example, if we had a CLTV of 1000 with eltoo
> we'd need to start closing at height 712, instead of 856 with
> LN-penalty. However, this increased delta does not accumulate along the
> path, it's just a fixed offset. The longer the route, the smaller the
> actual impact of this offset.
>
--000000000000f91f89056b2800f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm still not following why this doesn't accumulat=
e.<div><br></div><div>In the example route, let's look at it from the p=
oint of view of C. C sees the following r<span style=3D"color:rgb(34,34,34)=
;font-family:arial,sans-serif;font-size:small;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline">egardles=
s of whether D or E or someone behind E is the last hop in the route</span>=
:</div><div><br></div><div>B -> HTLC(expire =3D X + delta) -> C ->=
HTLC(expire =3D X) -> D</div><div><br></div><div>So D is not required t=
o 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 be=
fore time X + delta. C can't redeem the HTLC (with sufficient confirmat=
ions) at least until the settlement transaction is confirmed. So it seems t=
o me that regardless of the overall route and the maximum CSV on it, the de=
lta for the C hop has to be greater than the CSV delay on the update transa=
ction. And that this must be true at every hop for the same reason.<br><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, May 1, 2018 a=
t 9:29 AM, Christian Decker <span dir=3D"ltr"><<a href=3D"mailto:decker.=
christian@gmail.com" target=3D"_blank">decker.christian@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Jim Posen &=
lt;<a href=3D"mailto:jim.posen@gmail.com">jim.posen@gmail.com</a>> write=
s:<br>
> Can you explain why a fixed offset along the whole circuit is enough t=
o<br>
> ensure safely as opposed to an increased delta at each hop?<br>
<br>
</span>Sure. Let's assume we have chosen a path `A->B->C->D-&g=
t;E`. For simplicity<br>
let's assume they all have a CLTV delta of 144 blocks (lnd's defaul=
t<br>
setting). Furthermore let's assume that the CSV timeout for the channel=
s<br>
is also 144.<br>
<br>
This means that with the current LN-penalty mechanism you'd have the<br=
>
following CLTV deltas in the HTLC:<br>
<br>
```<br>
A -(576)-> B -(432)-> C -(288)-> D -(144)-> E<br>
```<br>
<br>
Meaning that if the current time is approaching the absolute CLTV we<br>
need initiate a channel closure to safely fetch the preimage on-chain,<br>
and be able to turn around and send it on the upstream channel.<br>
<br>
This is minimal, but can be arbitrarily higher, if you follow the best<br>
practice of obfuscating the final destination by building a shadow route<br=
>
behind the real recipient, and add it's CLTV deltas and fees to your<br=
>
route.<br>
<br>
With eltoo you'd need to make sure that you have the settlement<br>
transaction confirmed before your desired CLTV timeout delta begins to<br>
count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV<br>
delta` you need to initiate a close, whereas Lightning allows you to<br>
wait for time `now + CLTV delta`. Effectively this results in the<br>
following time deltas:<br>
<br>
```<br>
A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E<b=
r>
```<br>
<br>
Taking the last hop for example, if we had a CLTV of 1000 with eltoo<br>
we'd need to start closing at height 712, instead of 856 with<br>
LN-penalty. However, this increased delta does not accumulate along the<br>
path, it's just a fixed offset. The longer the route, the smaller the<b=
r>
actual impact of this offset.<br>
</blockquote></div><br></div></div></div>
--000000000000f91f89056b2800f2--
|
