* Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions
2026-06-11 18:28 ` Murch
@ 2026-06-12 6:52 ` 'SomberNight' via Bitcoin Development Mailing List
0 siblings, 0 replies; 3+ messages in thread
From: 'SomberNight' via Bitcoin Development Mailing List @ 2026-06-12 6:52 UTC (permalink / raw)
To: Murch, rkrux.connect; +Cc: bitcoindev
Hello rkrux, Murch, list,
The Electrum Wallet has for years been setting the nSequence of tx inputs to MAX-2 [0] by default for most transactions it creates. Between 2017-2022, the default was MAX-2 (to signal RBF), with an option to set MAX-1 instead.
Around Dec 2022 [1], when Bitcoin Core 24 added the mempoolfullrbf option, we removed the option and just started to (kind of) always set MAX-2.
"kind of", because we always set MAX-2 for normal wallet transactions, but for Lightning funding transactions, we have always (and still) set MAX-1 [2].
Similarly, if we add support for sending to silent payment addresses in the future, we will set MAX-1 (the old opt-out) there as well [3].
The wallet code still respects (and will keep respecting) opt-in/opt-out of BIP125 RBF, so it only allows replacing mempool transactions using the old nSequence rules (so no replacement for MAX-1).
All this is to support multi-device contexts: e.g. when a phone and a laptop both have a wallet restored from the same seed and they are used concurrently (perhaps even open in parallel, though not necessarily).
Instead of allowing the wallet to RBF any tx ignoring the signal, we abuse the signal bit to store publicly visible information to be used in a multi-device context [4]:
- if the tx opted-in to RBF, any device can freely RBF it
- if the tx did not opt-in to RBF, only the originating device can RBF it, as that device knows the details of the tx, and can apply special restrictions for it
- for example, a tx that pays to a silent-payment-addr, can have its fee bumped via decreasing the change output, but adding new inputs would burn coins. The device (wallet instance) that created the tx knows that it is a special tx that needs these restrictions upheld but can otherwise be safely RBF-ed. The other devices (that did not originate the tx) don't know it's paying to a silent payment addr but they will simply refuse to RBF it all together, as it did not opt-in to RBF and they did not originate it.
- or consider a lightning funding tx: only the wallet instance that created it knows the exact conditions re when it is safe to RBF it. In case of channel-establishment-v1, there is no way to RBF fee-bump the funding tx. In case of channel-establishment-v2, the originator wallet instance can bump its fee interactively. In either case, naively RBF fee-bumping the funding tx would result in the channel-open failing but the coins still being sent to the channel funding multisig script: recovering the coins would need manual cooperation from the channel-counterparty. Depending on the LN implementation and how long it takes for the two participants to react, the coins might be lost forever if the counterparty automatically deletes the channel keys for the failed channel open.
Note that double-spend-cancelling any tx (as opposed to fee-bumping) is safe AFAICT (though there could be contrived examples of multi-party protocols involving multiple txs or time pressure where even that is not safe(?)). By double-spend cancel, I mean RBF-ing the tx with a new one that sends all coins to a wallet address, another feature in Electrum.
---
The Electrum Wallet has always tried to mimic the Bitcoin Core wallet in terms of fingerprinting, for wallet transactions. E.g. we have the exact same anti-fee-sniping logic [5].
For this reason, it would be preferable to us if the Bitcoin Core wallet would *not* start setting nSequence fields to MAX or MAX-1 now.
---
I hope my explanation was clear enough :)
Cheers,
SomberNight (ghost43)
[0]: https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/transaction.py#L2462
[1]: https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
[2]: https://github.com/spesmilo/electrum/issues/7072
[3]: https://github.com/spesmilo/electrum/pull/9900#discussion_r2257399243
[4]: https://github.com/spesmilo/electrum/pull/8821#issuecomment-3160469899
[5]: https://github.com/spesmilo/electrum/blob/34f83a07617c2715522c18fdb71dc6a376162de1/electrum/wallet.py#L203
On Thursday, June 11th, 2026 at 18:42, Murch <murch@murch.one> wrote:
> 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
> > 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
> > 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
> > 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.
> >
> > Looking forward to replies from wallet developers in the list.
> >
> > [0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
> > [1] https://github.com/bitcoin/bitcoin/pull/35405
> > [2] https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4634469619
> > [3] https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4675005759
> >
> > - rkrux
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/uscVpXZgwC16jogiUouq2bY8y65G8BeiPWHizgCnU-IYtLwZyHY1bRC-VlpwTATpHTOuvQJ_c8KtSkipAsRhieC1wTlR6CDflgz9gwdIv_Q%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 3+ messages in thread