[Sjors]

Allow clients to obtain multipath descriptors, instead separate receive and change descriptors, by calling getdescriptors with --multipath.

So in addition to:

$ <cmd> --fingerprint f5acc2fd --chain test getdescriptors --account 0
{
  "receive": [
    "pkh([f5acc2fd/44h/1h/0h]tpubDCwY.../0/*)#...",
    "wpkh([f5acc2fd/84h/1h/0h]tpubDCtK.../0/*)#...",
    ...
  ],
  "internal": [
    "pkh([f5acc2fd/44h/1h/0h]tpubDCwY.../1/*)#...",
    "wpkh([f5acc2fd/84h/1h/0h]tpubDCtK.../1/*)#...",
    ...
  ]
}

Clients can use:

$ <cmd> --fingerprint f5acc2fd --chain test getdescriptors --account 0 --multipath
[
  "pkh([f5acc2fd/44h/1h/0h]tpubDCwY.../<0;1>/*)#...",
  "wpkh([f5acc2fd/84h/1h/0h]tpubDCtK.../<0;1>/*)#...",
  "sh(wpkh([f5acc2fd/49h/1h/0h]tpubDC87.../<0;1>/*))#...",
  "tr([f5acc2fd/86h/1h/0h]tpubDDKY.../<0;1>/*)#..."
]

[fametrano]

ACK b28c40d

The --multipath output expands to exactly the receive and change descriptors that getdescriptors already returns. I tested this without a device or emulator, and against a second BIP 389 implementation rather than Bitcoin Core. The one red CI job is unrelated: the bitbox02 simulator could not bind its port in test_display_address_multisig, and test_getdescriptors passed in that job.

I ran getdescriptors at this head, with and without multipath=True, against a fake client that derives keys from a fixed seed, and expanded each <0;1> descriptor with btclib-wallet's BIP 389 code. In all 12 runs (mainnet and testnet, accounts 0, 1 and 7, with and without Taproot) the expansions matched the receive and change lists, checksums included. Their first three addresses also matched those derived from the seed's private keys. Happy to share the script.