walletprocesspsbt bip32derivs=false makes no nonce for tr(musig(A,B)/<0;1>/*) #36413

Current behaviour

With bip32derivs=false, walletprocesspsbt makes no MuSig2 nonce for a wallet whose descriptor derives after the aggregate, such as tr(musig(A,B)/<0;1>/*). It returns no error. Without nonces there are no partial signatures: after two rounds decodepsbt shows no musig2_pubnonces and no musig2_partial_sigs, and finalizepsbt returns "complete": false. With the default bip32derivs=true the same steps sign and the transaction is accepted.

The signer needs the derivation path from the aggregate key to the Taproot internal key. bip32derivs=false hides key origins from the signer, so SignMuSig2 skips the aggregate at if (agg_info.path.empty()) continue;.

Two cases sign fine with false: tr(musig(A/<0;1>/*,B/<0;1>/*)), where the aggregate is itself the internal key, and a PSBT that already carries the derivations, for example from walletcreatefundedpsbt or from another participant's bip32derivs=true call.

v31.1.0 behaves the same. #35370 adds a "strip" mode with the same problem: #35370#pullrequestreview-5391507690.

Expected behaviour

Either the PSBT signs and finalizes as with bip32derivs=true, or walletprocesspsbt returns an error.

Steps to reproduce

Regtest, master a829aeaac1.

1. Create two blank descriptor wallets. Import tr(musig(A,B)/<0;1>/*) into both as an active descriptor, each with its own key as xprv and the other as xpub.
2. Send to getnewaddress "" bech32m (the same address in both wallets) and confirm.
3. createpsbt spending that output.
4. In each wallet: bitcoin-cli -named walletprocesspsbt psbt=<psbt> bip32derivs=false.
5. combinepsbt the two results and repeat step 4 on the combined PSBT.
6. combinepsbt the two new results, then decodepsbt and finalizepsbt.

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

master@a829aeaac1

Operating system and version

macOS 27.0.1

Made with my usual tools: a computer, the Internet and an LLM. The mistakes, as usual, are all mine.

Hi! I'd like to investigate and work on this issue if it's still available. I've gone through the reproduction and the distinction between tr(musig(A,B)/<0;1>/) and tr(musig(A/<0;1>/,B/<0;1>/*)) looks particularly interesting. I'd like to trace how bip32derivs=false affects the MuSig2 signing path, understand whether the derivation information can be obtained internally without exposing it in the PSBT, and then work on a fix and regression test. Is anyone currently working on this? If not, would it be okay for me to take it?

I didn't start a fix because it needs a choice first: sign anyway, with the wallet using the key origins that bip32derivs=false keeps out of the PSBT, or return an error. @achow101, which would you prefer? @avicdr, fine by me if you take it. Which approach do you have in mind?

My initial preference would be to sign using the wallet's internal key-origin and derivation information without exposing those derivations in the PSBT.

As I understand it, bip32derivs=false controls whether BIP32 derivation information is included in the PSBT, but it shouldn't necessarily prevent the wallet from using that information internally when signing. In this case, SignMuSig2 skips the aggregate because agg_info.path is empty, even though the wallet has the information needed to derive the aggregate's path to the Taproot internal key.

I'll investigate whether we can resolve the required path from the wallet's internal metadata while keeping the PSBT unchanged with respect to derivation fields. I'll also add a regression test covering tr(musig(A,B)/<0;1>/*) with bip32derivs=false, alongside the existing cases where the aggregate key itself is the internal key or the PSBT already contains derivations.

If the required information cannot be resolved reliably without the PSBT derivations, returning an explicit error would be preferable to silently producing an incomplete signing result.