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
5. 
   crackedhandle commented at 9:43 am on January 20, 2026: none

   Hi, I went through the issue and the context around the removal of -mempoolfullrbf and the current -walletrbf / replaceable handling.

   From my understanding, a staged approach like this seems reasonable:

   First deprecate the -walletrbf option and the replaceable RPC parameter, and default to using MAX-2 sequence numbers when creating transactions.

   Keep reporting bip125-replaceable in RPCs for one release (marked deprecated), and remove it in a later release.

   In a follow-up, remove the remaining isRBFOptIn logic once the RPC surface no longer exposes or accepts replaceable.

   For the fingerprinting concern: is always using MAX-2 considered acceptable, or would maintainers prefer to keep some variability at the wallet level?

   For the bip125-replaceable field: should the plan be to fully remove it from RPC results eventually rather than hardcoding it to true?

   If this direction makes sense, I’d be happy to start by preparing a PR that deprecates -walletrbf and the replaceable parameter and updates the relevant RPC help + tests.

Contributors
ismaelsadeeq crackedhandle

Labels
Brainstorming Wallet RPC/REST/ZMQ