BIP 86: Key Derivation for Single Key P2TR Outputs

[achow101]

This BIP specifies a suggested derivation path to use for single key P2TR outputs, following BIP 43/44.

Test vectors and the actual derivation path value for the purpose will be set after receiving a BIP number.

[dr-orlovsky]

Have you seen by earlier ideas around more generic support for both single- and multisig wallets for P2TR in bitcoin-dev?

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018381.html

[achow101]

Have you seen by earlier ideas around more generic support for both single- and multisig wallets for P2TR in bitcoin-dev?

Yes, but I think more complicated derivation schemes can come later. Using the system we already have is the path of least resistance and will allow for faster adoption of Taproot in current wallets.

[luke-jr]

Assigned BIP number 86

[benthecarman]

Is there a extended key version defined for BIP 86 like there was in BIP 84?

https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#extended-key-version

[achow101]

Is there a extended key version defined for BIP 86 like there was in BIP 84?

This intentionally does not define one.

[benthecarman]

Is there a extended key version defined for BIP 86 like there was in BIP 84?

This intentionally does not define one.

I think it'd be worthwhile adding the reasoning to the BIP

[Rspigler]

I've been away, so apologies for the post-merge comments.

I agree with @achow101 's comments on the ML - I believe this is mostly unnecessary with the use of descriptors, but as long as this is for single-sig only, ACK, as it can help with adoption. Hopefully we will eventually move away from this however.

[benma]

Small post-merge comment: The test vectors contain addresses, so it would be great if the BIP mentioned that the addresses are bech32m (BIP-350).