[bitcoin-dev] Pull-req to enable Full-RBF by default

From: Peter Todd <pete@petertodd•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Pull-req to enable Full-RBF by default
Date: Sun, 30 Jul 2023 15:44:36 +0000	[thread overview]
Message-ID: <ZMaFZLW7+HdPVtYW@petertodd.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

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

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 explorers,
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 outgoing
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 only
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 emails
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 ability
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, the
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 hashing
power ignores it. There is also clear value in *not* having that distinction:
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 releases
after that.

# References

1) https://github.com/Blockstream/esplora/commit/289cc6539497c3f42ab5c591c2369b75d90046e6
2) https://github.com/mempool/mempool/pull/3867
3) https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1-
4) https://github.com/mynodebtc/mynode/commit/a6cd63583cab8c62510925492bb2cfda9d2add09
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/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
10) https://github.com/spesmilo/electrum/issues/8490

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]