Consider implementing BIP67 (sortedmulti)

[prusnak]

BIP67 defines that keys within MultisigRedeemScriptType should be sorted. We currently don't do this, because the adoption of such standard was quite low when we were implementing multisig.

We might want to add it now to fully support sortedmulti in Bitcoin descriptors.

That said, this seems like a quite big change to how we do things in the legacy code. I have not looked into core code yet.

Related issue: https://github.com/bitcoin-core/HWI/issues/487

[matejcik]

I believe this can be handled on the client side, by submitting MultisigRedeemScriptType with keys sorted according to BIP-67. This is what the fix to bitcoin-core/HWI#487 is doing. Note that this can always be done because the client must know the values of the pubkeys before requesting the address (or signature) from Trezor.

A thing that could make sense on Trezor: instead of sorting on device-side, rejecting multisigs that aren't correctly sorted.

I don't know if there is any advantage to doing that. @prusnak or @andrewkozlik, any comments?

[prusnak]

Sorted pubkeys in MultisigRedeemScriptType.nodes is one thing, while having sorted final derived pubkeys (when MultisigRedeemScriptType.address_n is not empty) is another thing and this is what this issue is about.

The latter cannot be easily achieved on the client side unless the client performs all derivations before sending the keys to the device.

[prusnak]

We could implement this by adding bool MultisigRedeemScriptType.sort_final_pubkeys field and let the client decide whether they want to follow BIP67 for the final keys (and possibly break the order given in MultisigRedeemScriptType.nodes) or they want to keep the order as is.