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

This modification is considered necessary due to the obsolescence of specific RBF signaling following the implementation of full RBF in Bitcoin Core nodes starting with version 28.0. A pull request aimed at this change has already been initiated and is currently under review. There are discussions among developers regarding what should be the default input sequence number post-removal of BIP 125 signaling, aiming for a consensus that reflects best practices endorsed by the wallet developer community. Furthermore, an informational Bitcoin Improvement Proposal (BIP) is expected to be published soon, recommending a standard input sequence number for transactions, which could help standardize practices across different implementations and facilitate a smooth transition.

The current use of sequence values for signaling transaction replaceability brings to light various network behaviors and implications on wallet settings. Data from Mainnet Observer indicates that around 75% of transactions signal replaceability, yet there's ambiguity about the distribution between different sequence settings such as MAX and MAX-1. This situation has led to suggestions for more detailed analysis and potentially developing tools like a Dune dashboard to provide clearer insights. The majority of the network now adopts mempoolfullrbf, indicating a general acceptance of replaceability irrespective of individual transaction signals. This shift suggests that transitioning all transactions to use MAX-2 for explicit replaceability could simplify signaling processes and align more closely with prevailing network behaviors.

Electrum Wallet's approach to setting the nSequence of transaction inputs highlights the nuanced strategies employed by wallet developers to accommodate changes within the broader Bitcoin ecosystem. Since the introduction of the mempoolfullrbf option, Electrum has standardized its settings to consistently use MAX-2 for most transactions, while still allowing options for specific transaction types like Lightning funding transactions. This method not only signals RBF eligibility but also encodes information critical in multi-device environments. For instance, transactions optimized for RBF can be replaced by any device, whereas non-RBF transactions require actions only from the originating device. Special conditions apply to transactions targeting silent payment addresses or those involved with the Lightning Network, where incorrect replacement could lead to loss of coins. These considerations are crucial for maintaining functionality and security across diverse transaction scenarios and highlight the importance of consistent and informed setting of nSequence fields in wallet software.

These developments reflect a broader trend towards refining Bitcoin transaction protocols to enhance network efficiency, user privacy, and overall security. The collective input from various wallet developers is vital in ensuring these updates meet the needs of all stakeholders and contribute positively to the evolving landscape of cryptocurrency transactions.