Feedback-ID: i525146e8:Fastmail
Date: Sun, 30 Jul 2023 15:44:36 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <ZMaFZLW7+HdPVtYW@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="jxJ9cGscdKF6mcQ7"
Content-Disposition: inline
Subject: [bitcoin-dev] Pull-req to enable Full-RBF by default
Precedence: list


--jxJ9cGscdKF6mcQ7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

FYI I have submitted a pull-req to Bitcoin Core to enable full-rbf by defau=
lt:

https://github.com/bitcoin/bitcoin/pull/28132

At the moment approximately 40% of the total Bitcoin hash power is mining
full-rbf replacements, spread over 8 different pools. Multiple block explor=
ers,
including blockstream.info(1) and mempool.space(2), have enabled full-rbf on
all their nodes. Nodes installed via BTCPay Server(3) and MyNode(4), among
others, enable full-rbf by default. Measurements also indicate that a
significant percentage of nodes have manually enabled full-rbf(5), and there
exists a well-connected set of nodes running my full-rbf peering patch(6).

As https://mempool.space/rbf#fullrbf shows, successful full-rbf replacements
are fairly common. Though the fact that only a minority of nodes relay full=
-rbf
replacements is still a nuisance barrier to taking advantage of them, eg in
multi-party transactions(7). A typical non-listening node with only 8 outgo=
ing
connections is certainly *not* guaranteed to have full-rbf peers. Thus, my
pull-req to enable full-rbf by default.

Meanwhile, the last time full-rbf was discussed on this mailing list the on=
ly
opposition to full-rbf from actual entities with an actual claimed use(8) of
unconfirmed transactions was Bitrefill. I've checked multiple times, most
recently today, and I can find no evidence that Bitrefill actually accepts
unconfirmed transactions as payment any more even though their payment page
claims otherwise. Every test transactions I've done - from a variety of ema=
ils
and accounts not linked to myself - has required a confirmation.

Finally, on-chain wallets have been moving towards removing the ability to =
set
non-BIP125-rbf transactions entirely. For example, Electrum removed the abi=
lity
to turn off BIP125 last year(9), and Phoenix, Green, Nunchuck, and Zeus, -
among others - also provide no way to turn BIP125 off. For these wallets, t=
he
existence of "non-replaceable" transactions is merely a support headache(10=
).

The fact is the dream of "on-chain coffee payments" is well and truly dead.
There is clearly no value in having the BIP125 distinction when ~40% of has=
hing
power ignores it. There is also clear value in *not* having that distinctio=
n:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf


We should enable full-rbf by default in Bitcoin Core github master, to be
released in the upcoming v26.0. Following that, we can depreciate and
eventually remove all BIP125 code and associated complexity in future relea=
ses
after that.


# References

1) https://github.com/Blockstream/esplora/commit/289cc6539497c3f42ab5c591c2=
369b75d90046e6
2) https://github.com/mempool/mempool/pull/3867
3) https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempool=
fullrbf-1-
4) https://github.com/mynodebtc/mynode/commit/a6cd63583cab8c62510925492bb2c=
fda9d2add09
5) https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
6) https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
7) https://petertodd.org/2023/fullrbf-multiparty-protocols
8) While GAP600 claimed to act as a payment processor for unconfirmed
   transactions, they refused to actually provide examples of real services
   making use of them. Given their ties to BSV, I'm inclined to believe that
   they are lying.
9) https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1=
613b252db388
10) https://github.com/spesmilo/electrum/issues/8490

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTGhWEACgkQLly11TVR
LzcGHg/6A00gNpgcDWfo78Im7K3WmKXK5jMxKbB68VaPAfRpFuNUfo1QdcsfgFGR
Mn7t5CIjVq3MSEbb9X7HSyyPLyT75ODL8moxkiOlS8qlxkL4UosV279PtOstxHtY
3D3DpWUmq0x8QunOU6n908ksDElrjZKUnmYVyr3gyWSIM9LMWE9M5XFou077/jDz
Eg0zeRWhtf7H1Pe6DcrldwC3xEM3CeUqQ0LhR1NEKVrqQwpQXDHdmdHa9vTG8CRg
XvlbIsBPCHz8pIUZereasp4E/AtE3/L4KokPCBJU1gZ2SpGJkVk26IfZ+y9p6LnQ
9muV/sLcYee0kU0e15N8vduc/cWYmWRZ4pfw5U8xoIj+I/FptN2drDJF3Vpw+GA8
07VOuUL37v0eyA/+VEzZBT3iMTPsEhNk/7RQobn3Q4+t4ZqBCECwVCEObzY21Oe/
6PfdbbJbKqg3+QoF26+961TwuZ6T+WauJbCyN4iTI0oho9jzFMj3PaCrXweyFEsD
fXerVebQCKxswQo6e+iKQASsENDh6ju2fuhcBr0U0QGscgOC/u4ed6m3SPaizpvH
LLQTrIzv9iALeq31wpm82BT2AbHG3WchNpgnmtkC9BsOjh0eGukTEvaw1XBsmwif
dd1xcdfGFTn2SbTUdCYnNWRiTbxZvtxNTw/u8Q9iLjgNIvxUMmY=
=073F
-----END PGP SIGNATURE-----

--jxJ9cGscdKF6mcQ7--