#35370 rpc: add key-origin modes to PSBT processing RPCs

ReviewabilityReviewsAgreementSize
#35370 junbyjun1238 rpc: add key-origin modes to PSBT processing RPCsWaiting on author0Blocked86 + 245 tests
  • Allow PSBT processing RPCs to explicitly add, preserve, or strip key-origin derivation metadata
  • Let participants in collaborative workflows sanitize sensitive derivation paths and xpubs before sharing
  • Author has been silent for 84 days
  • New reviews may wait a long time for an author response
  • Concept and approach approval for adding strip options to PSBT processing RPCs (willcl-ark, rkrux)
  • Unaddressed objection: strip mode breaks MuSig2 signing on PSBTs lacking key origins (fametrano)
  • Open question on whether participant pubkeys should also be stripped to avoid fingerprinting (fametrano)
  • 86 lines added or modified outside tests
  • 245 lines added or modified in tests
  • 10 lines removed in total
  • 9 files, 2 commits
RPC / REST / ZMQ#22 of 55
P3 · user request
  • P3 because users get explicit modes to add, preserve, or strip derivation metadata in PSBT RPCs
  • Resolves unexpected retention of derivation paths and global xpubs when processing transactions
  • Ranking pass: Moved down 9: valuable privacy control, but it adds modes rather than fixing wrong output, so it sits below the P3 correctness fixes.
Wallet#50 of 92
P3 · user request
  • P3 because users in collaborative workflows can sanitize sensitive derivation paths and xpubs
  • Prevents leaking internal wallet structure before sharing transactions with outside signers
  • Ranking pass: Moved down: resolves a long-standing issue, but it is a feature addition behind the P3 bug fixes.
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Extends the bip32derivs argument in walletprocesspsbt and descriptorprocesspsbt to accept explicit key-origin handling modes: "add", "preserve", and "strip", while retaining boolean values for backward compatibility. When "strip" is selected, a new helper removes global xpubs and legacy/Taproot BIP32 derivation fields from all inputs and outputs after processing.

Problem: Setting bip32derivs to false prevents new key derivation metadata from being added, but leaves any existing key-origin fields intact. In collaborative PSBT workflows, users wishing to sanitize sensitive derivation paths or xpubs prior to sharing the transaction cannot strip existing metadata using these RPCs.

Evidence of importance:

  • Closes issue #30294 ('Setting bip32derivs to false with walletprocesspsbt includes bip32_derivs for outputs'), which noted unexpected retention of output derivation metadata.
  • Follows closed PR #30341 ('Permit Combiner to strip bip32_deriv information'), addressing metadata privacy in collaborative PSBT processing.

Reviewability

Paused · Waiting on author

Open objections from fametrano, maflcko with no author reply for 30 days; review would repeat what has been asked.

Waiting on (from the thread read):

  • author: address MuSig2 signing failure under "strip" mode and inline suggestions 2026-10-02
  • author: answer question regarding duplicate test logic 2026-07-10
  • author: clarify whether participant pubkeys should be stripped from outputs 2026-10-02
  • author: fix MuSig2 signing failure when 'strip' mode is used 2026-10-02
  • author: address test coverage for bip32derivs=false preserving derivations 2026-10-02
  • author: answer whether 'strip' should remove PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS from outputs 2026-10-02
  • author: explain or deduplicate test logic in test/functional/rpc_psbt.py 2026-07-10

Agreement

Blocked

objection that needs a change, nobody has replied (fametrano)

Thread notes: Reclassified achow101's comment c:4569152829 from objection to suggestion per re-read instructions as it proposes an enum design without stating a concrete cost. Added fametrano's objection regarding MuSig2 signing failure under "strip", along with their test suggestion and participant pubkey question, and maflcko's question on test duplication. / Reclassified achow101's interface comment as a suggestion rather than an objection per current rules. Recorded fametrano's objection regarding MuSig2

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
achow101 (member)suggestion, interfaceConvert the existing `bip32derivs` argument into an enum/choices argument rather than adding another boolean parameterfixed · fix pushed · author converted bip32derivs into an enum supporting "add", "preserve", and "strip" in e5adbdfbe9answeredyes2026-05-28: 'I'm not sure about stacking yet another bool argument. Maybe it would be better to convert the existing `bip32derivs` into a enum/choices argument.'
Status from: 2026-07-10: junbyjun1238: 'The separate `stripbip32derivs` boolean has been removed, and the existing `bip32derivs` argument now accepts `"add"`, `"preserve"`, and `"strip"`'
maflcko (member)question, maintenanceWhy is the test logic duplicated given that the test supports --usecli?openansweredno2026-07-10: 'The test supports --usecli, so why is this duplicate?'
fametrano (contributor)question, interfaceShould "strip" remove PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS from outputs as well to prevent wallet fingerprinting, or should documentation specify that they remain?openansweredno2026-10-02: 'Should `"strip"` remove them from outputs too, or should the help say they stay?'
fametrano (contributor)objection, correctnessWith "strip", MuSig2 wallets cannot produce nonces or partial signatures on PSBTs lacking key origins because key origins are hidden during processing instead of stripped afterwardsopenchangedno2026-10-02: 'With `"strip"`, a `tr(musig(A,B)/<0;1>/*)` wallet makes no MuSig2 nonce and no partial signature on a PSBT that has no key origins yet.'
fametrano (contributor)suggestion, correctnessAdd a test asserting that bip32derivs=false on a PSBT with key origins preserves them rather than stripping themopenansweredno2026-10-02: '`bip32derivs=false` is only tested on a PSBT without key origins, where `"preserve"` and `"strip"` give the same result.'

Support:

  • willcl-ark (member) (Approach ACK, 2026-05-28) [read: descriptorprocesspsbt, walletprocesspsbt]: putting strip functionality in `walletprocesspsbt` (and also `descriptorprocesspsbt`)
  • rkrux (member) (Concept ACK, 2026-06-19) [read]: stripping away the bip32 derivations data if the user intends so

Participants:

  • achow101 (member, neutral, 1 statements 2026-05-28 to 2026-05-28): suggested converting bip32derivs to an enum instead of adding another boolean argument
  • willcl-ark (member, support, 1 statements 2026-05-28 to 2026-05-28): Approach ACK for placing strip functionality in walletprocesspsbt and descriptorprocesspsbt
  • rkrux (member, support, 1 statements 2026-06-19 to 2026-06-19): Concept ACK for stripping BIP32 derivation metadata and supported enum conversion
  • maflcko (member, question, 5 statements 2026-07-10 to 2026-07-10): asked why test logic is duplicated, noted AI policy adherence and commit squashing
  • fametrano (contributor, objection, 6 statements 2026-10-02 to 2026-10-02): found that "strip" prevents MuSig2 signing on PSBTs without key origins; suggested test coverage and questioned participant pubkey retention

Files

248 lines under test/bench/ci.

  • test/functional/rpc_psbt.py +245/-3
  • src/rpc/rawtransaction_util.cpp +21/-0
  • src/rpc/rawtransaction.cpp +13/-3
  • src/psbt.cpp +15/-0
  • src/wallet/rpc/spend.cpp +13/-2
  • doc/release-notes-35370.md +11/-0
  • src/rpc/rawtransaction_util.h +8/-0
  • src/rpc/client.cpp +2/-2
  • src/psbt.h +3/-0

Card

The short text the ranking pass compares across PRs.

This PR enhances the bip32derivs parameter in walletprocesspsbt and descriptorprocesspsbt to support string modes (add, preserve, and strip) in addition to existing booleans. Setting bip32derivs to false prevented adding new derivation paths but could not remove existing derivation metadata or global xpubs already present in a PSBT. The new strip mode clears standard BIP32 derivation paths and global xpubs from inputs and outputs, allowing users in collaborative multisig setups to sanitize key-origin metadata before sharing transactions. This resolves long-standing issue #30294.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-03T01:21, confidence high, input hash c0c596fa0e344e29
thread read through 2026-10-02 (16 statements), head af752153f7
labels: RPC/REST/ZMQ

Categories

RPC / REST / ZMQ

P3 · user request (ranking pass: Moved down 9: valuable privacy control, but it adds modes rather than fixing wrong output, so it sits below the P3 correctness fixes.)

Extends PSBT RPC interfaces to allow stripping key derivation data as requested in #30294. The PR adds explicit key-origin handling modes ('add', 'preserve', 'strip') while maintaining backwards compatibility with boolean values.

Membership: Has the RPC/REST/ZMQ label and updates argument parsing and handling across descriptorprocesspsbt and walletprocesspsbt.

Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 0

Wallet

P3 · user request (ranking pass: Moved down: resolves a long-standing issue, but it is a feature addition behind the P3 bug fixes.)

Enables users in collaborative PSBT workflows to sanitize sensitive derivation paths and xpubs before sharing transactions. As noted in #30294, 'Setting bip32derivs to false with walletprocesspsbt includes bip32_derivs for outputs', leaving no straightforward way to strip existing metadata.

Membership: Changes PSBT handling and walletprocesspsbt in src/psbt.cpp and src/wallet/rpc/spend.cpp.

Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 0