Add register command for BIP388 policies

[Sjors]

First step towards #785.

Usage:

hwi --device-type ledger register --name MooSig --desc "tr(musig(@0,@1)" --key [00000001/87'/0'/0']xpub... --key [00000002/87'/0'/0']xpub...

{"hmac": "00......"}

For MuSig2 you can compare the hmac with the result from MooSig.

Strongly overlaps with #647.

[Sjors]

Rebased after #795 landed.

[Sjors]

I'll give this a rebase after #836.

I need to sync this up with the latest #794 (e2a7288, c3815ba), and consider cherry-picking 562fe54.

[achow101]

It seems like BitBox02 also has policy registration, so I would prefer if this could also be implemented for that as well. We should not be adding commands for one device only.

I strongly prefer for this to be generic and standardized. As of now, there is no standard for policy registration. Policies can be registered on BitBox02 but that seems to return nothing back to the user as they have enough storage to remember that registration. Conversely, Ledger returns the hmac. Since clearly not every device that can take policies will return the same thing, I think it would be better to say that the result value is some opaque binary result that has no meaning to the user. Rather, the interpretation of that blob occurs on a per-device basis, which users, and HWI for the most part, don't need to care about what that value is. We could also invent some encoding for it that can wrap the ledger's hmac, or signal that there is no value for the bitbox.

I also don't really like strictly following BIP 388 here in taking all of the fields directly from BIP 388 as separate positional arguments. Fundamentally, the policy is just a bastardized descriptor, and it should be straightforward to go from a descriptor to a policy. We have to massage the data into the device specific protocol stuff anyways. So instead of taking a policy, this could take a full descriptor, extract the keys and put in the substitutes, and verify that the rest of the descriptor meets the BIP 388 requirements. Then it can package up all of that to send to the device. This would reduce the number of parameters required and remove the requirement of the caller having to remember the correct key order.

Lastly, in addition to returning the policy registration result, I think the result should also include the descriptor/policy as part of the opaque string. Then the whole policy and proof can be supplied to signtx as a single argument rather than also requiring the user to know specifically which pieces to pass in. Both the policy and proof can be encoded into one big string that is visually meaningless to the user (e.g. base64 encode it) that can be passed in at a later time.

[Sjors]

We have to massage the data into the device specific protocol stuff anyways. So instead of taking a policy, this could take a full descriptor, extract the keys and put in the substitutes, and verify that the rest of the descriptor meets the BIP 388 requirements.

Having HWI convert from descriptors to BIP388 will make things easier on the Bitcoin Core side too, so that's nice.

In #785 (comment) I suggested that we simply store a max 255 byte blob from the device. A null blob means we don't store anything. That should be easy to make device independent.

I think the result should also include the descriptor/policy as part of the opaque string.

Oh but then it needs to be bigger. And the wallet still needs to know what blob to pass for which descriptor, so not sure if this helps at all.

cc @bigspider