wallet, node: Redundant opt-in RBF wallet config and RPC parameters #32661

1. 
   ismaelsadeeq commented at 12:27 pm on June 2, 2025: member

   Following the removal of the -mempoolfullrbf node option in #30592, the Bitcoin Core wallet still retains the -walletrbf option. This option determines whether transactions are marked as opt-in RBF (i.e., using sequence numbers MAX - 1 or MAX - 2).

   With full-RBF now the default behavior, -walletrbf is effectively redundant and should be removed.

   However, removing -walletrbf alone is not sufficient, as several wallet RPCs also support a replaceable parameter that overrides the option:

   • send
   • sendall
   • sendtoaddress
   • sendmany
   • fundrawtransaction
   • walletcreatefundedpsbt
   • createpsbt
   • bumpfee
   • psbtbumpfee

   Additionally, the node-level createrawtransaction RPC also accepts a replaceable argument.

   Several RPCs—such as gettransaction (wallet), getmempoolentry (node), and others—expose a bip125-replaceable field. The chain interface also includes an isRBFOptIn method, which is used by both wallet and node code.

   ---

   I think it will can be cleaned up in a few releases using the following method:

   • Remove the -walletrbf configuration option.
   • Deprecate the replaceable parameter from all affected RPCs.
   • Always use sequence number MAX - 2 when creating transactions.
   • Deprecate the bip125-replaceable field from transaction info returned by RPCs for some period marked for removal.
   • Add release note that wallet option is removed and RPC parameter and return values are deprecated.

   In future release

   • Remove the replaceable parameter from RPC’s
   • Remove the bip125-replaceable field from transaction info.
   • Remove the isRBFOptIn logic from the codebase and Chain interface.
   • Note in release notes that bip125-replaceable field will no longer be reported in affected RPC’s and also RPC’s now don’t accept replaceable parameter .

   ---

   Questions:

   1. Fingerprinting Risk: Using a consistent sequence value (e.g., MAX - 2) could further narrow the wallet’s transaction fingerprint. Is this acceptable from a privacy perspective? cc: https://github.com/achow101/wallet-fingerprinting/blob/main/fingerprints.md

   2. Field Removal: Should we fully remove the bip125-replaceable field from transaction info RPCs, or hardcode it to true for backward compatibility? (Note: Retaining the field might require keeping the isRBFOptIn logic if we dont want to hardcode.)

2. willcl-ark added the label Brainstorming on Jun 2, 2025
3. willcl-ark added the label Wallet on Jun 2, 2025
4. willcl-ark added the label RPC/REST/ZMQ on Jun 2, 2025

Contributors
ismaelsadeeq

Labels
Brainstorming Wallet RPC/REST/ZMQ