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
|
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 1192971F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 14:12:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4C0A6682
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 14:12:34 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id y189-v6so4638465wmc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 07:12:34 -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=2+unz6kVjoUm7XC6ZFXauWbH9z8IHhrfErZ/ayPyYlQ=;
b=UAbB9T48/fkBYVRFA7l1xL+8BLndApvxHciyOQ7Qp3Itx1nG1uuRWA51fl7LSJCmzL
eIXjnsS9YQ0FzmW3yQtQuFl2Peia84pn1xeXQJT5NaFizMX8kkfwkmp9u7J8jxKXxZdh
n4J8u4VtNruiUtHA4rtTq4H1fKkfN9rt+wT/oi6qDSZLUwepO3kd4H8mbmtg2FfVD++R
68ZRO6+qp7KP0j8PNDZYRpEguJAwEi62Nq92QEzS3Vs9GuXxRxBPyYWOBys1nPzx1x2+
sjlDtxXGSsLbipL+jbrOKetwUZA8oqb890TSBm9+WWodrscOFobI51zFEKJ9r/ApkgWs
Zsng==
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=2+unz6kVjoUm7XC6ZFXauWbH9z8IHhrfErZ/ayPyYlQ=;
b=tKy7rleWzgBvex0g5vYsAhvL9H1H/sAP/FrDkZxfHZszIlTSOLH44RQsTy8QLRNWTC
DOm1GcEF4R6DYVNNqNtnN8imJF/gAhAxvP3chu0L08HnKTjcWN8Oja31ruEq43uN29S9
/i3q7btOAFXQTLkJGbLCu9rQHfYMO7abS/GbT71kqGaB0+GP52gmcmN/Un4Tq+pNueTq
ix1M1KHwUoSWBVtNM5CHuEocAwUuVSwno/BDp/NBiHM+T5rNITTVVWibQBPqsF4CcDnP
Ea2sQx9wkLMihLrmQocq37K3tFcS+z7cp/oklSrRQJY3693yXLc1pFqzoTRCz/AueXys
kYDw==
X-Gm-Message-State: ALKqPwfLf6aY6EYFo5+L4BygQCEjhoBwDJReVlN7U+M6F7eTJL4QP82j
E2McsGa4gnIIwFoF4xwMLO4=
X-Google-Smtp-Source: AB8JxZoTta8BaPtC+20NJsB4KjGdpWPdgWmqFuJci29+G7rp3J1StFqa7eNKKmu9mhkI39qDsR7Yxw==
X-Received: by 2002:a1c:4406:: with SMTP id r6-v6mr1283957wma.99.1525961552788;
Thu, 10 May 2018 07:12:32 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9])
by smtp.gmail.com with ESMTPSA id
c18-v6sm1484702wmd.13.2018.05.10.07.12.30
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 10 May 2018 07:12:31 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Jim Posen <jim.posen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAO3Pvs8mf-X4T7fJOgZ9L8uSS3vKhZyvJ1SxL=gbk6b96QuMow@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>
<87bmdzgu4v.fsf@gmail.com>
<CADZtCSgHmyYbumDw6bwfYpoqc9b-0JmHM5-22=Y1FXNDiTghrA@mail.gmail.com>
<CAO3Pvs8mf-X4T7fJOgZ9L8uSS3vKhZyvJ1SxL=gbk6b96QuMow@mail.gmail.com>
Date: Thu, 10 May 2018 15:57:30 +0200
Message-ID: <87603v4nqt.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: Thu, 10 May 2018 14:12:35 -0000
Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> writes:
> Hi Jimpo,
>
> You're correct that the introduction of symmetric state now
> re-introduces the dependency between the CSV value of the commitment,
> and the HTLC timeouts. It's worth nothing that this issue existed in
> an earlier version of the BOLT spec, this was pointed out by Mats in
> the past: [1][2]. The dependency meant that if we wanted to allow very
> long CSV time outs (like 1 month +), then this would have the adverse
> effect of increasing the total CLTV timeout along the entire route. As
> a result, we moved to the 2-stage HTLC scheme which is now implemented
> and deployed as a part of BOLT 1.0. It may be the case that in the mid
> to near future, most implementations aren't concerned about long time
> locks due to the existence of robust and reliable private
> outsourcers.
It's worth mentioning that the requirement for extremely large CLTV deltas
would already create incredibly long CLTV deltas between the endpoints,
since the endpoint delta accumulates along the path. This is true for
LN-Penalty as well as eltoo. eltoo's requirement to settle before the
HTLCs touch the blockchain adds a stage in which need to start on-chain
settlement to ensure the HTLC hits the chain before its CLTV
expires. We can imagine this as a separate timewindow, that does not
accumulate across multiple hops (settlement ordering is not an issue,
CLTV resolution is).
My hope is that indeed with the simpler watch-towers we can reduce both
the CLTV deltas as well as the settlement timeouts for eltoo, so that
they become negligible.
> As a side effect of the way the symmetric state changes the strategy
> around breach attempts, we may see more breach attempts (and therefore
> update transactions) on the chain since attempting to cheat w/ vanilla
> symmetric state is now "costless" (worst case we just use the latest
> state, best case I can commit the state better for me. This is in
> stark contrast to punishment/slashing based approaches where a failed
> breach attempt results in the cheating party losing all their funds.
Not exactly costless, since the breaching party will have to pay the
on-chain fees, and we may be able to reintroduce the reserve in order to
add an additional punishment on top of the simple update mechanism
(selectively introducing asymmetry).
> However, with a commitment protocol that uses symmetric state. The
> 2-stage HTLC scheme doesn't actually apply. Observe that with
> Lighting's current asymmetric state commitment protocol, the "clock"
> starts ticking as soon as the commitment hits the chain, and we follow
> the "if an output pays to me, it must be delayed as I may be
> attempting a breach". With symmetric state this no longer applies, the
> clock instead starts "officially" ticking after the latest update
> transaction has hit the chain, and there are no further challenges. As
> a result of this, the commitment transaction itself doesn't need to
> have any CSV delays within the Script branches of the outputs it
> creates. Instead, each of those outputs can be immediately be spent as
> the challenge period has already elapsed, and from the PoV of the
> chain, this is now the "correct" commitment. Due to this, the HTLC
> outputs would now be symmetric themselves, and look very much like an
> HTLC output that one would use in a vanilla on-chain cross-chain
> atomic swap.
In addition to this it is worth pointing out that the old/replaced HTLCs
have no way of ever touching the blockchain, so we can throw away a
whole heap of data about these HTLCs, that we would have to carry around
indefinitely if this were not the case. The same reason the HTLCs start
ticking when a settlement touches the chain in LN-penalty is also the
reason we need to carry all that data around. eltoo can be said to
contain the two stage HTLC commit we added on top of LN-penalty.
Cheers,
Christian
|
