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.
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.
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
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.
53+===Address derivation===
54+
55+
56+[[bip-0341.mediawiki#cite_ref-22-0|BIP 341]] states: "If the spending conditions do not require a
57+script path, the output key should commit to an unspendable script path instead of having no
58+script path. This can be achieved by computing theoutput key point as
0script path. This can be achieved by computing the output key point as
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
Is there a extended key version defined for BIP 86 like there was in BIP 84?
This intentionally does not define one.
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
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.