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

This PR extends the existing bip32derivs argument of the walletprocesspsbt and descriptorprocesspsbt RPCs with explicit key-origin modes.

Motivation

Setting bip32derivs=false prevents new key-origin fields from being added, but does not explicitly remove fields already present in an input PSBT. Some collaborative PSBT workflows need to remove that metadata before sharing the PSBT.

Behavior

• true or "add" allows known key-origin fields to be added.
• false or "preserve" does not add or explicitly remove key-origin fields.
• "strip" does not add key-origin fields and removes surviving standard key-origin fields after normal processing.

The default remains true. The existing boolean values remain accepted for compatibility.

Stripping removes global xpubs and legacy and Taproot BIP32 derivation fields from inputs and outputs. Unknown and proprietary PSBT fields are left unchanged. Finalization may independently remove input key-origin fields.

Closes #30294.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35370.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Approach ACK.

This looks like the correct approach (in contrast to #30341), putting strip functionality in walletprocesspsbt (and also descriptorprocesspsbt).

The option does more than stripping bip32 derivation paths and it's name should reflect that.

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.

Concept ACK 2ec9650 for stripping away the bip32 derivations data if the user intends so.

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.

I'm inclining to agree with this. I think it'd be good to avoid having a new similar looking argument that sort of overlaps with the existing one (based on what's described in the "Behaviour" section). I also believe that updating the existing bip32derivs to accept an enum would be worth the breaking change. Fortunately, the name of the bip32derivs argument already is generic enough that it's functionality can be extended.

Reworked in e5adbdfbe9. The separate stripbip32derivs boolean has been removed, and the existing bip32derivs argument now accepts "add", "preserve", and "strip" for both processing RPCs. Existing true and false values remain aliases for "add" and "preserve" so current callers keep their behavior.

The helper and RPC documentation now describe the full key-origin scope: global xpubs and legacy and Taproot BIP32 derivation fields. Normal processing and finalization behavior remain unchanged.

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task tidy: https://github.com/bitcoin/bitcoin/actions/runs/29073641590/job/86300384551} _{LLM reason (✨ experimental): CI failed because clang-tidy reported a performance-unnecessary-copy-initialization warning in src/rpc/rawtransaction_util.cpp (warnings-as-errors), causing the clang-tidy step to fail.}

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

Given that this is LLM generated, please make sure to adhere to the https://github.com/bitcoin/bitcoin/blob/master/doc/AI_POLICY.md

I authored the original PR and the initial revisions myself. For these additional changes, I used an LLM as a tool. Unfortunately, I failed to properly catch the issues before pushing. I have now personally reviewed both the original and current changes, and I fully understand the content. I have also reviewed the AI policy, and going forward, I will take personal responsibility for reviewing changes and responding to feedback.

Tests

* `cmake --build build --target bitcoind bitcoin-cli --parallel 2`

* `python3 test/functional/rpc_psbt.py --configfile=build/test/config.ini`

* `python3 test/functional/rpc_help.py --configfile=build/test/config.ini`

* `python test/lint/lint-includes.py`

* `python test/lint/lint-files.py`

* `python test/lint/lint-tests.py`

You can remove this whole LLM generated redundant section. A human can see that you modified test/functional/rpc_psbt.py and can see that this is a test meant for the change.

Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits and https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#committing-patches