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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 838CB982
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 17:31:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com
[209.85.128.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAB1934F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 17:31:38 +0000 (UTC)
Received: by mail-wr0-f176.google.com with SMTP id g21-v6so11413645wrb.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 May 2018 10:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version; bh=Hbjr9CkuUwcKvomkNYzzXKs6LpejoFv1zMaRZcCBt90=;
b=oVx5qJ11++h+ctsRIRVvJhG4SI8tspt0do7nPkw05RnaslCPwKtG5nEG5ibggnPbMf
J5d2XqX/Z/1cVUNNJz/wyGnIlj5klcL7Y+zXLufMYrqQQ8TrDb+Px19Ww3K8/zenligP
nETn7q5Ncq3QUl4neiDf65cMuJm06YNQQ9+MYG4QHpJYl5ZwydM1LefFiR6deowlPR0Z
gadzVhCTFHn6tbpXNRFXExZebNEs8D/bmmrBQUriR7JDIYr1gMrm0m/S0zOf2MQ20fYf
e5i/Oy9hW2rAf2z6gRCajJCicyJjwJZYEiO9dxyiyt1U4ipQJcfCWtlknRdph8QhT3GH
ufAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version;
bh=Hbjr9CkuUwcKvomkNYzzXKs6LpejoFv1zMaRZcCBt90=;
b=OKOFkybuDI6xSiUhHwwVawsfvu9d2i30jFMMJhbmN12w/xNpqRUf0VrxpexSeBkrNZ
kJcYIYSvNeQ1PsPVcGK2oNEp9ie7JPzEgtbqROyb5Lmx6u8DPffOuj0nKZ8XZQnu1UCn
HZ9AkiOt36ljIjrfKBeoh/A/jDQ4i3q7k1leOoFAxNgNKiMbiBkfuGK3V0kHYp0g+8wo
hCpKl6WD78wUsBo9lhi1pVUM3IFLSbKz+pRfHbmtQRTN+cW+AJUjYUt2BU12H+i9WuhB
UOGOEdyxo+q8sL+Bf+EQ5sK7evHpLJvho3acpQLn23y6Maetba+r4WYdk5hfj9HXt07Q
EDtw==
X-Gm-Message-State: ALQs6tCumgGCtOYmZ/nODiq09KuJEvQTmUhH5DE8x4/Bw0NKOcEcQvjM
sZa6wVHbN7lIekUwxF8xZWo=
X-Google-Smtp-Source: AB8JxZpTGxWRtwg1o2MvtahjD47Ix1seo7+MotxNnLeCU5q7HtHu5zXwQ0sM7Me+T9nlpTuxzWZUSA==
X-Received: by 2002:adf:b839:: with SMTP id
h54-v6mr12311198wrf.141.1525195897619;
Tue, 01 May 2018 10:31:37 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
i10sm11102876wmf.24.2018.05.01.10.31.36
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 01 May 2018 10:31:36 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Jim Posen <jim.posen@gmail.com>
In-Reply-To: <CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.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>
Date: Tue, 01 May 2018 19:31:28 +0200
Message-ID: <87bmdzgu4v.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
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:31:39 -0000
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
```
|
