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

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.)

See #32661 (comment) for the status of this.

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.

Just to have it written somewhere. The GUI has also a redundant option for sending to enable RBF.

https://github.com/bitcoin-core/gui/pull/936 :)

@ismaelsadeeq could you modify the issue description to use a list of tasks and links to PRs? I think we should deprecate everything in the same release to be consistent, having a TODO might be useful.

@achow101 I don't think this is completed. Still missing all the replaceable arguments in the RPC calls.

@ismaelsadeeq could you modify the issue description to use a list of tasks and links to PRs? I think we should deprecate everything in the same release to be consistent, having a TODO might be useful.

Hi Pol, that's a good idea for book-keeping. I am not spearheading the effort or following up on it. I think @rkrux can add a comment here with them and update the status as things change, then I will link that comment in the issue description?

PRs to review in order:

1. #35381
2. #35404
3. #35405
4. #35433
5. #35442

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.

I guess one PR is missing to mark them deprecated?

$ git grep '"replaceable", RPCArg::Type::BOOL'
src/rpc/rawtransaction.cpp:        {"replaceable", RPCArg::Type::BOOL, RPCArg::Default{true}, "Marks this transaction as BIP125-replaceable.\n"
src/wallet/rpc/spend.cpp:                    {"replaceable", RPCArg::Type::BOOL, RPCArg::DefaultHint{"wallet default"}, "Signal that this transaction can be replaced by a transaction (BIP 125)"},
src/wallet/rpc/spend.cpp:                    {"replaceable", RPCArg::Type::BOOL, RPCArg::DefaultHint{"wallet default"}, "Signal that this transaction can be replaced by a transaction (BIP 125)"},
src/wallet/rpc/spend.cpp:            "replaceable", RPCArg::Type::BOOL, RPCArg::DefaultHint{"wallet default"}, "Marks this transaction as BIP125-replaceable.\n"
src/wallet/rpc/spend.cpp:                    {"replaceable", RPCArg::Type::BOOL, RPCArg::Default{true},

Yes, I'm waiting for these three to get merged first.

I guess one PR is missing to mark them deprecated?

Added the fourth stacked PR #35433 in the comment #32661 (comment).