wallet: allow skipping script paths #32857

While testing MuSig2 integration in #29675 I ran into a Ledger bug https://github.com/LedgerHQ/app-bitcoin-new/issues/329 that was triggered because we signed for a script path in addition to the key path. The bug itself will be fixed, but it seems useful in general to be able to skip script path signing.

For example, you may have a 2-of-2 musig() descriptor with some sort of fallback after coins are N blocks old. For both on chain privacy and fee reasons, you don't want to use this path unless absolutely necessary. But our wallet can't know if our co-signer still has their key, so we sign the script path at all times. This could lead to accidental broadcast.

This PR introduces a keypath_only option (default false for now) to:

• the send RPC
• the walletprocesspsbt RPC.

The resulting PSBT won't include taproot_script_path_sigs. It does still have taproot_bip32_derivs and musig2_participant_pubkeys.

The wallet_taproot.py tests are expanded to cover this behavior.

It can also be tested with https://github.com/Sjors/bitcoin/pull/91.

TODO:

• maybe refactor MutableTransactionSignatureCreator
• add test coverage for send

<!--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/32857.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #bitcoin-core/gui/872 (Menu action to export a watchonly wallet by achow101)
• #35092 (wallet: stop materializing skipped descriptor addresses after high-index detection by takeshikurosawaa)
• #34861 (wallet: Add importdescriptors interface by polespinasa)
• #33392 (wallet, rpc: add UTXO set check and incremental rescan to importdescriptors by musaHaruna)
• #32861 (Have createwalletdescriptor auto-detect an unused(KEY) by Sjors)
• #32489 (wallet: Add exportwatchonlywallet RPC to export a watchonly version of a wallet by achow101)
• #31668 (Added rescan option for import descriptors by saikiran57)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

• Parse(desc_str, keys, error, false) in src/wallet/rpc/wallet.cpp
• WalletDescriptor(std::move(descs.at(0)), GetTime(), 0, 0, 0) in src/wallet/rpc/wallet.cpp

^{2026-05-01 10:44:00}

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task ARM, unit tests, no functional tests: https://github.com/bitcoin/bitcoin/runs/45219351756} _{LLM reason (✨ experimental): Compilation error due to passing a bool where an int* is expected in fillPSBT function.}

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

Why is one of the native Windows jobs failing to compile: https://github.com/bitcoin/bitcoin/actions/runs/16027562790/job/45219347987?pr=32857#step:10:553, but not the other: https://github.com/bitcoin/bitcoin/actions/runs/16027562790/job/45219348012?pr=32857 ?

@fanquake because it's in the fuzzer code, I incorrectly changed one of the function signatures there.

From the original description:

Under the hood it adds m_hide_script_paths to the HidingSigningProvider which triggers an early return in GetTaprootSpendData() when set.

It's also missing taproot_scripts which might be a bit too much. At least in initial testing Ledger wouldn't sign it.

I probably need to implement this at the SigningProvider level rather than HidingSigningProvider. The early return needs to be inside SignTaproot() right before // Try script path spending rather than in GetTaprootSpendData(). The goal isn't to hide leaf scripts from co-signers, only to make sure we don't sign them ourselves.

Shoehorning this into SigningProvider got ugly real fast. So instead I endup up passing avoid_script_path along the call stack from SignPSBTInput to SignTaproot. Which is also ugly...

Well, it compiles and works. Thoughts on how to implement this elegantly?

The walletprocesspsbt RPC now also has this option. Added test coverage by expanding wallet_taproot.py.

I split off a non-behavior-changing commit that adds avoid_script_path to FillPSBT. I think it makes sense to pass this option here, although in general we may want to refactor FillPSBT to take an options struct instead of this ever expanding argument list. That could be an independent or prerequisite PR.

I then did the same for SignPSBTInput, where I also think struct would be better.

Rinse and repeat for ::SignTransaction.

Will continue later to further split 09334ae0bd7939ed7476eb2b36f3bf8085885fe7. It might make sense to add a property to BaseSignatureCreator or it subclasses?

I opened #32876 and rebased this PR on top of it. That allowed me to drop 1486f05c8eded02d72690bf34d983a03e4ad748b + efc34a514b59cc1bab6e4d0f80c197481561c429.

I expanded #32876 with SignOptions. This shrinks 93fb607af3141ff1e22693588f498764401fc2c4 to just e2a151c3dc35997ac0f515feb292fc4543093593 which is very small ... but very ugly: casting BaseSignatureCreator to MutableTransactionSignatureCreator to access its avoid_script_path option.

This may also be useful for Silent Payments, cc @josibake.

Sidenote: currently it's unlikely you'll accidentally spend via an older() or after() script path. This is because you need to manually set the input sequence field in the send (etc.) RPC (and manually adjust the fee rate). Found out the hard way while testing 🤦 (there's currently no useful feedback when this happens).

Holding off on rebasing until #32876 is merged or I have to touch it.

Sidenote: currently it's unlikely you'll accidentally spend via an older() or after() script path. This is because you need to manually set the input sequence field in the send (etc.) RPC (and manually adjust the fee rate). Found out the hard way while testing 🤦 (there's currently no useful feedback when this happens).

Scenario that I have not tested but expect to behave in this way: 3 signers (A, B, C) form a MuSig (ABC) in the keypath and also have 3 non-Musig multi-sig script paths (AB, BC, AC) without any timelocks. They intend to MuSig sign in order from A to C to spend via keypath and start the signing flow first by producing nonces in the mentioned order, and then by adding partial signatures. By the time B adds its nonce, there'd would be a fully signed spendable script path? If yes, seems unusual to have this when the intent of the signers was for keypath spending, which makes a good case for this PR.

I did notice unconditional key and script path signing within SignTaproot function when I was reviewing #29675. We tried to simulate an intentional script path spending like above in #29675 by making A a no-signing wallet in the last test case in functional tests: https://github.com/bitcoin/bitcoin/pull/29675/commits/ac599c4a9cb3b2d424932d3fd91f9eed17426827#diff-c94f9555a2569240d362a00a82764f4714f6c65283e3f96725cf2a1043a296b5R238. Though the script path in that case is using MuSig but the overall unconditional script signing principle is still applicable.

If #32876 is not garnering reviews, can consider undrafting this PR itself because it contains 7 commits only. Allowing skipping script path spending optionally seems reasonable to me and a ready-to-review PR is more inviting than a draft one.

@rkrux I'm not too worried about reviews just yet, let's focus on getting #29675 in.

Rebased after #32876 landed. I need to check a few more things before marking this as ready for review.