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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Return-Path: <nadav@shesek.info>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id DC207C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 04:36:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 6441C21507
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 04:36:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NGvvIlv1EcMr
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 04:36:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com
[209.85.208.193])
by silver.osuosl.org (Postfix) with ESMTPS id F107D2107F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 04:36:04 +0000 (UTC)
Received: by mail-lj1-f193.google.com with SMTP id q19so4987465lji.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2020 21:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=/h48OFhY54Fy5lq/g9dLrpdQ6v6ojB3mz6ztcp5ksY8=;
b=FHVRGXh5l4kdWknfmEh475CtTcqso1puhNHUYkSj+/2VlqzP2h1wtUKbHFSZKrRHms
UM9DVjS/eb6cY5vSrZd5HPFle/Vp8E9ii2piEVO76MxWty/9L9zGyCxhsJTorPsNG0YI
tOjRhLkK96wlq988nXQghG5cv2I529/+4MMv8=
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=/h48OFhY54Fy5lq/g9dLrpdQ6v6ojB3mz6ztcp5ksY8=;
b=Zhmy/jHHhzKEc4sIf35C5N4iykqMzX4hK0fZEmbeHpFXm177PqAOKohTQts0rdioRZ
7BkpcbfR4bKifyiQDCBhPsN3zS6ewDwqbQLiYhK7w9oc8el9A0CvUETxvcJUessKCfe6
6yK0CB0qkJljYgbZE8aajHsiGD1SQQR9XCurAFZUrk19V+MV4yUERtwSRBUxxe90rGUi
wzCAwaOQZ1SanfXqNGZrMfX7JJkUJHEnSB0YR6pwTe7K1EOGl3oZBASkzNjy4mOW3kWw
MVnweSZzxnXwxRJQZuuD1OsurFIWdv3+srbyat8M+C9RiLPZtzeQcqUNkUrF2S8S1THw
+phw==
X-Gm-Message-State: AOAM532wn1Quut6AYZO5yjCMEFbuaNiMS6Dn3Rt7EdzPMA64bAcrOVla
NHVj2EdEwsKAQ0u23s8BwFzsbLQ3drxaTTIB3ayhoQ==
X-Google-Smtp-Source: ABdhPJyHRaxEJfs9eZbfd15UGuwV84J6AOmKq0MnPkakZPvjLxbNhxLtO+sOUdQtvy7TPwnis7aXfMWjKhyrIznM880=
X-Received: by 2002:a2e:b8ce:: with SMTP id s14mr14820423ljp.89.1593059762880;
Wed, 24 Jun 2020 21:36:02 -0700 (PDT)
MIME-Version: 1.0
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
<CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
<ahTHfoyyTpBrMiKdJWMn9Qa8CMCEd1-y8OXPSjsDmttTOVC3zGuDoSHkm_oOe5mBYgIAY7jOPocQhLW29n544xFsqVyq51NFApvaFYYSvFY=@protonmail.com>
<CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.gmail.com>
<CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com>
<xFJlIP6z6qhjxDAP8xUBnqPF-Wulexjr9izry8mIWCQzQdNrULtX_TwWGfuHo7VNfTdXZNmy05QHxMF3iJbjZm_-jFO_WRJjSQR0N_Dreic=@protonmail.com>
<CAGXD5f0PXDMbVMiUNnqK-HGwB1yDEmBQgtLbQU4xcad3pDaGmw@mail.gmail.com>
<XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com>
In-Reply-To: <XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Thu, 25 Jun 2020 07:35:51 +0300
Message-ID: <CAGXD5f25Y180WoVhh+PnNP6pF_fHE1DbRqDJp_vaLz58+-5=8g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000463bfa05a8e12126"
X-Mailman-Approved-At: Thu, 25 Jun 2020 12:45:36 +0000
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 25 Jun 2020 04:36:07 -0000
--000000000000463bfa05a8e12126
Content-Type: text/plain; charset="UTF-8"
Hi ZmnSCPxj,
You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.
You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
her transaction confirmed in order to have a valid bribery fraud. This
seems workable if the time frame was long enough (over a few hours should
be sufficient, assuming we consider reorgs of over 3-4 blocks to be
unlikely), but could indeed be problematic if the time frame is already
short to begin with.
Nadav
On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Nadav,
>
> > > I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
> >
> > An additional disincentive could be introduced in the form of bribery
> proofs for failed attempts.
> >
> > If we assume that "honest" users of the LN protocol won't reveal their
> timelocked transactions before reaching the timelock expiry (they shouldn't
> anyway because standard full node implementations won't relay them), we can
> prove that Bob attempted bribery and failed to an outside observer by
> showing Bob's signed timelocked transaction, spending an output that was in
> reality spent by a different transaction prior to the locktime expiry,
> which should not be possible if Bob had waited.
>
>
> Unfortunately this could be subject to an inversion of this attack.
>
> Alice can wait for the timelock to expire, then bribe miners to prevent
> confirmation of the Bob timelocked transaction, getting the Alice
> hashlocked transaction confirmed.
>
> Now of course you do mention "prior to the locktime expiry" but there is
> now risk at around locktime.
>
> Particularly, "natural" orphaned blocks and short-term chainsplits can
> exist.
> Bob might see that the locktime has arrived and broadcast the signed
> timelocked transaction, then Alice sees the locktime has not yet arrived
> (due to short-term chainsplits/propagation delays) and broadcast the signed
> hashlocked transaction, then in the end the Alice side of the short-term
> chainsplit is what solidifies into reality due to random chance on which
> miner wins which block.
> Then Bob can now be accused of bribery, even though it acted innocently;
> it broadcasted the timelock branch due to a natural chainsplit but Alice
> hashlocked branch got confirmed.
>
> Additional complications can be added on top to help mitigate this edge
> case but more complex == worse in general.
> For example it could "prior to locktime expiry" can ignore a few blocks
> before the actual timelock, but this might allow Bob to mount the attack by
> initiating its bribery behavior earlier by those few blocks.
>
> Finally, serious attackers would just use new pseudonyms, the important
> thing is to make pseudonyms valuable and costly to lose, so it is
> considered sufficient that LN nodes need to have some commitment to the LN
> in the form of actual channels (which are valuable, potentially
> money-earning constructs, and costly to set up).
>
> Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris
> Belcher, could use similar disincentivizing; I know Chris is planning a
> fidelity bond system for SwapMarket makers, for example, which would mimic
> the properties of LN channels (costly to set up, money-earning).
>
> Regards,
> ZmnSCPxj
>
--000000000000463bfa05a8e12126
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi ZmnSCPxj,</div><div><br></div><div>You are of cour=
se correct. I=20
had considered the effect of reorgs, but the email seemed to be getting=20
too lengthy to mention that too.<br></div><div><br></div><div>You would=20
need a few spare blocks in which Bob won't be accused of bribery as a=
=20
safety margin, which does reduce the time frame in which Alice can get=20
her transaction confirmed in order to have a valid bribery fraud. This=20
seems workable if the time frame was long enough (over a few hours=20
should be sufficient, assuming we consider reorgs of over 3-4 blocks to=20
be unlikely), but could indeed be problematic if the time frame is=20
already short to begin with.</div><font color=3D"#888888"><div><br></div><d=
iv>Nadav</div></font></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj <<a href=
=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Nad=
av,<br>
<br>
> > I and some number of Lightning devs consider this to be sufficien=
t disincentive to Bob not attacking in the first place.<br>
><br>
> An additional disincentive could be introduced in the form of bribery =
proofs for failed attempts.<br>
><br>
> If we assume that "honest" users of the LN protocol won'=
t reveal their timelocked transactions before reaching the timelock expiry =
(they shouldn't anyway because standard full node implementations won&#=
39;t relay them), we can prove that Bob attempted bribery and failed to an =
outside observer by showing Bob's signed timelocked transaction, spendi=
ng an output that was in reality spent by a different transaction prior to =
the locktime expiry, which should not be possible if Bob had waited.<br>
<br>
<br>
Unfortunately this could be subject to an inversion of this attack.<br>
<br>
Alice can wait for the timelock to expire, then bribe miners to prevent con=
firmation of the Bob timelocked transaction, getting the Alice hashlocked t=
ransaction confirmed.<br>
<br>
Now of course you do mention "prior to the locktime expiry" but t=
here is now risk at around locktime.<br>
<br>
Particularly, "natural" orphaned blocks and short-term chainsplit=
s can exist.<br>
Bob might see that the locktime has arrived and broadcast the signed timelo=
cked transaction, then Alice sees the locktime has not yet arrived (due to =
short-term chainsplits/propagation delays) and broadcast the signed hashloc=
ked transaction, then in the end the Alice side of the short-term chainspli=
t is what solidifies into reality due to random chance on which miner wins =
which block.<br>
Then Bob can now be accused of bribery, even though it acted innocently; it=
broadcasted the timelock branch due to a natural chainsplit but Alice hash=
locked branch got confirmed.<br>
<br>
Additional complications can be added on top to help mitigate this edge cas=
e but more complex =3D=3D worse in general.<br>
For example it could "prior to locktime expiry" can ignore a few =
blocks before the actual timelock, but this might allow Bob to mount the at=
tack by initiating its bribery behavior earlier by those few blocks.<br>
<br>
Finally, serious attackers would just use new pseudonyms, the important thi=
ng is to make pseudonyms valuable and costly to lose, so it is considered s=
ufficient that LN nodes need to have some commitment to the LN in the form =
of actual channels (which are valuable, potentially money-earning construct=
s, and costly to set up).<br>
<br>
Other HTLC-using systems, such as the "SwapMarket" being proposed=
by Chris Belcher, could use similar disincentivizing; I know Chris is plan=
ning a fidelity bond system for SwapMarket makers, for example, which would=
mimic the properties of LN channels (costly to set up, money-earning).<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--000000000000463bfa05a8e12126--
|