From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D223FC0032 for ; 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 ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtledgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeihfeljeevvdfhteetheeutdfgieehue ekheeiuefggeekudefffduvdeufeefleenucffohhmrghinhepghhithhhuhgsrdgtohhm pdguohhusghlvghsphgvnhgurdhphidpshhtrggtkhgvrhdrnhgvfihspdhpvghtvghrth houggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; 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 To: Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cgm7x1PMMzBjvME4" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--