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
|
Delivery-date: Sun, 21 Jul 2024 11:04:36 -0700
Received: from mail-qk1-f185.google.com ([209.85.222.185])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDZ3NVEJ5UFBBLE36W2AMGQEKT7JQGQ@googlegroups.com>)
id 1sVavD-000294-UE
for bitcoindev@gnusha.org; Sun, 21 Jul 2024 11:04:36 -0700
Received: by mail-qk1-f185.google.com with SMTP id af79cd13be357-7a199a3eebfsf377437785a.2
for <bitcoindev@gnusha.org>; Sun, 21 Jul 2024 11:04:35 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721585070; cv=pass;
d=google.com; s=arc-20160816;
b=rES5YC1aTb0N8ogjE0oB2VqjtucU2VIb/gr6g9Ds3Yg9dlyyhb3hTlZXqsz/U6jeOQ
fD9qEGOyw1f7HQJ2iNWrqSptSX5LdKnsrBmIDob/gdPCXRSGPfuOkvJ85NaEQckVZv3C
tpuoeWQ/JSjH2any3k4UP3CoTqH3PqTzFkibGxlCd6C9daCOP+8RZ80alZFsqQXB1pmQ
ahWOHafXphE8QpbN9KroEaU+/m98HkeMezDSBBEqkGL4m401sICke5vjDC5r6sVL67WV
XOg6jV4UdGzan/Ww/e9Cd6dhX802bDzPeHvzI5C2L/HLH/73tNxCZbgSIno9xDlLWc3C
/TAw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:content-transfer-encoding
:message-id:references:in-reply-to:subject:cc:to:from:date
:mime-version:sender:dkim-signature;
bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=;
fh=UVebBCZlnoj0ph4dH8fK/isiWBw9egf2QLTfdbvS9nQ=;
b=fZhmHdDS0DxEOhJGjl+FAXg2nUO81TyMAKP2tHTEjUEyr4Bq3hOpxhiIkqYsmbuUIj
F/nWgoiYrozHcvFSdUruBaSCVe45csPHNL1Hj6Sme86XBeE4dE985o+zDjHjUI4kqJtL
3/DoyiEDX1Vq0tbnsmWit3BIvOZT5ZryLw0x/GEpPEKaz7IqJhesbz02lwIqx0Bnumtw
Mv5Dn1llzRInnU6tOSR8qmtDw5mvtxEojfGg1sc/zy0taH6x/9foblp1MClKckcbdy6L
dxLGalOF0gfrPROZzePyhuFh3WddVl6We5z3DFZyvW0hoY1kThV1jCCsSB0UBg+bIuUx
NhiQ==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1721585070; x=1722189870; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:content-transfer-encoding:message-id:references
:in-reply-to:subject:cc:to:from:date:mime-version:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=;
b=up2ED82ar4sUq2LBlyirf3wFN51n2vYUHAqrEqz7fR8dDWVFLJ7QcqI4BdxfEdE0a7
pRZsW0MgQQ/C092hFhepDrRE/9knIJDqidyDSGHzGrYBtznto4PqDiwkukMORJ9O3S+k
JcuNeqZhogVaOyuWB/ezCFdjNw8lm6aGfEZDEbiHNqLII1ItIhkPStBpqrlJDxQ3H+Te
7EzasM+ZwhKTfHHB5rk0lDvrF4QeGvifJV7j7TFueXVwZCAy4/iTRc5CP034h746oiVG
PQv6ro55ChtIFLwbnF1btbQOtEulV5Di92KgDIh8t3xVEf5XYvFp0mCQM85rEkpAyDPg
xNFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1721585070; x=1722189870;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:content-transfer-encoding:message-id:references
:in-reply-to:subject:cc:to:from:date:mime-version:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=oWsTk3RKffKl/SFxypwQEFPz8NJBN0GYLjOR3O0Vu6s=;
b=t08qx0OodZYG3hNJHJPZyuI2FmZprOIUq3pdWNWcW6oR55IMSihPl/E4PTpWysoDfT
iOGprTzmmyNAC51Z3BtMg0MXEPbxlNZPbcj1fhLVaXlxp1WSXEETJdlieEkhmyZDyZcN
JJiratuW1/s8dSwACqp0HvjSGvUD3VpkESgA02pvcY/83S3vn0LdRvdHzN+/9Ui6L5hU
rgCbCSHmVWkGwFsJYw3pc24x2C18eGqLTEJMPyyIjpQstP5ISO2C/uAdzv4sCXjwwu17
kGemaQE9ZDYNhVrkqlGos+oue0iCX9BngPZz3sa2jzJvu4FImB+/Bhz8QJU/jynBJI3G
ia2A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVHp87wkD3EpeD5cXh5LNW9O1Nxone31f0AQqHGeDCQRh4XWMbtNMyQAMMEt1rlrmr/yuor1rVBtw6M9iBFFjvnMcX9SUk=
X-Gm-Message-State: AOJu0YyimvBCtbTT03Q/qx0r/LL0Wdo99IyVStY04iFPelMEUuAVnwP0
MBNdNIM8+2OScP9s+gsOuj2HFL/y+ksJdremp5ye4s19ACwb/pJD
X-Google-Smtp-Source: AGHT+IEfJCA1wgNp74K1yOfmYyZ2Qxg9UEhGKy9C5+tXAbsvICoBJmcMwHhwaSRkCeCE22+/pbPo9w==
X-Received: by 2002:a05:6214:d0e:b0:6b5:4b10:7849 with SMTP id 6a1803df08f44-6b9610d4277mr68401796d6.1.1721585069499;
Sun, 21 Jul 2024 11:04:29 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6214:acf:b0:6b7:8baa:dce3 with SMTP id
6a1803df08f44-6b79b899cfdls101443926d6.2.-pod-prod-00-us; Sun, 21 Jul 2024
11:04:28 -0700 (PDT)
X-Received: by 2002:a05:620a:3181:b0:7a1:417a:9d16 with SMTP id af79cd13be357-7a1a1950277mr19310985a.5.1721585068088;
Sun, 21 Jul 2024 11:04:28 -0700 (PDT)
Received: by 2002:a05:620a:22da:b0:79c:bd3:58c5 with SMTP id af79cd13be357-7a18f14f124ms85a;
Sun, 21 Jul 2024 08:35:36 -0700 (PDT)
X-Received: by 2002:a05:6102:4a8a:b0:48f:40be:3a9e with SMTP id ada2fe7eead31-4928ba389c0mr4560978137.21.1721576135558;
Sun, 21 Jul 2024 08:35:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721576135; cv=none;
d=google.com; s=arc-20160816;
b=fg8Lj1mAAc+HdA23sck+zmaV4hfEr5uGCscNlUPp6Qni+KxIXpHlD/I5GDqJbIn1w+
XbCopHNPG1XuO3RsBNR67/ablGLZ6wzwXYWBVB2jvy86T6e20MLOXr6TBoIADPDp0TRI
E+XI9BfxNXcbCw/OGlB+Xq5H37tnAdP3MOd6zqH+EhTXzFFsIc0pt09uImTfnmr9YgaL
1wWV8gW/bNyafIAUNp5ZpGF+0IetVaAVMWmkdpiOloUpeptQ63X93H5AKyd2dR0yMmf7
7ufx/fYvH+oevNDoD3R80e2mW1amVO78QguyhqwFHgleeUGguaDe0k8g+e9EIC2W4I0D
EGZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:message-id:references:in-reply-to:subject
:cc:to:from:date:mime-version;
bh=/jjNuIAPeH5iR75fqavLIgj5Oo34ruCdwyZ1PhZsADI=;
fh=psWP3UCtCzzPEOUoUzVM9ZZK8adYsTeWDAKCd6L5Zok=;
b=jyLp5hDes7bufEoogylKu25aDwU8TEZI2WoqqI/+C2aBY5UUG4VSjfziSbebzW2uLy
YNLEoBG9F00Zkv59l6uPzfxU8Ia8zYyxQPESZBmsmxWrT6ji3DRz+OgVdTY7RUmoh0ik
Wevdffe3Q6TXfvhsnefOc/fFLgTfAqvLKN+EPVUfy/bCcdcSiq7jKpWZjlsFDK4JZ+cS
6wR7DufBYPBxzvQsp9UHFODxCVPsbsXh7sAztmd+ut6zQQuOZPMjATfqTFRXndiizDXD
MoZAOpmVsTNamUZX3T7q1qxPPT5tHp4QLCjOal4Dk+lm50aDLXcYwc0L0369MWS6S7DX
6rwQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
spf=pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) smtp.mailfrom=dave@dtrt.org
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us. [2607:fe70:0:3::d])
by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-826df49c219si234711241.1.2024.07.21.08.35.34
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 21 Jul 2024 08:35:35 -0700 (PDT)
Received-SPF: pass (google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted sender) client-ip=2607:fe70:0:3::d;
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 897A62800864;
Sun, 21 Jul 2024 08:35:32 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Sun, 21 Jul 2024 08:35:31 -0700 (PDT)
MIME-Version: 1.0
Date: Sun, 21 Jul 2024 05:35:31 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
of Full-RBF In Core
In-Reply-To: <ZpvRvRybauFFnhQV@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<c6593662694f9d4a4fe999dd432f87ff@dtrt.org> <ZpvRvRybauFFnhQV@petertodd.org>
Message-ID: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 490d.669d2ac3.e94f5.0
X-Original-Sender: dave@dtrt.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass
(google.com: domain of dave@dtrt.org designates 2607:fe70:0:3::d as permitted
sender) smtp.mailfrom=dave@dtrt.org
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
On 2024-07-20 05:03, Peter Todd wrote:
> What other "free" relay attacks can you think of that were fixed?
The two you mention were the two I had in mind.
> Did you actually read my One-Shot RBFR proposal?
Yes. It didn't provide any examples of RBFr free relay and I wanted to
see whether a basic RBFr free relay attack would use significantly more,
significantly less, or about the same amount of bandwidth per dollar
spent as other free relay attacks. My conclusion is that it's about the
same.
> Weak blocks are not a solution to any of the "free" relay attacks I've
> disclosed and your source does not claim that they are a "free" relay
> solution.
It does not explicitly say that, but it does say: "bonus use-cases:
=E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-com=
patible but
violate anti-DoS rules".
For example, in some of the scenarios you describe, the attacker sends
an appealing transaction to miners and then sends less appealing
versions of that transaction to relay nodes. If the appealing
transaction enters the top mempool and gets included in a weak block,
relay nodes will stop relaying less appealing variations minutes to
hours before they otherwise would.
Weak blocks also provide a decentralized DoS-resistant mechanism for
voluntarily communicating all sorts of information from miners to other
miners and relay nodes. That makes them an excellent tool for resolving
any attack that depends on miners and relay nodes having a divergent set
of transactions.
> 1) Have you've read my One Shot RBFR proposal? In particular, my
> analysis of DoS attacks *including* existing DoS attacks like
> simultaneous broadcast.
>=20
> 2) Do you agree or disagree with me that these existing DoS attacks
> are real?
Yes, I've read your proposal, and I agree those attacks are plausible.
In my mind, the major difference between those free relay attacks
and RBFR free relay attacks is how solvable they are.
I think it's easy to sketch a significant mitigation to all free relay
attacks (including RBFR):
- Reduce the maximum size of both relayable transactions and in-mempool
packages, e.g. from 100,000 vbytes to 1,000 vbytes.
- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
- Increase the default mempool feerate floor, e.g. from e.g. from 1
sat/vb to 100 sat/vb.
That would break relay of many existing presigned transactions,
potentially leading to money loss, and would break other existing
usecases, not to mention introduce other problems. However, I think
it's sufficient to prove that a mitigation to free relay is possible
without rendering the network unusable.
Of course, an ideal solution wouldn't require placing any additional
constraints on mempool policy. For the case of free relay due to
divergent mempool policies, maybe it's something that could be done with
transaction set reconciliation (~erlay), functions for allowing
independent nodes to come to consistent conclusions about the best
revenue set of transactions (~cluster mempool), P2P relay of non-obvious
cluster linearizations[1], and miners voluntarily committing to their
mempool contents in candidate blocks and P2P relaying those commitments
in weak blocks.
Innovations like that don't work for RBFR. If mempool policy is kept
the same, free relay attacks with RBFR remain equally effective no
matter what mechanisms we implement to improve preconsensus consistency.
If pure RBFR is added and clever protocol developers find ways to
largely fix other free relay attacks, then devs will either need to
significantly restrict mempool policy anyway or will need to restrict or
remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
a very reasonable decision not to add pure RBFR and to wait until better
tools like cluster mempool become available before evaluating
significant changes to RBF policy (like one-shot RBFR).
Thanks,
-Dave
[1]=20
https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r14=
15834695
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/d57a02a84e756dbda03161c9034b9231%40dtrt.org.
|
