brainstorming: support generalized descriptors

[bitcoin-core]

brainstorming: support generalized descriptors

[achow101]

What do you mean by generalized descriptors? I'm not sure that it is useful for us to support making complex descriptors. That seems like something that is better suited for a descriptor generator software. They could get an xpub from HWI and pass it to that software.

[instagibbs]

I mean the ability for the software to make importmulti entries, like now, but allowing things like multisig.

…

On Sat, Nov 17, 2018, 3:26 PM Andrew Chow ***@***.*** wrote: What do you mean by generalized descriptors? I'm not sure that it is useful for us to support making complex descriptors. That seems like something that is better suited for a descriptor generator software. They could get an xpub from HWI and pass it to that software. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFgC0xk69oENCFmpGmJwdYn5dbWS4dZnks5uwHDwgaJpZM4YnlNK> .

[Sjors]

This is also useful in the context of #137 (getdescriptors command), vs. the alternative approach I tried in #73 with descriptor templates.

For simple enough policies, e.g. M of N multisig, it makes sense for HWI to return descriptors based on params:

For example:

./hwi.py --fingerprint 0000000 getdescriptors --account 0 --multisig_threshold 2 --multisig_participants xpub1,xpub2
{
  "receive": [
    "sh(wpkh(...))",
    "wpkh(multi(2, xpub, xpub1, xpub2)/0/*)",
    "taproot(...)"
  ],
  "internal": [
     ....
  ]
}

This is very easy to build on what we have, and Bitcoin Core could use as soon as it has native descriptor support.

But for more complex policies, perhaps it's better if some other program gives us a template descriptor, we check if the hardware wallet can handle it, and then fill in our xpub.

./hwi.py --fingerprint 0000000 getdescriptors --receive "wpkh(multi(2, $xpub, xpub1, xpub2)/0/*)" --internal "wpkh(multi(2, $xpub, xpub1, xpub2/1/*)"
{
  "receive": "wpkh(multi(2, xpub, xpub1, xpub2)/0/*)"
  "internal": "wpkh(multi(2, xpub, xpub1, xpub2)/1/*)"
}

However, currently there is no such standard. Bitcoin Core also can't compose descriptors yet, it can only parse them or infer them from a script.

[Sjors]

Thinking about this a bit more, neither approach seems sufficient for an interactive MuSig setup. For that we may need to add a number of specific commands.

Once the key is produced we can use descriptors, but how will the device know that it controls some of that? I'm sure this, and Taproot, will require new firmware anyway, but it's useful to think about what the interaction might look like.