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
|
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 AEA9D3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 12:05:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com
[209.85.128.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25157672
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 May 2018 12:05:11 +0000 (UTC)
Received: by mail-wr0-f177.google.com with SMTP id p18-v6so10645828wrm.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 May 2018 05:05:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=XS40y9iOiyXH9bWbciqIAJmY6BNwN7R7xUAjUiLjgco=;
b=tH42fPDGPDG3Id/emNNLEnDrI1qibTWvAyc+osJvaNnZlcpzBSynTpTf2RQOYNkFY6
hONrpep1TiQFtoHNlYmRIK1UWcIYiyeWg38emb2mzqq+w/ETwmjLrRdJi8TB6Nfmhz9s
PVJ4LhfAPlLbie3TH2ITTOxdrqz+ANNm5GeO4oySjbPQ/TGErnmBmd9NWvDHqveSehJW
kAVXTPrlOgbc407Wh8X3ZKSmd30w0Ftgk+pTfbrPuL1Xv0WxW8kFs1A5qqe9In5PeExy
B80/MPDs+NK/+53xZxv+RcxRhLF/zSTKBIL16eSom+lhyb3ZMZVEqW5kr50MY4lB7z+c
qqwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=XS40y9iOiyXH9bWbciqIAJmY6BNwN7R7xUAjUiLjgco=;
b=KV+UeTefrqAyio+V8ONcORhtyYhHb/IxXvndmKVl5u83EN7v5k+zGFiJn41eJWOpVW
SUovG5w+HQzHumu7FNxSdEa2TAspY70/N5lTCMQSaNAfvwUaHwWkD+QQaBVzkWTBRMb/
fQ/iMWXGcHPKxC68hvf069QwQdfFp+WeBf0rKS4KHqwJvkxOiYOhszyugPQfXlmUfxB7
Ys6tlmK7boMI6oIArBNAEX4RZpYuie2qz1avD/4MZb5Zf4+Sut0JceVkmUlxKc6EWbpf
T7mAR3z2Ug9iGEgQ9lduuZHzGok16py6hDpaelvOK4kxshf3kGjoUt5N3oYe3ESRGO8A
oDWg==
X-Gm-Message-State: ALQs6tC/nx0SqyWS0M0yDOrgC0fPNC1IwM3YnjMjcvrM9xjV0SqF3Yj1
z9P5KmxTNwBJ34uz/UY0PGo=
X-Google-Smtp-Source: AB8JxZpoASZU8cnGU10jS50HLGfa4UIX1uZDKZ8H/XVMB9436ccSKxcffTvD5royhpN9a8ABESrQqQ==
X-Received: by 2002:adf:9745:: with SMTP id
r63-v6mr12211177wrb.57.1525176309814;
Tue, 01 May 2018 05:05:09 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
u10sm10195349wme.12.2018.05.01.05.05.08
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 01 May 2018 05:05:08 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Jim Posen <jim.posen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
References: <874ljsitvx.fsf@gmail.com>
<CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
Date: Tue, 01 May 2018 13:36:32 +0200
Message-ID: <87vac7hakf.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
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 12:05:11 -0000
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) :-)
|
