summaryrefslogtreecommitdiff
path: root/bb/02100081155cd02d6d22e558efc487f56dff20
blob: eca17063fe7a06e84359c1529d813727369aa4df (plain)
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
Delivery-date: Thu, 18 Jul 2024 09:04:32 -0700
Received: from mail-oa1-f63.google.com ([209.85.160.63])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRYHVHZTUGRBCH24S2AMGQELHBICEA@googlegroups.com>)
	id 1sUTcO-0000Wf-6v
	for bitcoindev@gnusha.org; Thu, 18 Jul 2024 09:04:32 -0700
Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-25e7f6bd7a0sf1057427fac.2
        for <bitcoindev@gnusha.org>; Thu, 18 Jul 2024 09:04:31 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1721318666; cv=pass;
        d=google.com; s=arc-20160816;
        b=ixRXS+c1W2KkGQPKK6QJ/6G2QY5qbEutbGarRDQZOplWlswG/2wcvkmhOp3F2RtzPi
         EtA1a+MCQN8lsFnLcrXCXFUbKBKGhYMdwJDSKVkf/dLpqGVV7gTKGGhLZEEiYEBoDt9U
         RwHrZ+cUHjVxCgg+ChgzxBh9GW3ypGVu/o3pNvb+axiU46VTGvHunpCp9aLE7twtsicH
         EbCTLOxpgUpa8cwjt/mtCuoaDfPo1od5kw94WsZ00uok7T1+hnFqRU05P71Ua6SfG5m1
         MjmuqcwVV/TU7JISixp7NmeKOfFbtuFJTtytXW91gbNxgfJmyJWoG+YG9e/ihIlo0sVX
         mD1Q==
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-disposition:mime-version
         :message-id:subject:to:from:date:feedback-id:sender:dkim-signature;
        bh=AgeAOOMQ9A2I3ppK63gxnlbvt1Id1E6X0kFnoEwgJR4=;
        fh=mtBwaEzOoGrZ6xWsIIFcONpBYG/hHYQ7EK5kdZwEJOg=;
        b=xe2d2XrkZ2tZVTOwJyLKVmLceKaOu/2BN5/QDPeahY8BqTzZzEwt5EY/HOMXpSbbjS
         veqx7UyvR91xEXlh43xW6oB3V4f1utfb8IWL/rRaDfRZ6daOxNieomgmArRBL6wUAVll
         Wb+0dW+LH+bie65AEFjMVl8Z28VbMoypzW/rTdrJYojRQDqEH8ncEMOw3MAHiQo6ENic
         VYwrCMpMcyRB0/W9hJIwvns/abY018+yKOjAhfecajZudE6GVOQ5SMt3Txh6i1ZgOIes
         xEuUT7TP7jJm/FPBYB/fRFrSBfj4y2VoitClKGmbCGjyiFQsyE4PVwXj8NMlooMK4TMg
         CC7g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=BnuF8kJl;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721318666; x=1721923466; 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-disposition:mime-version:message-id
         :subject:to:from:date:feedback-id:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=AgeAOOMQ9A2I3ppK63gxnlbvt1Id1E6X0kFnoEwgJR4=;
        b=pNtApxPTz5C9xbkUJ/oQFrqDnvS6HFKe6MOcgR0942DkVwbGKLgNdRuA8Y6IAkdGqC
         oZiYHscJMhBSw+t6Chtqm1cZLVhlm/IG3OXVAPVj81uDF0Y5DS4fpjtbdtet6TU18t84
         MlE9cyZH88Tg+E7RnEt4ZULAW7T16pmM7ypKpruPPthETtRZQGcNCXCDo4vshYqD23zZ
         HS69ZObvML78qOR4PFO7S2oev60RE+G8Km7cwX93s/2AfOSOgHS9OoKIWMeBnJPlkdKL
         xfm6jUBZM+JPS9WDgwHy+DQF5JCxwxfw59V+IfmpLA3ozVBHnjG+t5QzXxQkkXUixlb4
         0GXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721318666; x=1721923466;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-disposition:mime-version:message-id
         :subject:to:from:date:feedback-id:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=AgeAOOMQ9A2I3ppK63gxnlbvt1Id1E6X0kFnoEwgJR4=;
        b=tQEPmgAJKmZWRT2KId+hhIamOG5hcwhAP0DeBE/muXbG3uqqu5P1IyyZ16nNfYDYKd
         gOtUEYtWYW+a3BgeVIBFV72Lj7tfGFOPe91I2P012AqTIxqEqie1pqcQujoXRUx6ksDw
         0n+5GBnsGTdMY/KaJguwiZivobxeWCT1LrEP3zLq2O3O87eosm34gifDxM51gq+zhQF8
         Zo6ec0YSQyXgerQUNT+pMIhMe6RQ3ocpGajsm8cGuLqGIYzsBQ6/7FPGagQBOUtd/aIo
         WjslyfyBXQUF1YRts0z71ACPKggtnr3AXovynbTJ0vwiTwD8TvP9/P2mn7zppg5BRbah
         56GQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWcgbW2OgOgrlOUKg9A37EqguJag+m9aUL0dsoOpX/Y24iQabliVIUwM3lSJygeKMK/M7Ooop+TCJskxb33wIaU8c0E3fg=
X-Gm-Message-State: AOJu0YyOJJQ9NLb9hQHa9vt2pHQ6jMaCv993nq/z0aQqA+yAQpxypRHs
	5zWHPV5sUDpVYBCxf9JK7ozNKe0yRJy4amz2kNx13cvEKP9YsEkW
X-Google-Smtp-Source: AGHT+IETUEBGIdskJFvAy7WqPSDWFyfYzxeqfhuhglbP4D3H+j+O8UWDfbzM9DVNLHnslQU6TgAwRA==
X-Received: by 2002:a05:6870:148c:b0:260:3fb2:b724 with SMTP id 586e51a60fabf-260d9505869mr4543622fac.46.1721318665813;
        Thu, 18 Jul 2024 09:04:25 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6870:9f06:b0:25c:ac6e:8806 with SMTP id
 586e51a60fabf-260ec487065ls578591fac.1.-pod-prod-00-us; Thu, 18 Jul 2024
 09:04:24 -0700 (PDT)
X-Received: by 2002:a05:6808:15a5:b0:3d9:23ad:2002 with SMTP id 5614622812f47-3dad7370a04mr84420b6e.0.1721318664185;
        Thu, 18 Jul 2024 09:04:24 -0700 (PDT)
Received: by 2002:a05:6808:984:b0:3d9:302f:bb85 with SMTP id 5614622812f47-3dadf171cc3msb6e;
        Thu, 18 Jul 2024 08:56:06 -0700 (PDT)
X-Received: by 2002:a05:6830:4486:b0:708:d860:e51b with SMTP id 46e09a7af769-708e37862e7mr6230327a34.15.1721318165235;
        Thu, 18 Jul 2024 08:56:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1721318165; cv=none;
        d=google.com; s=arc-20160816;
        b=adguW8EYzxccWv9yJrPujv7z51/dA4530GWaKsGyIQnfk4pQuLjwL0a/CVa4u8HJ2+
         4SgCsfdrlphIZA8tTuNPZVgnAjaVcCXafh8EqAxO0PCE/HdbEEl9uDTr9bn+HIQPMTZ+
         zxntvlmSNFkSodDKL/gXO+wXvrllf/3HieTOmRdHXeJYNKrupCEVghSrEK5hR3/lYl+7
         9jQa/0/1mgginMHpFFoNbYPGZIyREL8BEauuv8BNUy0Ef+yETPr0lGmayGmhcU/j28eQ
         EhnKBAO8wxluTz8xSZthRD37Y5RAE/PeQ3fezsLBvX6BmvVgCT4ljR4l9+okNomoW+jN
         DVqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-disposition:mime-version:message-id:subject:to:from:date
         :feedback-id:dkim-signature;
        bh=5Gi716z3gZ6zhwTtLg0C1/cCtLDXeln9DOGHjz2ACZc=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=sR25k9ZZPHtq+GLVaYZGlZy6QS7Ct6gvyYJZnFspqYNW+27cytO3kaZ/tL/l2ue06u
         TNfzjSMBxffozmI1QzaCpNEtWA2qHqF6fo7ox19ScA3UAhAkLYst+oaJuzKq8JiXAtN/
         xEuhtQpkbPN15CijzgFZNQdwhg4TwPvZb/14wyOVuoTNyyhvqdgk+eS4B+ncwfguGfyh
         7im6PG0hkFw5PqyvSIyx8E2b0lZU26VAG9ToPOKoIUZt9Y9KW1A/3llvn3PKG9/iXOgV
         H6arBA2qTYaMUgnnkJ6vYjeKrytNEqpHXUKkWKLPH2sqQabjE9K6sZ3HhbM5+etYEOY4
         o7cg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=BnuF8kJl;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com. [103.168.172.151])
        by gmr-mx.google.com with ESMTPS id 46e09a7af769-708e7932dbesi125862a34.5.2024.07.18.08.56.04
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 18 Jul 2024 08:56:05 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) client-ip=103.168.172.151;
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailfout.nyi.internal (Postfix) with ESMTP id 526C61380180
	for <bitcoindev@googlegroups.com>; Thu, 18 Jul 2024 11:56:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute4.internal (MEProxy); Thu, 18 Jul 2024 11:56:04 -0400
X-ME-Sender: <xms:EzuZZuMRIvmjkvNs0P_0iUzbdrHkFBsjvD4CT3-jWo8oxorxAgXu8g>
    <xme:EzuZZs-rzU5URfKNrW2m8VHTNPV0XjbyWdIURf32KDKD5KkPLKeABRD-yNu2mUy0V
    UBTzchlW-SV1v8luj4>
X-ME-Received: <xmr:EzuZZlR5IjI4HVaUrt__yb60TPp6c0QXtCWH52dTiFHd5wmhkYu5Lxg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeelgdelgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc
    fjughrpeffhffvuffkgggtugesghdtreertddtvdenucfhrhhomheprfgvthgvrhcuvfho
    ugguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrhhnpe
    ekhfevkeffjeefuefghfelhffhleffvdfgfeehieelkeejtdehffetieefvdfgleenucff
    ohhmrghinhepghhoohhglhgvrdgtohhmpdhgihhthhhusgdrtghomhdpphgvthgvrhhtoh
    guugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:EzuZZuuMAkj07LYrdy8Huqwvo9-RKpuope3UUb0pRJm3Oj7fyiJCcQ>
    <xmx:EzuZZmfmmOIhBM3oQ0JIgkceViH3TlkSWV8d8hjBcBfXQCWQ-LvlhA>
    <xmx:EzuZZi1A9RPtoLRfiLaKEUjE-z-e5FsxuAn0LkdCkmgpqjW4B3W2wQ>
    <xmx:EzuZZq9SLnmrH7a-evNzXcCHzeWRlwUqHaxTGvVkYx6S1WOILQjZkQ>
    <xmx:FDuZZl7oj13gJCQSigxr5MmIMJwidB-VVYJtmvu2QAwYEIjdyuC5Tj5b>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 <bitcoindev@googlegroups.com>; Thu, 18 Jul 2024 11:56:02 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
	id 72E4E5F83F; Thu, 18 Jul 2024 15:56:01 +0000 (UTC)
Date: Thu, 18 Jul 2024 15:56:01 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of
 Full-RBF In Core
Message-ID: <Zpk7EYgmlgPP3Y9D@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="2hJOODXU2lgKGZoa"
Content-Disposition: inline
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@messagingengine.com header.s=fm2 header.b=BnuF8kJl;       spf=pass
 (google.com: domain of pete@petertodd.org designates 103.168.172.151 as
 permitted sender) smtp.mailfrom=pete@petertodd.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 (/)


--2hJOODXU2lgKGZoa
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

# Summary

This is a public disclosure of a vulnerability that I previously disclosed to
the bitcoin-security mailing list. It's an easy vulnerability to fix. Although
as with other "free" relay attacks I've disclosed, I didn't get a substantive
response from Bitcoin Core, other than Core closing the my pull-req enabling
full-RBF by default that would fix this specific vulnerability.

But read on, this is quite an odd case of Core politics, and the story is not
as simple as Core refusing to fix a vulnerability. Also, I've including a fun
homework problem at the end: figure out how TRUC/V3 transactions itself creates
a "free" relay attack.


# Background

This is just one of a few "free" relay attacks that I have recently disclosed,
including, but not limited to:

    "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024
    https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg

    "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 2024
    https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo

The term "free relay attack" simply refers to any mechanism where transaction
data can be broadcast at unusually low cost; the "free" in "free relay" is a
misnomer as all these attacks do in fact have some cost.

This particular attack isn't significantly different than the other attacks
I've disclosed. With one important exception: unlike those other attacks,
fixing this particular attack would be quite easy, by enabling full-rbf by
default. So I disclosed it to the bitcoin-security mailing list as a test: does
Bitcoin Core actually care about free relay attacks? My hypothesis is that Core
does not, as they know full well that "free" relay is an unavoidable problem;
I've received absolutely no feedback from any Bitcoin Core members for the
other disclosed attacks, beyond achow using my disclosure of the RBF Rule #6
attack as an excuse to remove me from the bitcoin-security mailing list.

The fact that Core doesn't actually care about "free" relay attacks is relevant
to TRUC/V3 Transactions. As per BIP-431:

    "The primary problem with [RBFR proposals] is the potential for free relay and DDoS attacks.

    Removing Rule 3 and 4 in general would allow free relay [27]."
    https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate

I believe the authors of that BIP are fully aware of the fact that "free" relay
is an unavoidable problem, making their rational for TRUC/V3 bogus, and don't
want to admit that they've wasted a large amount of engineering time on a bad
proposal. I will be submitting a pull-req to get BIP-431 corrected, as the many
"free" relay attacks I've disclosed clearly show that claiming RBFR would
"allow" free relay is simply not true.

Notably, full-RBF is _itself_ a transaction pinning fix for many use-cases;
part of the TRUC/V3 standard is to force full-RBF behavior for V3 transactions.
So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a second
way, and TRUC/V3 proponents were the ones who tried to get the full-RBF option
removed from Core in the first place. If not for this dumb bit of Core
politics, I'm sure my year-old pull-req to enable full-RBF by default would
have been merged many months ago, as almost all hashpower has adopted full-RBF
making objections based on "zeroconf" absurd.


# The Attack

If you're a competent Bitcoin engineer, familiar with how mempools work, you've
probably figured it out already based on the title: obviously, if a high
percentage of miners are adopting a policy that Bitcoin Core nodes are not, you
can cheaply consume transaction relay bandwidth by simply relaying transations
that miners are rejecting.

Specifically, do the following:

1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
3. Spend the outputs of A in a large, low fee-rate, transaction B with BIP-125
   opt-in enabled. ~100% of miners will reject B, as it spends an input not in
   their mempools. However Bitcoin Core nodes will waste bandwidth propagating
   B.
4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will waste
   bandwidth propagating Bn's that ~100% of miners are ignoring.
5. Double-spend A2 to recover your funds and do it all over again (or if A2 had
   a high enough fee-rate, just wait for it to be mined).

The cost to relay each B transaction depends on the fee-rate of B. Since
Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-rate is
typically well below the economic fee-rate required for miners to actually mine
a transaction; Core accepts transactions that are uneconomical for miners to
mine for the forseeable future.

For example, at the moment typical mempools require transactions to pay at
least 1sat/vB, while there are hundreds of MvB worth of transactions paying
4sat/vB, the minimum economical fee-rate. Thus, transactions paying less than
4sat/VB are extremely unlikely to get mined in the nearish future.

Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB would
have almost zero cost as the probability of those transactions getting mined is
nearly zero. This is true _regardless_ of what % of miners are mining full-RBF!
As long as you can get at least one miner to mine the A double-spend, the
attack only costs what it cost to get A mined.

If B's are broadcast at a higher fee-rate than the minimum economical fee-rate,
then the % of full-RBF miners matters. For example, if only 99% of miners mine
full-RBF, the chance of a B transaction getting mined per block is about 1%, so
the amortized cost of broadcasting B is about 1% of whatever total fee the
highest fee-rate variant of B pays.

For an attacker who does not need any B to be broadcast, the cost savings to
use of relay bandwidth is approximately the ratio of the difference in size
between B and and A. With a maximum standard transaction size of 100KvB, or
400KB serialized size, this ratio is on the order of 5000:1, times the total
number of B variants broadcast, and the % chance of each B being mined; it's a
few orders of magnitude.

Of course, as mentioned above, this is just one of *many* "free" relay attacks,
so fixing this particular issue doesn't change much.


# Attackers Who Benefit From B Getting Mined

Some attackers actually need B to get mined. For example, imagine an exchange
who needs to do large consolidation transactions. They could use this attack
(and some attacks like it) as a way to goad users and miners into mining
consolidation transactions for them at low cost. In this variant of the attack,
the attacker would pad the size of B with consolidation spends that they needed
to do anyway. Someone who tried to stop the attack by getting B mined (eg via
mempool.space's transaction accellerator) would simply be paying the attacker's
fees for them.

Obviously, this strategy is only relevant for B's below the economic fee-rate.
However, the weaker version of this strategy is to parallize the attack, and do
your consolidation with the _A_ double-spends to reduce the # of bytes used per
full-rbf double-spend.


# TRUC/V3 Creates a Free Relay Attack

I'll leave the details of this as a homework problem. But obviously, the
introduction of TRUC/V3 transactions *itself* creates a free relay attack very
similar to the above! Just like full-RBF, not all miners will mine V3
transactions. So you can do the exact same type of attack by taking advantage
of this difference in mining policy.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zpk7EYgmlgPP3Y9D%40petertodd.org.

--2hJOODXU2lgKGZoa
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaZOwkACgkQLly11TVR
LzdtZA//XFnrI1Z4KIkwQ6mb9Vo9QZKn189xf4JZOkCv50F21zYDbQ0nufd0/C+4
QghsFBJqpWz/TG4VYioC3Z8OdyEcxV0y3ZFwq8huy9VK/Fyv66F+HYO8I9U2hO1M
yooRs+OzOhXMJFoTZF1tHc67EPAsclhqNXmlm7jlzmRx74joTY9dRxqAshT+768J
GQw/9hTlMiHRJfhUq5en4N2zbI187EdjFJzHbpcc1Pe4qZVVInMap0mkfpq7TbGl
leDHUgTZARPDpTGwNF29Om5UkIlJcm1I+VPi7mtglqjyqGihJvks+BqSVrT7JTd3
sJNaB9ZNtXzgv5BOmrNum/2p90TXLkdEKOyXBJScfnv4SYeVE78IiYvrCl7EsN3a
o2j5ITW3j42aOro4Za0oSRIDFTPOCaKJ9+TtN5h/COWfBNpF1lI1xDBKIEKUHK35
aNptK5CL1BDiXPkiY/ilGRYyYR8ADc0PvBcMgEm8y58H/t+dYDictbQoMJdfbbj0
RE4gCbKFp8gEe2X+pV4/5R3fwCFCmy8hZeUJHeXWzSVCM/DKO1k1KfEpQ7Cedkd7
G5MYYoCt4mjWvV7mqdOmDhmbpQZqk9M4zh6lhXGZvAZWo4yHYWkwuAA7BMvnua+k
ns23Pgp3otGZSazvehSWPy3shM9vOp4MRlAdcmhbMgWvRBvdgSQ=
=MWTI
-----END PGP SIGNATURE-----

--2hJOODXU2lgKGZoa--