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
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
|
Return-Path: <bastien.teinturier@acinq.fr>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B2BEDC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2020 07:35:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id A190788124
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2020 07:35:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CGhegAqzSXY0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2020 07:35:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
[209.85.210.43])
by whitealder.osuosl.org (Postfix) with ESMTPS id 148F2880E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2020 07:35:33 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id g7so12256239oti.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2020 00:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=acinq-fr.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=VeMPtwqBThO2+VyzsKlAOVeW0CUM7UkM4Lq26n86nsc=;
b=d9oUvq8B4+Ma3mSxX+/vn76LibnAM+u7aim03dgZXDMmUd3m10mkl9n6hroMKtc8y/
5LftonLzeuTKepcFOD/dwgRr+QJ9JoYpZjlje+NtBEVG46XIEwrWlbbryOtBeboiou8o
bF+DZui2T5nRlCmhLhWuacLAaAou5PCBeMMrQPgJRRu84AFcoEqxrCM3TIpHTtTupOYc
/sMTW9xrGu6graFqf6N7L5L5XUhncgDgprSmSnTfdjEj8e90BfbpTTnYO1Nuav0XUdA/
VxIR7FZHDyJijY86iM2p4aMJwAShDXa7Ic5cSjXjOmuPWi1SUn8wm8OsvaZE5+GeV9rS
8lYg==
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=VeMPtwqBThO2+VyzsKlAOVeW0CUM7UkM4Lq26n86nsc=;
b=namuDTEBsUxazCnu1EUew35kXDQ+MePRNCRLBVM24su72IrMLNbJyDeAt9ExuiX9nQ
59fHuA6aOs3SwgSsgT7v5LORjCMsm/J7Vi/AQ+GPCITzrj4kgsTb3yAnqtdAbkHeK9pE
6eAt1IilPHVUixeg898XCfu8NL847D7ZpShmPS1Ivb9LJUAR3E1qmZ3rfejLaL1LgY84
R2+65t+tkJ5jccs1dbZ8AvFWA0CDzKmukPQn04SlJFHQSSiic+kzAVQ8dEMFwDE09iXM
kV+oqr1EE78nT2Bq0F5J+7WGqEtyAZS4gjZGUODlpcPnigJaz1vQ8GlxPzSXkZC6tZCW
ilfA==
X-Gm-Message-State: AOAM533eyMdzTHVhAVFXRbuGkaUR7zVhLImUWLvfe8tPGWCoYqfo6bMg
uZF9aOtq9NvDzO0cIH7zr0astKqiGoE+mFoCDgnvSVysSB4=
X-Google-Smtp-Source: ABdhPJw6djHS3YgdAA5j4lgzBgF/lBAJ22wKowgXY9svJXy6cPk+C5YOHDNk2ff5xwMfKRNQiMBkz3POBARb3dGqxmk=
X-Received: by 2002:a9d:6d8c:: with SMTP id x12mr12626180otp.86.1592811332022;
Mon, 22 Jun 2020 00:35:32 -0700 (PDT)
MIME-Version: 1.0
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
<67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
<62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
<4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>
<CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>
<20200619195846.fclw4ilngvbbf2kk@ganymede>
<20200619205220.fshbr7pbijaerbf2@ganymede>
<CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com>
<20200620103647.g62srlcxbjqpaqj6@ganymede>
In-Reply-To: <20200620103647.g62srlcxbjqpaqj6@ganymede>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Mon, 22 Jun 2020 09:35:20 +0200
Message-ID: <CACdvm3NTY1UYWJg=SJm+TAZSi5RophxhRvze9gKi9PyEHx0PgA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000a3c3c405a8a749c4"
X-Mailman-Approved-At: Mon, 22 Jun 2020 11:03:50 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
and Competing Interest
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: Mon, 22 Jun 2020 07:35:34 -0000
--000000000000a3c3c405a8a749c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks for the detailed write-up on how it affects incentives and
centralization,
these are good points. I need to spend more time thinking about them.
This is one reason I suggested using independent pay-to-preimage
> transactions[1]
>
While this works as a technical solution, I think it has some incentives
issues too.
In this attack, I believe the miners that hide the preimage tx in their
mempool have
to be accomplice with the attacker, otherwise they would share that tx with
some of
their peers, and some non-miner nodes would get that preimage tx and be
able to
gossip them off-chain (and even relay them to other mempools).
If they are actively helping the attacker, they wouldn't spend the
pay-to-preimage tx,
unless they gain more from it than the share the attacker gives them. This
becomes
a simple bidding war, and the honest user will always be the losing party
here (the
attacker has nothing to lose). For this reason I'm afraid it wouldn't work
out in practice
as well as we'd hope...what do you think? And even if the honest user wins
the bidding
war, the attack still steals money from that user; it just goes into the
miner's pocket.
But from the perspective of a single LN node, it
> might make more sense to get the information and *not* share it
>
I think it depends. If this attack becomes doable in practice and we see it
happening,
LN routing nodes and service providers have a very high incentive to thwart
these attacks,
because otherwise they'd lose their business as people would leave the
lightning network.
As long as enough nodes think that way (with "enough" being a very hard to
define quantity),
this should mitigate the attack. The only risk would be a big "exit scam"
scenario, but the
coordination cost between all these nodes makes that scenario unlikely
(IMHO).
Thanks,
Bastien
Le sam. 20 juin 2020 =C3=A0 12:37, David A. Harding <dave@dtrt.org> a =C3=
=A9crit :
> On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> > We're simply missing information, so it looks like the only good
> > solution is to avoid being in that situation by having a foot in
> > miners' mempools.
>
> The problem I have with that approach is that the incentive is to
> connect to the highest hashrate pools and ignore the long tail of
> smaller pools and solo miners. If miners realize people are doing this,
> they may begin to charge for information about their mempool and the
> largest miners will likely be able to charge more money per hashrate
> than smaller miners, creating a centralization force by increasing
> existing economies of scale.
>
> Worse, information about a node's mempool is partly trusted. A node can
> easily prove what transactions it has, but it can't prove that it
> doesn't have a certain transaction. This implies incumbent pools with a
> long record of trustworthy behavior may be able to charge more per
> hashrate than a newer pools, creating a reputation-based centralizing
> force that pushes individual miners towards well-established pools.
>
> This is one reason I suggested using independent pay-to-preimage
> transactions[1]. Anyone who knows the preimage can mine the
> transaction, so it doesn't provide reputational advantage or direct
> economies of scale---pay-to-preimage is incentive equivalent to paying
> normal onchain transaction fees. There is an indirect economy of
> scale---attackers are most likely to send the low-feerate
> preimage-containing transaction to just the largest pools, so small
> miners are unlikely to learn the preimage and thus unlikely to be able
> to claim the payment. However, if the defense is effective, the attack
> should rarely happen and so this should not have a significant effect on
> mining profitability---unlike monitoring miner mempools which would have
> to be done continuously and forever.
>
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/0026=
64.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/0026=
67.html
> [3] https://bitcoinops.org/en/topics/op_checksigfromstack/
>
> > Do you think it's unreasonable to expect at least some LN nodes to
> > also invest in running nodes in mining pools, ensuring that they learn
> > about attackers' txs and can potentially share discovered preimages
> > with the network off-chain (by gossiping preimages found in the
> > mempool over LN)?
>
> Ignoring my concerns about mining centralization and from the
> perspective of just the Lightning Network, that doesn't sound
> unreasonable to me. But from the perspective of a single LN node, it
> might make more sense to get the information and *not* share it,
> increasing your security and allowing you to charge lower routing fees
> compared to your competitors. This effect would only be enhanced if
> miners charged for their mempool contents (indeed, to maximize their
> revenue, miners might require that their mempool subscribers don't share
> the information---which they could trivially enforce by occasionally
> sending subscribers a preimage specific to the subscriber and seeing if
> it propagated to the public network).
>
> > I think that these recent attacks show that we need (at least some)
> > off-chain nodes to be somewhat heavily invested in on-chain operations
> > (layers can't be fully decoupled with the current security assumptions
> > - maybe Eltoo will help change that in the future?).
>
> I don't see how eltoo helps. Eltoo helps ensure you reach the final
> channel state, but this problem involves an abuse of that final state.
>
> -Dave
>
--000000000000a3c3c405a8a749c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for the detailed write-up on how it affects incenti=
ves and centralization,<div>these are good points. I need to spend more tim=
e thinking about them.<div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">This is one reason I suggested using independent pay-to-preimag=
e<br>transactions[1]<br></blockquote><div><br></div><div>While this works a=
s a technical solution, I think it has some incentives issues too.</div><di=
v>In this attack, I believe the miners that hide the preimage tx in their m=
empool have</div><div>to be accomplice with the attacker, otherwise they wo=
uld share that tx with some of</div><div>their peers, and some non-miner no=
des would get that preimage tx and be able to</div><div>gossip them off-cha=
in (and even relay them to other mempools).</div><div><br></div><div>If the=
y are actively helping the attacker, they wouldn't spend the pay-to-pre=
image tx,</div><div>unless they gain more from it than the share the attack=
er gives them. This becomes</div><div>a simple bidding war, and the honest =
user will always be the losing party here (the</div><div>attacker=C2=A0has =
nothing to lose). For this reason I'm afraid it wouldn't work out i=
n practice</div><div>as well as we'd hope...what do you think? And even=
if the honest user wins the bidding</div><div>war, the attack still steals=
money from that user; it just goes into the miner's pocket.</div><div>=
<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But from =
the perspective of a single LN node, it<br>might make more sense to get the=
information and *not* share it<br></blockquote><div><br></div><div>I think=
it depends. If this attack becomes doable in practice and we see it happen=
ing,</div><div>LN routing nodes and service providers have a very high ince=
ntive to thwart these attacks,</div><div>because otherwise they'd lose =
their business as people would leave the lightning network.</div><div><br><=
/div><div>As long as enough nodes think that way (with "enough" b=
eing a very hard to define quantity),=C2=A0</div><div>this should mitigate =
the attack. The only risk would be a big "exit scam" scenario, bu=
t the</div><div>coordination cost between all these nodes makes that scenar=
io unlikely (IMHO).</div><div><br></div><div>Thanks,</div><div>Bastien</div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>Le=C2=A0sam. 20 juin 2020 =C3=A0=C2=A012:37, David A. Harding <<a href=
=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>> a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jun 20, 2020 at=
10:54:03AM +0200, Bastien TEINTURIER wrote:<br>
> We're simply missing information, so it looks like the only good<b=
r>
> solution is to avoid being in that situation by having a foot in<br>
> miners' mempools.<br>
<br>
The problem I have with that approach is that the incentive is to<br>
connect to the highest hashrate pools and ignore the long tail of<br>
smaller pools and solo miners.=C2=A0 If miners realize people are doing thi=
s,<br>
they may begin to charge for information about their mempool and the<br>
largest miners will likely be able to charge more money per hashrate<br>
than smaller miners, creating a centralization force by increasing<br>
existing economies of scale.<br>
<br>
Worse, information about a node's mempool is partly trusted.=C2=A0 A no=
de can<br>
easily prove what transactions it has, but it can't prove that it<br>
doesn't have a certain transaction.=C2=A0 This implies incumbent pools =
with a<br>
long record of trustworthy behavior may be able to charge more per<br>
hashrate than a newer pools, creating a reputation-based centralizing<br>
force that pushes individual miners towards well-established pools.<br>
<br>
This is one reason I suggested using independent pay-to-preimage<br>
transactions[1].=C2=A0 Anyone who knows the preimage can mine the<br>
transaction, so it doesn't provide reputational advantage or direct<br>
economies of scale---pay-to-preimage is incentive equivalent to paying<br>
normal onchain transaction fees.=C2=A0 There is an indirect economy of<br>
scale---attackers are most likely to send the low-feerate<br>
preimage-containing transaction to just the largest pools, so small<br>
miners are unlikely to learn the preimage and thus unlikely to be able<br>
to claim the payment.=C2=A0 However, if the defense is effective, the attac=
k<br>
should rarely happen and so this should not have a significant effect on<br=
>
mining profitability---unlike monitoring miner mempools which would have<br=
>
to be done continuously and forever.<br>
<br>
ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2]=C2=A0 I=
was<br>
hoping one of Bitcoin's several inventive cryptographers would come<br>
along and describe how someone with an adaptor signature could use that<br>
information to create a pubkey that could be put into a transaction with<br=
>
a second output that OP_RETURN included the serialized adaptor<br>
signature.=C2=A0 The pubkey would be designed to be spendable by anyone wit=
h<br>
the final signature in a way that revealed the hidden value to the<br>
pubkey's creator, allowing them to resolve the PTLC.=C2=A0 But if that&=
#39;s<br>
fundamentally not possible, I think we could advocate for making<br>
pay-to-revealed-adaptor-signature possible using something like<br>
OP_CHECKSIGFROMSTACK.[3]<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/20=
20-April/002664.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html</a><br>
[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/20=
20-April/002667.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html</a><br>
[3] <a href=3D"https://bitcoinops.org/en/topics/op_checksigfromstack/" rel=
=3D"noreferrer" target=3D"_blank">https://bitcoinops.org/en/topics/op_check=
sigfromstack/</a><br>
<br>
> Do you think it's unreasonable to expect at least some LN nodes to=
<br>
> also invest in running nodes in mining pools, ensuring that they learn=
<br>
> about attackers' txs and can potentially share discovered preimage=
s<br>
> with the network off-chain (by gossiping preimages found in the<br>
> mempool over LN)?<br>
<br>
Ignoring my concerns about mining centralization and from the<br>
perspective of just the Lightning Network, that doesn't sound<br>
unreasonable to me.=C2=A0 But from the perspective of a single LN node, it<=
br>
might make more sense to get the information and *not* share it,<br>
increasing your security and allowing you to charge lower routing fees<br>
compared to your competitors.=C2=A0 This effect would only be enhanced if<b=
r>
miners charged for their mempool contents (indeed, to maximize their<br>
revenue, miners might require that their mempool subscribers don't shar=
e<br>
the information---which they could trivially enforce by occasionally<br>
sending subscribers a preimage specific to the subscriber and seeing if<br>
it propagated to the public network).<br>
<br>
> I think that these recent attacks show that we need (at least some)<br=
>
> off-chain nodes to be somewhat heavily invested in on-chain operations=
<br>
> (layers can't be fully decoupled with the current security assumpt=
ions<br>
> - maybe Eltoo will help change that in the future?).<br>
<br>
I don't see how eltoo helps.=C2=A0 Eltoo helps ensure you reach the fin=
al<br>
channel state, but this problem involves an abuse of that final state.<br>
<br>
-Dave<br>
</blockquote></div>
--000000000000a3c3c405a8a749c4--
|