Possible modifications to BIP 371 #24492

In #22558 @sipa suggested some possible changes to BIP 371.

Thinking about later integration with MuSig(2), I think it's somewhat unfortunate that the currently suggested PSBT_IN_TAP_BIP32_DERIVATION field conveys both (a) which keys are participating in which leaves and (b) how those are derived. Post-MuSig2, I expect that often keys will be present that aren't directly BIP32-derived, but are a MuSig* aggregate of BIP32-derived keys. It's not impossible to integrate that on top here, but it'd involve some duplication.

My suggestion would be to have these fields:

PSBT_IN_TAP_KEY_SIG: unmodified PSBT_IN_TAP_SCRIPT_SIG: unmodified PSBT_IN_TAP_LEAF_SCRIPT: unmodified PSBT_IN_TAP_KEY_TWEAK: concatenation of PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_MERKLE_ROOT; it conveys "the output key is a tweak of this key with this Merkle root". PSBT_IN_TAP_KEY_IN_SCRIPT: like PSBT_IN_TAP_BIP32_DERIVATION now, but without the BIP32 path; it just conveys "this key occurs in these leaves". PSBT_IN_TAP_BIP32_DERIVATION: like PSBT_IN_TAP_BIP32_DERIVATION, but without the list of leaf hashes. It can be used for (a) the output key directly (b) the internal key (provided in PSBT_IN_TAP_KEY_TWEAK) of (c) a key occurring in a leaf script (provided by PSBT_IN_TAP_KEY_IN_SCRIPT). I'm also happy to take this to the ML if you think this deserves more discussion.

It was noted that BIP 371 is already in use in production by Ledger but the only Taproot field Ledger currently relies on is PSBT_IN_TAP_BIP32_DERIVATION. @bigspider added:

Leaving the 0x00 would not break anything as I understand it. If desired in order to have a clean standard, I suppose we can have a reasonable upgrade path by letting the next version of the app to skip the 0x00 if present and keeping this loose check for some time.

And @sanket1729:

I was thinking most keys would be BIP32 derived keys of a Musig2 aggregate like musig2(A,B,C)/* or BIP32 derived keys of a Musig2 aggregate of BIP32-derived keys, like musig2(A/, B/, C/)/? The case you mention seems like musgi2(A/, B/, C/*)

My 2 cents would be if Ledger/@bigspider are happy with the changes (and no one else is using BIP 371 in production) and those changes are better thought through for MuSig(2) integration we should make those changes. I'd much rather we get this right for the long term with all the different moving parts than tie our hands because BIP 371 is partially already being used.

I'm not very keen on pushing for changes if there are any implementations out there already. It's hard to know whether Ledger is the only one.

@afilini Since I saw you comment on PSBT/Taproot support in BDK just now on IRC, thoughts here?

PSBT_IN_TAP_KEY_TWEAK: concatenation of PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_MERKLE_ROOT; it conveys "the output key is a tweak of this key with this Merkle root".

I like this change, in general I don't see why we would have to set the INTERNAL_KEY if there's no MERKLE_ROOT to tweak it with. The only minor argument for keeping the current spec is that in the current BIP-371 there's a note that says that it's recommended to tweak the key with its own hash when there's no merkle root, so in that case having a single field might make it a bit more ambiguous in some cases.

With independent fields we could have said that INTERNAL_KEY must always be set (if the key has been tweaked in some way), but MERKLE_ROOT is only set if there's an actual tap script root, and if it's not provided the signer should assume that the key has been tweaked with its own hash. With a single field that has both it may look like there's a script committed in the key that you don't know of, although a signer could again just check if the MERKLE_ROOT corresponds to the key's hash or if it's different, and refuse to sign in that case.

PSBT_IN_TAP_KEY_IN_SCRIPT: like PSBT_IN_TAP_BIP32_DERIVATION now, but without the BIP32 path; it just conveys "this key occurs in these leaves". PSBT_IN_TAP_BIP32_DERIVATION: like PSBT_IN_TAP_BIP32_DERIVATION, but without the list of leaf hashes. It can be used for (a) the output key directly (b) the internal key (provided in PSBT_IN_TAP_KEY_TWEAK) of (c) a key occurring in a leaf script (provided by PSBT_IN_TAP_KEY_IN_SCRIPT).

I don't mind these changes, although I think in practice most signers would iterate them together as if they were still part of a single map, because you need the leaf hash to produce the signature. But if this help for MuSig it makes sense to separate them!

Closing this as although @bigspider seems happy with the proposed changes we can't be sure if other projects have already deployed. Hence after a consideration of trade-offs these proposed changes won't be made to BIP 371.

Also discussed in today's wallet meeting.