Re: [bitcoindev] [BIP Proposal] Removal of BIP 125 RBF signalling in wallet transactions

["'SomberNight' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

Hi void867,

(Replying to list as well. Original email quoted in full below.)

> It is interesting to use the input sequence number as a field to
> signal whether a transaction can be replaced between several wallets
> sharing the same seed.
> However, this seems like a fingerprinting vector.

You are of course right this behaviour is a (~small) fingerprinting vector.

> I wonder whether it would be better to use a database field for the
> wallet transaction to indicate whether a transaction is permitted to
> be replaced.

Storing the signal bit in a local database, and letting the wallet do RBF if its local database has the tx marked as being locally-originated, would mostly work.

(1) The tradeoff is that while with our current approach (storing signal bit on-chain) where any device is allowed to RBF the most-common simple wallet transactions (that set nSequence to MAX-2), that would not be the case with the local db signal where only the originator could RBF any tx.

(2) Another scenario is the user creating the tx in another wallet software but there is mempool congestion and their tx is "stuck" in the mempool, and so they restore from seed in Electrum and try to RBF it there: currently this works if the other wallet software set nSequence to MAX-2, but with the local db signal it would never work.
Although this use case is somewhat weakened by the fact that wallet software that doesn't let the user properly RBF their tx likely doesn't set nSequence to MAX-2 anyway.

(3) Even disregarding mixing wallet software, if there is mempool congestion and the wallet has some stuck txs, and the user panics and restores from seed in desperation (and also deletes their old wallet file) then they could not RBF the tx anymore (if the signal bit is stored in the local db). This might be a contrived example - although weird edge cases do happen.

(4) Relatedly, I think it would be nice if other wallet software would only set nSequence to MAX-2 if the tx is safe to arbitrarily RBF. That is, for example, ideally a tx paying to a silent payment address should not set MAX-2 in any wallet. Otherwise in scenario (2), the user could lose the coins. Alternatively users would have to be educated RBF-ing txs created in other wallet software is not safe...

Indeed this last issue (4) would be avoided if a wallet strictly restricted RBF to locally originated txs using by storing a flag in a local database. hmm. Tradeoffs everywhere :)

I wonder what logic other wallets use to determine whether they expose a GUI option to RBF a mempool tx.

Regards,
SomberNight


On Tuesday, June 16th, 2026 at 07:52, void867 wrote:

> Hi SomberNight,
> 
> (replying off-list, but feel free to reply on-list)
> 
> It is interesting to use the input sequence number as a field to
> signal whether a transaction can be replaced between several wallets
> sharing the same seed.
> 
> However, this seems like a fingerprinting vector. When the majority of
> wallets use a specific sequence number by default, but one wallet
> allows the user on a tx-by-tx basis to use a sequence number different
> from the most frequently used default, then transactions using those
> non-default sequence numbers are less frequent and could more easily
> be grouped and filtered for chain analysis.
> 
> I wonder whether it would be better to use a database field for the
> wallet transaction to indicate whether a transaction is permitted to
> be replaced. The local transaction field could be anything (such as a
> flag if the transaction was locally created, or the wallet/device ID
> where the transaction was originally created, possibly even a local
> field for each transaction input in a multi-party transaction-creation
> context).
> 
> Best, void867

-- 
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/NDkJg0T-NF7_W2e1dDsNmmfET-rDUbmRXhiiEQngqTNNnf2EyM4s4eM01O9--90LN985wXDHJgbiGyVthNdji9Zd3sB6OJgn5v03PFuEM-I%3D%40protonmail.com.