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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id D223FC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 10:26:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7BBCC8224A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 10:26:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7BBCC8224A
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=messagingengine.com header.i=@messagingengine.com
header.a=rsa-sha256 header.s=fm1 header.b=ZbkyTXos
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id G7uHe_8-CJbe
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 10:26:06 +0000 (UTC)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp1.osuosl.org (Postfix) with ESMTPS id 60B7C8223B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 10:26:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 60B7C8223B
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.nyi.internal (Postfix) with ESMTP id 3F3985C0102
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Aug 2023 06:26:02 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Wed, 16 Aug 2023 06:26:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
:message-id:mime-version:references:reply-to:sender:subject
:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm1; t=1692181562; x=1692267962; bh=TllDayObbcLSt
/pUHBPrZTV2O87YdYJ+6jvhVy0pCbA=; b=ZbkyTXosWBL+YkV7QiyIeBgLjZNz8
+wq2gnblPfkmPsNt4vzSnUQu2GqQkVHYiJHdQZh//9mRQzsnH0HfinCQzxmtkd3u
VieFkDpqxVKjgBz3Fbz0aHZGBQMW7FMHnxbDDZRNDuF+lu+w6pElad6Ef2XyTzs1
7lrGESLWuyVgbXk7pg6+u2zU2nvRTOKR0AwaNGig/GIQHAsIGiMKladjTZkSLxAk
zCJq9RvVqM/4uISQBMJ0IEINmwo97CzLKiYxXvA2GwctyupejxMkLMb2q3Q7W8tr
Ldhkr3RIpwBgpGojVGDWXeRa0RFUXs+jul8jCLSZ/ucG6s8pvJsA1fsgA==
X-ME-Sender: <xms:OaTcZG7XKDpanivoYUQL1nsn1v7VMldKJ63k2dsCnP_xIdQN_3gnig>
<xme:OaTcZP6pTrpCriJ-2tCFzK3l_ocdLKdCC_Fs2h430ZYwJ7Q0I30mg7ZvRlTXc-T_Y
kRBBCNDsFHyR5nvBYg>
X-ME-Received: <xmr:OaTcZFftwPFpaGIWAUiWGKPuJ2m0kQopZfowxMRAu1ARzfJYqoQFPAMa>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtledgvdekucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeihfeljeevvdfhteetheeutdfgieehue
ekheeiuefggeekudefffduvdeufeefleenucffohhmrghinhepghhithhhuhgsrdgtohhm
pdguohhusghlvghsphgvnhgurdhphidpshhtrggtkhgvrhdrnhgvfihspdhpvghtvghrth
houggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf
rhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:OaTcZDKkeMd0OpF87KH2Xx4F74xvyTo_a2kJ7xmANgtGtvH58jMRLA>
<xmx:OaTcZKKZPkhxQC3RC1BpvWTkMINTupPpzwZRPQUIasYwZSvRC0VoYQ>
<xmx:OaTcZEyS7Z7_Wp53fDteW5bux36HrlOcsdxUBmz1e59pMqNnhxhL2A>
<xmx:OqTcZBV5ssCViAwukWA2CiPZeHukwb1KZXUWLk1ztiIcvtL_93-Bbw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bitcoin-dev@lists.linuxfoundation.org>; Wed,
16 Aug 2023 06:26:01 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
id 969965F843; Wed, 16 Aug 2023 10:25:58 +0000 (UTC)
Date: Wed, 16 Aug 2023 10:25:58 +0000
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZNykNtFb/mMfk79L@petertodd.org>
References: <CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gmail.com>
<CACkWPs-jW-bae2oywp-LswFhmWhNAFZEFg7M=rXLi6nMGLUgRw@mail.gmail.com>
<ZMuhsGj+tsv+xBzW@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="cgm7x1PMMzBjvME4"
Content-Disposition: inline
In-Reply-To: <ZMuhsGj+tsv+xBzW@petertodd.org>
Subject: [bitcoin-dev] Full-RBF testing: at least 31% of hash power,
over at least 4 pools, is mining full-RBF right now
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, 16 Aug 2023 10:26:10 -0000
--cgm7x1PMMzBjvME4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,
I've been doing high-fee full-RBF testing to re-confirm my findings.
Specifically, that means sending a high fee tx1 with a fee more than suffic=
ient
to get mined in the next block. Then 30 seconds later, I send tx2, a double
spend with an even higher fee, removing one of tx1's outputs. Propagation w=
as
verified for each full-RBF double-spend by checking debug.log on another ve=
ry
well-connected node.
Results: >31% of hash power, over at least 4 different pools, is mining
full-RBF at the moment, assuming Binance Pool is mining full-RBF with half
their hashing power (see below for details). This finding confirms my OTS
calendar research, which found similar results.
Specifically, in my testing yesterday I successfully did the following full=
-RBF
double-spends:
Antpool: 2ebe68edca320dabdd8b39ebae5f18efaac829055058a2c0f4bc2b37c69cd88c
dac9895795efa3956cc775b4f48a5d2b01fa0ea0d7a915fa350baa4779d2e0e9
b7d43485bf8f0f9792ba6889ab2f53fb462aa4997f3995d9d027375993fa7907
e2cd91093399dcad5ad3fd73627e497c5e808434ecc7aaec13d9d488973f099c
5bb7e7d6c34dfd2ae65466a2968a0e500ef25d9b70f7f2b299203dffc1a1b10d
ad7d2f74eab240726604dfd66231f52ac7778567028cf818387dc9395474f63b
1ddb11bad477e8b5bcdb36dbaa26065ae8e3c37b39b37a2b34780b98274bd076
f16bb35670b66ab3c8ccbbaf5f06da5f311e9b05a02b23a77a6fec5e8e5951a4
b6123a7c126b7937a23bf93cce09358bc2c1047a3bd20fad47bf187e453aadc5
66f3da902d43ab0a2561d0477c7050d057bb0f69ade79015494363ad08ed172d
17a6995a757e027b2a51b9cc58635b29553ccc6c164555c0ed922074a23bcbfe
Poolin: 68ca9ee95748dc98ba24018ea64c18de31fca552e4753ef012acd0b615cd7384
477089a1e997a0115b3d4cd1d4ce21eb9dc83c45c14a7f7441e4fc74c3649ba2
EMCDPool: dde0975ad42fd9e03677f64b6c4f7efbe2ec0b6f905206d47893a77ac6336fca
a0131d4f8cc13d70443cd87f2ee7543e1142640666a88f80d1e0c885c7eb2c12
Binance Pool: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669c=
db5
637c58f3c0447ee99808b37e4f9559096c00ceb0d21130a9254558c4d2d7a=
e63
Anyone running a full-RBF node with debug=3Dmempool can easily verify all t=
hese
double-spends by examining their debug.log files.
With Antpool, Poolin, and EMCDPool, it is most likely that they're mining
full-RBF with ~100% of their hash power. These pools mined every double-spe=
nd
available to them, with the exception of some Antpool blocks found very clo=
se
to when the double-spend was broadcast. Binance Pool did *not* mine a full-=
RBF
replacement on two occasions, which makes me suspect they're mining full-RBF
with less than 100% of their hash power. During this testing, Binance Pool,
AntPool, Poolin, and EMCDPool, also all mined multiple double-spends from my
OTS calendars, further confirming my findings.
My OTS research also found examples of KuCoinPool and ULTIMUSPOOL mining
full-RBF double spends. They didn't find any blocks during this testing, so=
I
have no data on them with this testing. Luxor _did_ mine some blocks without
mining the double-spends, so at the moment it's reasonable to assume they h=
ave
full-RBF fully or partially disabled, or have some kind of full-RBF propaga=
tion
issue. They have confirmed similar issues to me in the past (eg employees
unintentionally disabling it on some nodes during an upgrade), so it's like=
ly
that has happened again. MARA Pool also mined some blocks without mining
double-spends, so they too may have full-RBF fully or partially disabled, a=
s I
mentioned in my OTS research.(1)
The tool I used is the following:
https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespe=
nd.py
Note that this script was written years ago, pre-segwit, and I hastily upda=
ted
it for recent Bitcoin Core/python-bitcoinlib versions. I haven't checked if=
all
the options like OP_Return outputs and multisig still work, and it doesn't =
even
take segwit into account when calculating fees. Don't use it on a wallet wi=
th
funds you can't afford to lose; it definitely has bugs in it.
For reference, here is the logs from a successful double-spend attempt:
$ sleep 15 ; ./doublespend.py --fee1 0.00018 --fee2 0.000224 `/home/user/b=
itcoin/src/bitcoin-cli getnewaddress` 0.00001
DEBUG:root:Delta fee: 0.00002296
DEBUG:root:Adding new input caec040f4435e98de9ae44a385e301312c5a3cddfb33f1=
bd08e1cf63307f87ce:0 with value 0.00072549 BTC
DEBUG:root:Delta fee: 0.00003035
DEBUG:root:Payment tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e3=
85a344aee98de935440f04ecca0000000000ffffffff028a0f0100000000001600149e12f3e=
f33ba4ccde4b85978e675c9fe59bb24a2e8030000000000001600149049e0f57ec5899c1eed=
2c5e9aab1c34ff5cec1f02473044022063834a187727c1eceb9b3e6ae9ccd0d369b51af3493=
fafba1d61ed3b273d48f7022049fbe71ecd600c7345fb6002e04275eb8445031df746eceaa6=
e6f5f413f67497012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412=
d1ea49a8b00000000
INFO:root:Payment tx size: 0.222 KB, fees: 0.00002035, 0.00009166 BTC/KB
INFO:root:Sent payment tx: 1c28870a78efd1c4616726ea0ca3f9d67f5591aab415222=
e2c9ec6184fc0b4f2
INFO:root:Sleeping for 30 seconds
DEBUG:root:Delta fee: 0.00004279
DEBUG:root:Double-spend tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3=
101e385a344aee98de935440f04ecca0000000000ffffffff01ae0a0100000000001600149e=
12f3ef33ba4ccde4b85978e675c9fe59bb24a20247304402201289c26da70e9ec4424fc2ff7=
194b57384c78c9c986c2efe6771ac6f5fda199702200cefa72560f21cd9abe846078ce13197=
029562102f7a44b8ec50772a851c1799012102c56d86e3031851822485d1a2f9f0e402f14b9=
6b64e711d5a2567412d1ea49a8b00000000
INFO:root:Double-spend tx size: 0.191 KB, fees: 0.00004279, 0.00022403 BTC=
/KB
INFO:root:Sent double-spend tx: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f=
50e79f77059ba0a669cdb5
Remember that if you want to replicate this, don't be surprised if it takes
quite a few attempts if you're sending tx1 with next-block fees. A minority=
of
hash power is mining full-RBF. There's also a chance that in the ~30s or
whatever you wait between tx1 and tx2, a block is found and tx1 gets mined.
This chance is actually even higher than the ~5% you'd expect, because mine=
rs
don't instantly update their block templates.
So if ~30% of hash power is actively mining full-RBF, you might actually ha=
ve a
~20% chance per attempt at succeeding at a naive high-fee/higher-fee
double-spend. Thus there's a (1-20%)^10 =3D 11% chance that 10 attempts in =
a row
fail. Being that unlucky happens all the time; the Gods of Probability,
probably hate you. :)
Finally, research like this is expensive in terms of my time and transaction
fees; research via the OTS calendar approach is essentially free. Donations=
are
appreciated as no-one is paying me to do full-RBF work or covering these
expenses.
Cheapest/easiest way is via Lightning: https://stacker.news/petertodd
Or on-chain: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
# References
1) https://github.com/bitcoin/bitcoin/pull/28132
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--cgm7x1PMMzBjvME4
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTcpCsACgkQLly11TVR
Lze6pQ/9Hj7VIiWegSQ3cN4Keh8hAtIdu3Om6cXz56rJDuXeozETzbWMLT9GL0la
gkz0iqxj8GEwxK9jm7edrV95If8TMbTtwvdvmwtScXB+vHjmsCOW+bLFK7LgecRx
/40xztcTnLnrG+5rfkFx6mfzBUVoLViHaeZN1sKcjbHdejm8f2BX7GGYgk0Da6Kn
jiiDNabwmo/veTDBHWXGdnWszxJ144sRP87pInaA2XLJtg2SAsyK2kzHrf+RHhF6
0MpeBuYjsif5fVN/IVI1ZHt6KKZCDDZfieDJtY6H9D1n8tI9T3trbydnElDkRu51
RJl2O2E6IGjvYfmWt9epaj4O0C0OYbxJVgIEk6xvy9ntA7BYv6O9meHTnyB/aH+a
RIWESbUDhlpkyU6imzT3kINrGUqMW6C5UWjOYDsaZ3CxHVwrQLW0Mr0aOt7/PLvq
2OyA0Q7HcHVT6l13931uDSyiqQ71/j+lHxqcM5uhd+dtsXkCMbfakdVMsneRP5fn
4YDTJssgxi2gRgvv+n/odnRIFrh9+KHX+HT1On8ptk1zA34fTNIA/UyVKvGpiEI6
GwogSJWmCIfnvbi6ckWXdgWMggSq2r0iIAMir/voikUbPlxqMMa8uCM1TmleEnZV
8shPy//smNUsutztuz7/ahd2+r//7c/xqDnrD4T7Rz3z0BtVicE=
=bODY
-----END PGP SIGNATURE-----
--cgm7x1PMMzBjvME4--
|
