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
|
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 6E8DD723
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 15:50:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com
[209.85.216.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A79C682
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 15:50:39 +0000 (UTC)
Received: by mail-qt0-f171.google.com with SMTP id f13-v6so5231856qtp.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 May 2018 08:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=dJrxS4qLiTqdaA2beCTDaBFg5H2F7I+Nqo1ppjIRD3k=;
b=VnBZZnN/xFLkD+NG0e3AfYcYx7lfvhRN38frpyRwecD8yidG2KaLrp5QRRt+lJLRY+
Ua1s9gh3I9ft3IdNaPL+ZzkSzLf4RFVF4aA3A5WO74SnqAZxT5vAysDs3uvLHsfMFE7F
F2GxjnJGnUPh0l7WAGq9v/eVKg7IoCVI4giK6ufIAYJY4DlfUNp0LV1sgsKLLIy3t5D+
HHKszr/xvzRqVEK4a4PLl4uxlvUqSY0sqzpPnlfj3si+uIOe4Oe3jH7lzfoln3Pt3pgE
ySJYxoYt0aDd2jN7SEPlzpEpf7NWEfntTk5JFM5Ejr4TZz0QYQLYs5XBQdrclNnj7ebL
mHzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=dJrxS4qLiTqdaA2beCTDaBFg5H2F7I+Nqo1ppjIRD3k=;
b=tjhWa/oY7ZHhZjzykTSlV+WSpCAJh50nwdrS3ZRWsbxb64x+5L/vvFE6r06SEHaYxW
g5I9BHzrE9/0BV1SsCnqCI6EKs+G6U9SdH7c7Q3p6XRoxSTM3NioZUGwgLM6y93Vog7Q
g9ngTPW7lh0FDSsmC2ryn1xb4XFwwsW+FNLXa3eC7GfSstxXgdzikVYhTV2GvBdW/v/x
Cb2+VG3YhiL8D21UzwX6+5ImgQZ6ffqzPMVSAgn0QrVtY5pyqlTBoecSprTgl3+3giJ3
Vecaxon76cCJ1+xJtQHl6x6CfdP5xVyEFDuxi+sb/SuRQYJ4iEPyaCtDRbEt8L8z4g5u
6D4g==
X-Gm-Message-State: ALQs6tAroTJdzVWEE5hzOMQYsd16y7ixOIUUhAOApvjoRflFbVhwLH+Q
5i9ckLpN7ozQ0JvaMlBVPB6kpHLY8J1ZRrxnJ6Q=
X-Google-Smtp-Source: AB8JxZo5y80NEiVTdOShgqE/kYI1bxNUG0x0n/uUFf7SQPKnizlSHOqehTT3RWMLsIPMrq15ZGcoax45swXSUC0n1hQ=
X-Received: by 2002:ac8:35f0:: with SMTP id
l45-v6mr14036662qtb.317.1525189838503;
Tue, 01 May 2018 08:50:38 -0700 (PDT)
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"
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 15:57:21 +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 15:50:40 -0000
--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 <<a href=3D"mailto:decker.christian@gmail.com">d=
ecker.christian@gmail.com</a>> 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 <<a href=3D"mailto:jim.posen@gmail.com" target=3D"_blank=
" rel=3D"noreferrer">jim.posen@gmail.com</a>> writes:<br>
> If my understanding is correct though, this construction would<br>
> significantly increase the safe CLTV delta requirements because HTLCs<=
br>
> cannot be timed out immediately on the settlement transaction. Conside=
r a<br>
> case where node B receives an HTLC from A and forwards to C. If the HT=
LC<br>
> offered to C times out and C does not fail the HTLC off-chain, Lightni=
ng<br>
> currently guarantees that the CLTV delta is sufficient that I may clos=
e the<br>
> channel to C on-chain and claim the timed-out HTLC before my upstream =
HTLC<br>
> to A times out. If the CLTV delta is too small, I may fail the upstrea=
m<br>
> HTLC as soon as it times out, and then C may still claim the downstrea=
m<br>
> HTLC with the preimage on-chain. With eltoo, when B closes the downstr=
eam<br>
> channel on-chain, it must wait the CSV timeout on the update transacti=
on<br>
> before locking in the timed-out HTLC. This effectively means the CLTV =
delta<br>
> has to be greater than the CSV timeout, plus some extra (whereas it is=
<br>
> currently safe to make it significantly shorter). Is that true or am I=
<br>
> missing something?<br>
<br>
That'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'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'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'd argue that it's a n=
et<br>
positive for the Lightning network (but then again I'm biased) :-)<br>
</blockquote></div>
--0000000000008a045e056b26ee59--
|
