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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id B220AC016F;
Wed, 24 Jun 2020 08:39:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id ACF008887C;
Wed, 24 Jun 2020 08:39:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kx3813by7Q0r; Wed, 24 Jun 2020 08:39:00 +0000 (UTC)
X-Greylist: delayed 00:06:04 by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by hemlock.osuosl.org (Postfix) with ESMTPS id AB44D88809;
Wed, 24 Jun 2020 08:39:00 +0000 (UTC)
Received: from [IPv6:2620:6e:a007:235::1] (unknown [IPv6:2620:6e:a007:235::1])
by mail.as397444.net (Postfix) with ESMTPSA id C87CE28E7DF;
Wed, 24 Jun 2020 08:32:53 +0000 (UTC)
Content-Type: multipart/alternative;
boundary=Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 24 Jun 2020 01:32:52 -0700
Message-Id: <034FCF40-B7D3-46F8-8746-98083CB0461E@mattcorallo.com>
References: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com>
In-Reply-To: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com>
To: Bastien TEINTURIER <bastien@acinq.fr>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (17F80)
Cc: 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: Wed, 24 Jun 2020 08:39:01 -0000
--Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Given transaction relay delays and a network topology that is rather transpa=
rent if you look closely enough, I think this is very real and very practica=
l (double-digit % success rate, at least, with some trial and error probably=
50+). That said, we all also probably know most of the people who know enou=
gh to go from zero to doing this practically next week. As for motivated fol=
ks who have lots of time to read code and dig, this seems like something wor=
th fixing in the medium term.
Your observation is what=E2=80=99s largely led me to conclude there isn=E2=80=
=99t a lot we can do here without a lot of creativity and fundamental rethin=
king of our approach. One thing I keep harping on is maybe saving the blind-=
CPFP approach with a) eltoo, and b) some kind of magic transaction relay met=
adata that allows you to specify =E2=80=9Cthis spends at least one output on=
any transaction that spends output X=E2=80=9D so that nodes can always appl=
y it properly. But maybe that=E2=80=99s a pipedream of complexity. I know An=
toine has other thoughts.
Matt
> On Jun 22, 2020, at 04:04, Bastien TEINTURIER via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>=20
> =EF=BB=BF
> Hey ZmnSCPxj,
>=20
> I agree that in theory this looks possible, but doing it in practice with a=
ccurate control
> of what parts of the network get what tx feels impractical to me (but mayb=
e I'm wrong!).
>=20
> It feels to me that an attacker who would be able to do this would break *=
any* off-chain
> construction that relies on absolute timeouts, so I'm hoping this is insan=
ely hard to
> achieve without cooperation from a miners subset. Let me know if I'm too o=
ptimistic on
> this!
>=20
> Cheers,
> Bastien
>=20
>> Le lun. 22 juin 2020 =C3=A0 10:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :
>> Good morning Bastien,
>>=20
>> > Thanks for the detailed write-up on how it affects incentives and centr=
alization,
>> > 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 incentive=
s 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 w=
ith 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).
>>=20
>> I believe this is technically possible with current mempool rules, withou=
t miners cooperating with the attacker.
>>=20
>> Basically, the attacker releases two transactions with near-equal fees, s=
o that neither can RBF the other.
>> It releases the preimage tx near miners, and the timelock tx near non-min=
ers.
>>=20
>> Nodes at the boundaries between those that receive the preimage tx and th=
e timelock tx will receive both.
>> However, they will receive one or the other first.
>> Which one they receive first will be what they keep, and they will reject=
the other (and *not* propagate the other), because the difference in fees i=
s not enough to get past the RBF rules (which requires not just a feerate in=
crease, but also an increase in absolute fee, of at least the minimum relay f=
eerate times transaction size).
>>=20
>> Because they reject the other tx, they do not propagate the other tx, so t=
he boundary between the two txes is inviolate, neither can get past that bou=
ndary, this occurs even if everyone is running 100% unmodified Bitcoin Core c=
ode.
>>=20
>> I am not a mempool expert and my understanding may be incorrect.
>>=20
>> Regards,
>> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">Given transaction relay de=
lays and a network topology that is rather transparent if you look closely e=
nough, I think this is very real and very practical (double-digit % success r=
ate, at least, with some trial and error probably 50+). That said, we all al=
so probably know most of the people who know enough to go from zero to doing=
this practically next week. As for motivated folks who have lots of time to=
read code and dig, this seems like something worth fixing in the medium ter=
m.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Your observation is what=
=E2=80=99s largely led me to conclude there isn=E2=80=99t a lot we can do he=
re without a lot of creativity and fundamental rethinking of our approach. O=
ne thing I keep harping on is maybe saving the blind-CPFP approach with a) e=
ltoo, and b) some kind of magic transaction relay metadata that allows you t=
o specify =E2=80=9Cthis spends at least one output on any transaction that s=
pends output X=E2=80=9D so that nodes can always apply it properly. But mayb=
e that=E2=80=99s a pipedream of complexity. I know Antoine has other thought=
s.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Matt</div><div dir=3D"lt=
r"><br><blockquote type=3D"cite">On Jun 22, 2020, at 04:04, Bastien TEINTURI=
ER via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<br><=
br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<d=
iv dir=3D"ltr">Hey ZmnSCPxj,<div><br></div><div>I agree that in theory this l=
ooks possible, but doing it in practice with accurate control</div><div>of w=
hat parts of the network get what tx feels impractical to me (but maybe I'm w=
rong!).</div><div><br></div><div>It feels to me that an attacker who would b=
e able to do this would break *any* off-chain</div><div>construction that re=
lies on absolute timeouts, so I'm hoping this is insanely hard to</div><div>=
achieve without cooperation from a miners subset. Let me know if I'm to=
o optimistic on</div><div>this!</div><div><br></div><div>Cheers,</div><div>B=
astien</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">Le lun. 22 juin 2020 =C3=A0 10:15, ZmnSCPxj <<a href=
=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> a =C3=A9=
crit :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good m=
orning Bastien,<br>
<br>
> Thanks for the detailed write-up on how it affects incentives and centr=
alization,<br>
> these are good points. I need to spend more time thinking about them.<b=
r>
><br>
> > This is one reason I suggested using independent pay-to-preimage<b=
r>
> > transactions[1]<br>
><br>
> While this works as a technical solution, I think it has some incentive=
s issues too.<br>
> In this attack, I believe the miners that hide the preimage tx in their=
mempool have<br>
> to be accomplice with the attacker, otherwise they would share that tx w=
ith some of<br>
> their peers, and some non-miner nodes would get that preimage tx and be=
able to<br>
> gossip them off-chain (and even relay them to other mempools).<br>
<br>
I believe this is technically possible with current mempool rules, without m=
iners cooperating with the attacker.<br>
<br>
Basically, the attacker releases two transactions with near-equal fees, so t=
hat neither can RBF the other.<br>
It releases the preimage tx near miners, and the timelock tx near non-miners=
.<br>
<br>
Nodes at the boundaries between those that receive the preimage tx and the t=
imelock tx will receive both.<br>
However, they will receive one or the other first.<br>
Which one they receive first will be what they keep, and they will reject th=
e other (and *not* propagate the other), because the difference in fees is n=
ot enough to get past the RBF rules (which requires not just a feerate incre=
ase, but also an increase in absolute fee, of at least the minimum relay fee=
rate times transaction size).<br>
<br>
Because they reject the other tx, they do not propagate the other tx, so the=
boundary between the two txes is inviolate, neither can get past that bound=
ary, this occurs even if everyone is running 100% unmodified Bitcoin Core co=
de.<br>
<br>
I am not a mempool expert and my understanding may be incorrect.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundation.org</sp=
an><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/span><br></div></blockquote></body></html>=
--Apple-Mail-4ABBA549-16A1-4375-AFE1-69D9BBC13056--
|
