Add Labels/Groups to Output Descriptors #21197

Output Descriptors do not contain labels.

Having labels for the descriptors could greatly enhance the UX of the wallets using these.

We could use syntax similar to this one to introduce labels. The characters {} are unused yet in the descriptors and the Checksums section mentions that using these does not decrease the error detection ability of the currently used checksum.

sh(multi(2,{Alice}022f01e5e15cca351daff3843fb70f3c2f0a1bdd05e5af888a67784ef3e10a2a01,{Bob}03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe))

or

wsh(sortedmulti(1,{Alice}xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,{Bob}xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))

Related to https://github.com/nunchuk-io/bips/pull/1 where the need originated from.

Having labels also is also beneficial for scenarios where no multisig is used, because that allows the naming of exported descriptors for watch-only wallet, e.g.

pkh({Corporate Cold Wallet}[d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/0/*)

Introducing labels also naturally creates a format for descriptor templates, where a label without the following key denotes a "slot" where the key can be "inserted" in the course of the multisig setup.

wsh(multi(1,{Alice},{Bob})) can be useful especially for setups where the order of keys is important (with more complex miniscript-extended descriptors, for example: wsh(or(multi(2,{Alice},{Bob},{Carol}), older(1000,{Dylan})))

The template can be partially specified: wsh(or(multi(2,{Alice},{Bob}022f01e5e15cca351daff3843fb70f3c2f0a1bdd05e5af888a67784ef3e10a2a01,{Carol}), older(1000,{Dylan})))

This could be useful.

Earlier I thought the current descriptor language only captures on-chain stuff, but actually it is not true. Key origin information is actually off-chain data. So the language already adds metadata to the script. Labels would just be an extension of that.

Concept ACK. This would make verifying descriptors simpler

So far my philosophy has been that descriptors should contain all information a signer may need in order to sign (or decide whether to sign). That includes things that may end up on chain (keys, scripts), but also things a signer may need to derive the key (origin info).

My thinking is that human identification information like this would go in a different layer, e.g. in things that compile to descriptors. One reason for that is trying to not put too much complexity into it, especially if the hope is at one point having more interoperable implementations.

On the other hand, this feature itself doesn't hurt, and doesn't add much complexity.

I realized this is related to #17190 and #21199 - i.e. ranges, groups and labels are all connected together.

I see two strong use-cases for descriptors grouping/labels.

Let's imagine each descriptor group has a title, consists of one or several keys with title and descriptors are operating within these keys. There are two strong usecases for this:

a) BIP44/49/84 accounts, e.g.

{
  "title": "Segwit Account [#2](/bitcoin-bitcoin/2/)",
  "keys": [
    { "title": "receiving", "key": "xpubA/0"},
    { "title": "change", "key": "xpubA/1"},
  ],
  "descriptors": [
    "pkh({receiving}/*)",
    "pkh({change}/*)",
  ]
}

b) multisig, e.g.

{
  "title": "Corporate Wallet",
  "keys": [
    { "title": "Alice", "key": "xpubA/0"},
    { "title": "Bob", "key": "xpubB/0"},
    { "title": "Carol", "key": "xpubC/0"},
  ],
  "descriptors": [
    "wsh(sortedmulti(2,{Alice},{Bob},{Carol}))",
  ]
}

If we had a standard that defines this, we would solve the need for labels and ranges at once.

Concept ACK. I think this would help alleviate @sipa 's concern?

In the multisig example, the wallet doesn't have any receiving change keys/descriptors?

descriptors should contain all information a signer may need in order to sign (or decide whether to sign).

I can say with confidence labels are used to trace output contacts from transaction to transaction at least in Chaincase and Wasabi. Keeping labels of which contacts know of each output informs signing decisions of their resulting privacy. We are going to see more and more of this client-side chain analysis help preserve privacy. This information can reveal what contacts can follow a transaction when funded by each output. It's mostly manual now but is being automated by software.

I recognize this is different from how we may have thought of labels in the past to remember what we purchased or why. Regardless of whether out-of-band label metadata ends up inside or outside of the descriptor I want to bring up the fact that output labels are increasingly used to make signing decisions.

Given that there are BIPS (38x) for this now, I think this is best discussed on the mailing list if it's still relevant.