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

The discussion revolves around the implications of storing a signal bit in a local database for Replace-by-Fee (RBF) transactions, as opposed to the current method of storing it on-chain. The proposed change would allow only the originator of a transaction to perform an RBF if the transaction is flagged in their local database as originating locally. This modification aims to reduce the risk of fingerprinting, which can occur with the current system where any device can initiate RBF for the most common simple wallet transactions by setting nSequence to MAX-2.

However, several challenges are associated with this approach. For instance, if a user creates a transaction using one wallet software but then switches to another wallet like Electrum due to mempool congestion, they might not be able to perform an RBF if the new wallet does not recognize the transaction as originating from it. This problem is compounded if the user also deletes their old wallet file or restores their wallet from seed in a panic, as they would lose the ability to RBF the transaction altogether. These scenarios underscore potential issues that could arise from restricting RBF capabilities to locally originated transactions only.

Furthermore, the conversation touches upon the need for wallet software to responsibly use nSequence for RBF eligibility. Ideally, transactions paying to a silent payment address should not have nSequence set to MAX-2, ensuring safety across different wallets. The email suggests that educating users about these nuances and the risks involved with RBF when switching between different wallet software could mitigate some risks. However, it remains unclear how other wallets handle GUI options for RBF of mempool transactions, indicating a broader industry challenge in standardizing safe and user-friendly RBF practices.