[BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions
19 views
Skip to first unread message
rkrux
5:34 AM (14 hours ago) 5:34 AM
to Bitcoin Development Mailing List
Hello list,
There is an intention in the bitcoin core wallet to remove the
BIP 125 RBF signalling[0] in transactions for which a PR is raised[1].
The primary reason for its removal is because ever since fullrbf
became the default In bitcoin core nodes in v28.0 two years back,
this signalling has become redundant.
However, a point[2] was raised in the review of the above PR that
the default input sequence number should be the one that's agreed
There is an intention in the bitcoin core wallet to remove the
BIP 125 RBF signalling[0] in transactions for which a PR is raised[1].
The primary reason for its removal is because ever since fullrbf
became the default In bitcoin core nodes in v28.0 two years back,
this signalling has become redundant.
However, a point[2] was raised in the review of the above PR that
the default input sequence number should be the one that's agreed
by the wide wallet community as a best practice. It would be helpful
if other wallet developers can share if (when) they have plans to
if other wallet developers can share if (when) they have plans to
remove this explicit BIP 125 signalling for RBF in transactions.
It's also an intention[3] to share an informational BIP later that
highlights a recommended input sequence number in transactions.
It's also an intention[3] to share an informational BIP later that
highlights a recommended input sequence number in transactions.
Looking forward to replies from wallet developers in the list.
Murch
2:42 PM (5 hours ago) 2:42 PM
to bitco...@googlegroups.com
Hi rkrux and everyone,
I don’t have a strong recommendation at this time, but I have a few
thoughts on what should be considered in making the decision:
Stopping to signal replaceability makes it sound like it’s a matter of
dropping a fingerprint, but it might be clearer to state that the signal
is expressed in the per-input sequence value, and that every sender has
to pick a sequence for every input!
The most common three settings for the sequence value would presumably
be final (MAX), non-final (MAX−1), and non-final replaceable (MAX−2).
The past usage of BIP125 had caused a trend toward more wallets setting
the latter (MAX−2). According to Mainnet Observer, currently about 75%
of txs signal replaceability in the 30-day average (see
https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).—Unfortunately,
that chart does not distinguish between (MAX) and (MAX−1), so I’m not
sure which of those two is more prevalent (probably (MAX)?). Does
someone have more data on that? Otherwise, I could throw together a Dune
dashboard later.
We should try to converge transactions on one common sequence. Signaling
finality means that locktimes in the transaction are disabled, so that
seems like a poor choice. While `mempoolfullrbf` appears to be fully
adopted by the network at this time, there are still some users that use
(MAX−1) to explicitly convey absence of intent to replace, but that
signal would be ignored by the network for evaluating replaceability and
these senders could easily renege on the perceived signal. There are
also some wallets that generally still use (MAX) which now also
effectively is replaceable. So, the more natural convergence point would
perhaps be for everyone to adopt usage of (MAX−2), as the emergent
behavior of the network is replaceability and it currently is the most
common signal.
Cheers,
Murch
On 2026-06-10 22:43, rkrux wrote:it
> --
> 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+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.
I don’t have a strong recommendation at this time, but I have a few
thoughts on what should be considered in making the decision:
Stopping to signal replaceability makes it sound like it’s a matter of
dropping a fingerprint, but it might be clearer to state that the signal
is expressed in the per-input sequence value, and that every sender has
to pick a sequence for every input!
The most common three settings for the sequence value would presumably
be final (MAX), non-final (MAX−1), and non-final replaceable (MAX−2).
The past usage of BIP125 had caused a trend toward more wallets setting
the latter (MAX−2). According to Mainnet Observer, currently about 75%
of txs signal replaceability in the 30-day average (see
https://mainnet.observer/charts/transactions-signaling-explicit-rbf/).—Unfortunately,
that chart does not distinguish between (MAX) and (MAX−1), so I’m not
sure which of those two is more prevalent (probably (MAX)?). Does
someone have more data on that? Otherwise, I could throw together a Dune
dashboard later.
We should try to converge transactions on one common sequence. Signaling
finality means that locktimes in the transaction are disabled, so that
seems like a poor choice. While `mempoolfullrbf` appears to be fully
adopted by the network at this time, there are still some users that use
(MAX−1) to explicitly convey absence of intent to replace, but that
signal would be ignored by the network for evaluating replaceability and
these senders could easily renege on the perceived signal. There are
also some wallets that generally still use (MAX) which now also
effectively is replaceable. So, the more natural convergence point would
perhaps be for everyone to adopt usage of (MAX−2), as the emergent
behavior of the network is replaceability and it currently is the most
common signal.
Cheers,
Murch
On 2026-06-10 22:43, rkrux wrote:it
> 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+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/212d5db3-7521-4afd-a551-fda8a6ef09c9n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages