mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
Merge pull request #1540 from achow101/musig2
328, 390, 373: BIPs for MuSig2 derivation, descriptors, and PSBT fields
This commit is contained in:
Mark "Murch" Erhardt
GitHub
commit
5d77440479
@ -1016,6 +1016,13 @@ Those proposing changes should consider that ultimately consent may rest with th
|
||||
| Informational
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0328.mediawiki|328]]
|
||||
| Applications
|
||||
| Derivation Scheme for MuSig2 Aggregate Keys
|
||||
| Ava Chow
|
||||
| Informational
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0329.mediawiki|329]]
|
||||
| Applications
|
||||
| Wallet Labels Export Format
|
||||
@ -1149,6 +1156,13 @@ Those proposing changes should consider that ultimately consent may rest with th
|
||||
| Standard
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0373.mediawiki|373]]
|
||||
| Applications
|
||||
| MuSig2 PSBT Fields
|
||||
| Ava Chow
|
||||
| Standard
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0380.mediawiki|380]]
|
||||
| Applications
|
||||
| Output Script Descriptors General Operation
|
||||
@ -1219,6 +1233,13 @@ Those proposing changes should consider that ultimately consent may rest with th
|
||||
| Informational
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0390.mediawiki|390]]
|
||||
| Applications
|
||||
| musig() Descriptor Key Expression
|
||||
| Ava Chow
|
||||
| Informational
|
||||
| Draft
|
||||
|-
|
||||
| [[bip-0431.mediawiki|431]]
|
||||
| Applications
|
||||
| Topology Restrictions for Pinning
|
||||
|
||||
@ -483,6 +483,52 @@ The currently defined per-input types are defined as follows:
|
||||
| 0, 2
|
||||
| [[bip-0371.mediawiki|371]]
|
||||
|-
|
||||
| MuSig2 Participant Public Keys
|
||||
| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
|
||||
| <33 byte plain aggregate pubkey>
|
||||
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
|
||||
be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the
|
||||
script were derived.
|
||||
| <tt><33 byte compressed pubkey>*</tt>
|
||||
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
|
||||
required for aggregation. If sorting was done, then the keys must be in the sorted order.
|
||||
|
|
||||
|
|
||||
| 0, 2
|
||||
| [[bip-0373.mediawiki|373]]
|
||||
|-
|
||||
| MuSig2 Public Nonce
|
||||
| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt>
|
||||
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
|
||||
| The compressed public key of the participant providing this nonce, followed by the plain public
|
||||
key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of
|
||||
the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the
|
||||
taproot output key, then the tapleaf hash must be omitted. The plain public key must be
|
||||
the key found in the script and not the aggregate public key that it was derived from, if it was
|
||||
derived from an aggregate key.
|
||||
| <tt><66 byte public nonce></tt>
|
||||
| The public nonce produced by the <tt>NonceGen</tt> algorithm.
|
||||
|
|
||||
|
|
||||
| 0, 2
|
||||
| [[bip-0373.mediawiki|373]]
|
||||
|-
|
||||
| MuSig2 Participant Partial Signature
|
||||
| <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
|
||||
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
|
||||
| The compressed public key of the participant providing this partial signature, followed by the
|
||||
plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
|
||||
of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
|
||||
the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
|
||||
be the key found in the script and not the aggregate public key that it was derived from, if it was
|
||||
derived from an aggregate key.
|
||||
| <tt><32 byte partial signature></tt>
|
||||
| The partial signature produced by the <tt>Sign</tt> algorithm.
|
||||
|
|
||||
|
|
||||
| 0, 2
|
||||
| [[bip-0373.mediawiki|373]]
|
||||
|-
|
||||
| Proprietary Use Type
|
||||
| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
|
||||
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
|
||||
@ -599,6 +645,20 @@ determine which outputs are change outputs and verify that the change is returni
|
||||
| 0, 2
|
||||
| [[bip-0371.mediawiki|371]]
|
||||
|-
|
||||
| MuSig2 Participant Public Keys
|
||||
| <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
|
||||
| <33 byte plain aggregate pubkey>
|
||||
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
|
||||
be in the script directly. It may instead be a parent public key from which the public keys in the
|
||||
script were derived.
|
||||
| <tt><33 byte compressed pubkey>*</tt>
|
||||
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
|
||||
required for aggregation. If sorting was done, then the keys must be in the sorted order.
|
||||
|
|
||||
|
|
||||
| 0, 2
|
||||
| [[bip-0373.mediawiki|373]]
|
||||
|-
|
||||
| Proprietary Use Type
|
||||
| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
|
||||
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
|
||||
|
||||
80
bip-0328.mediawiki
Normal file
80
bip-0328.mediawiki
Normal file
@ -0,0 +1,80 @@
|
||||
<pre>
|
||||
BIP: 328
|
||||
Layer: Applications
|
||||
Title: Derivation Scheme for MuSig2 Aggregate Keys
|
||||
Author: Ava Chow <me@achow101.com>
|
||||
Comments-Summary: No comments yet.
|
||||
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0328
|
||||
Status: Draft
|
||||
Type: Informational
|
||||
Created: 2024-01-15
|
||||
License: CC0-1.0
|
||||
</pre>
|
||||
|
||||
==Abstract==
|
||||
|
||||
This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2
|
||||
aggregate public key and how such keys should be used for key derivation.
|
||||
|
||||
==Copyright==
|
||||
|
||||
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
|
||||
|
||||
==Motivation==
|
||||
|
||||
Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable
|
||||
from a random public key. The cosigners need a method for generating additional aggregate pubkeys
|
||||
to follow the best practice of using a new address for every payment.
|
||||
|
||||
The obvious method is for the cosigners to generate multiple public keys and produce a
|
||||
new aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script
|
||||
works where all of the cosigners share their extended public keys and do derivation to produce
|
||||
the multisig script. The same could be done with MuSig2 and instead of producing a multisig script,
|
||||
the result would be a MuSig2 aggregate pubkey.
|
||||
|
||||
However, it is much simpler to be able to derive from a single extended public key instead of having
|
||||
to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking
|
||||
public key, the aggregate public can be used in this way. This reduces the storage and computation
|
||||
requirements for generating new aggregate pubkeys.
|
||||
|
||||
==Specification==
|
||||
|
||||
A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting
|
||||
the depth to 0, the child number to 0, and attaching a chaincode with the byte string
|
||||
<tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this
|
||||
constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>.
|
||||
This fixed chaincode should be used by all such synthetic xpubs following this specification.
|
||||
Unhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since
|
||||
the aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate
|
||||
public key that will be used in this way shares the same privacy concerns as typical xpubs.
|
||||
|
||||
Furthermore, as there is no aggregate private key, only unhardened derivation from the aggregate
|
||||
public key is possible.
|
||||
|
||||
When signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key
|
||||
being signed for. The I<sub>L</sub> value computed in ''CKDpub'' is the tweak used at each
|
||||
derivation step. These are provided in the session context, each with a tweak mode of plain
|
||||
(''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the
|
||||
partial signatures.
|
||||
|
||||
==Test Vectors==
|
||||
|
||||
TBD
|
||||
|
||||
==Backwards Compatibility==
|
||||
|
||||
Once a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened
|
||||
derivation can be done, and the signers will be able to produce a signature for any derived children.
|
||||
|
||||
==Rationale==
|
||||
|
||||
<references/>
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
TBD
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
|
||||
participated in discussions on this topic.
|
||||
216
bip-0373.mediawiki
Normal file
216
bip-0373.mediawiki
Normal file
@ -0,0 +1,216 @@
|
||||
<pre>
|
||||
BIP: 373
|
||||
Layer: Applications
|
||||
Title: MuSig2 PSBT Fields
|
||||
Author: Ava Chow <me@achow101.com>
|
||||
Comments-Summary: No comments yet.
|
||||
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0373
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Created: 2024-01-15
|
||||
License: CC0-1.0
|
||||
</pre>
|
||||
|
||||
==Introduction==
|
||||
|
||||
===Abstract===
|
||||
|
||||
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP
|
||||
327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for
|
||||
the participants' keys, the public nonces, and the partial signatures produced with MuSig2.
|
||||
|
||||
===Copyright===
|
||||
|
||||
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
|
||||
|
||||
===Motivation===
|
||||
|
||||
BIP 327 specifies a way to create BIP 340 compatible public keys and signatures using the MuSig2
|
||||
Multi-Signature scheme. The existing PSBT fields are unable to support MuSig2 as it introduces new
|
||||
concepts and additional rounds of communication. Therefore new fields must be defined to allow PSBTs
|
||||
to carry the information necessary to produce a valid signature with MuSig2.
|
||||
|
||||
==Specification==
|
||||
|
||||
The new per-input types are defined as follows:
|
||||
|
||||
{|
|
||||
! Name
|
||||
! <tt><keytype></tt>
|
||||
! <tt><keydata></tt>
|
||||
! <tt><valuedata></tt>
|
||||
! Versions Requiring Inclusion
|
||||
! Versions Requiring Exclusion
|
||||
! Versions Allowing Inclusion
|
||||
|-
|
||||
| rowspan="2"|MuSig2 Participant Public Keys
|
||||
| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
|
||||
| <tt><33 byte plain aggregate pubkey></tt>
|
||||
| <tt><33 byte compressed pubkey>*</tt>
|
||||
| rowspan="2"|
|
||||
| rowspan="2"|
|
||||
| rowspan="2"| 0, 2
|
||||
|-
|
||||
| The MuSig2 aggregate plain public key<ref>'''Why the plain aggregate public key instead of x-only?'''
|
||||
BIP 32 requires public keys to include their evenness byte. Aggregate public keys are expected to be
|
||||
derived from, following [[bip-0328.mediawiki|BIP 328]], and therefore will
|
||||
need to include the evenness. Furthermore, PSBT_IN_TAP_BIP32_DERIVATION fields include fingerprints
|
||||
to identify master keys, and these fingerprints require full compressed public keys. By including
|
||||
the aggregate key as a full public key, signers that are unaware of the MuSig2 outside of the PSBT
|
||||
will still be able to identify which keys are derived from the aggregate key by computing and then
|
||||
comparing the fingerprints. This is necessary for the signer to apply the correct tweaks to their
|
||||
partial signature.</ref> from the <tt>KeyAgg</tt> algorithm. This key may or may not
|
||||
be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the
|
||||
script were derived.
|
||||
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
|
||||
required for aggregation. If sorting was done, then the keys must be in the sorted order.
|
||||
|-
|
||||
| rowspan="2"|MuSig2 Public Nonce
|
||||
| rowspan="2"|<tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt>
|
||||
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
|
||||
| <tt><66 byte public nonce></tt>
|
||||
| rowspan="2"|
|
||||
| rowspan="2"|
|
||||
| rowspan="2"| 0, 2
|
||||
|-
|
||||
| The compressed public key of the participant providing this nonce, followed by the plain public
|
||||
key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of
|
||||
the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the
|
||||
taproot output key, then the tapleaf hash must be omitted. The plain public key must be
|
||||
the key found in the script and not the aggregate public key that it was derived from, if it was
|
||||
derived from an aggregate key.
|
||||
| The public nonce produced by the <tt>NonceGen</tt> algorithm.
|
||||
|-
|
||||
| rowspan="2"|MuSig2 Participant Partial Signature
|
||||
| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
|
||||
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
|
||||
| <tt><32 byte partial signature></tt>
|
||||
| rowspan="2"|
|
||||
| rowspan="2"|
|
||||
| rowspan="2"| 0, 2
|
||||
|-
|
||||
| The compressed public key of the participant providing this partial signature, followed by the
|
||||
plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
|
||||
of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
|
||||
the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
|
||||
be the key found in the script and not the aggregate public key that it was derived from, if it was
|
||||
derived from an aggregate key.
|
||||
| The partial signature produced by the <tt>Sign</tt> algorithm.
|
||||
|}
|
||||
|
||||
The new per-output types are defined as follows:
|
||||
|
||||
{|
|
||||
! Name
|
||||
! <tt><keytype></tt>
|
||||
! <tt><keydata></tt>
|
||||
! <tt><valuedata></tt>
|
||||
! Versions Requiring Inclusion
|
||||
! Versions Requiring Exclusion
|
||||
! Versions Allowing Inclusion
|
||||
|-
|
||||
| rowspan="2"|MuSig2 Participant Public Keys
|
||||
| rowspan="2"|<tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
|
||||
| <tt><33 byte compressed pubkey></tt>
|
||||
| <tt><33 byte compressed pubkey>*</tt>
|
||||
| rowspan="2"|
|
||||
| rowspan="2"|
|
||||
| rowspan="2"|0, 2
|
||||
|-
|
||||
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
|
||||
be in the script directly. It may instead be a parent public key from which the public keys in the
|
||||
script were derived.
|
||||
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
|
||||
required for aggregation. If sorting was done, then the keys must be in the sorted order.
|
||||
|}
|
||||
|
||||
==Roles==
|
||||
|
||||
===Updater===
|
||||
|
||||
When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is
|
||||
aware if, it can add a <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> field containing the public keys
|
||||
of the participants. This aggregate public key may be directly in the script, the Taproot internal
|
||||
key, the Taproot output key, or a public key from which the key in the script was derived from.
|
||||
|
||||
An aggregate public key that appears directly in the script or internal key may be from the result
|
||||
of deriving child pubkeys from participant xpubs. If the updater has this derivation information, it
|
||||
should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> for each participant public key.
|
||||
|
||||
If the public key found was derived from an aggregate public key, then all MuSig2 PSBT fields for
|
||||
that public key should contain the aggregate public key rather than the found pubkey itself. The
|
||||
updater should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> that contains the derivation path used
|
||||
to derive the found pubkey from the aggregate pubkey.
|
||||
Derivation from the aggregate pubkey can be assumed to follow [[bip-0328.mediawiki|BIP 328]]
|
||||
if there is no <tt>PSBT_IN_GLOBAL_XPUB</tt> that specifies the synthetic xpub for the aggregate
|
||||
public key.
|
||||
|
||||
Updaters should add <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS</tt> and
|
||||
<tt>PSBT_OUT_TAP_BIP32_DERIVATION</tt> similarly to inputs to aid in change detection.
|
||||
|
||||
===Signer===
|
||||
|
||||
To determine whether a signer is a participant in the MuSig2 aggregate key, the signer should first
|
||||
look at all <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> and see if any key which it knows the
|
||||
private key for appears as a participant in any aggregate pubkey. Signers should also check whether
|
||||
any of the keys in <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> belong to it, and if any of those keys
|
||||
appear in as a participant in <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt>.
|
||||
|
||||
For each aggregate public key that the signer is a participant of that it wants
|
||||
to produce a signature for, if the signer does not find an existing
|
||||
<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one using
|
||||
the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
|
||||
nonce that is added in a <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field. However
|
||||
signers must keep in mind that '''improper nonce usage can compromise private
|
||||
keys.''' Please see BIP 327 for best practices on nonce generation and usage.
|
||||
|
||||
Once all signers have added their <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> fields, each signer will perform
|
||||
the <tt>NonceAgg</tt> algorithm followed by the <tt>Sign</tt> algorithm in order to produce the
|
||||
partial signature for their key. The result will be added to the PSBT in a
|
||||
<tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt> field.
|
||||
|
||||
Signers must remember to apply any relevant tweaks such as a tweak that is the result of performing
|
||||
BIP 32 unhardened dervation with the aggregate public key as the parent key.
|
||||
|
||||
If all other signers have provided a <tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt>, then the final signer may
|
||||
perform the <tt>PartialSigAgg</tt> algorithm and produce a BIP 340 compatible signature that can be
|
||||
placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>.
|
||||
|
||||
===Finalizer===
|
||||
|
||||
A finalizer may perform the same <tt>PartialSigAgg</tt> step as the final signer if it has not
|
||||
already been done.
|
||||
|
||||
Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it
|
||||
as such.
|
||||
|
||||
==Backwards Compatibility==
|
||||
|
||||
These are simply new fields added to the existing PSBT format. Because PSBT is designed to be
|
||||
extensible, old software will ignore the new fields.
|
||||
|
||||
Reusing <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> to provide derivation paths for participant public
|
||||
keys may cause software unaware of MuSig2 to produce a signature for that public key. This is still
|
||||
safe. If that public key does not directly appear in the leaf script that was signed, then the
|
||||
signature produced will not be useful and so cannot be replayed. If the public key does directly
|
||||
appear in the leaf script, then the signer will have validated the script as if it did not involve a
|
||||
MuSig2 and will have found it acceptable in order for it to have produced a signature. In either
|
||||
case, producing a signature does not give rise to the possibility of losing funds.
|
||||
|
||||
==Test Vectors==
|
||||
|
||||
TBD
|
||||
|
||||
==Rationale==
|
||||
|
||||
<references/>
|
||||
|
||||
==Reference implementation==
|
||||
|
||||
The reference implementation of the PSBT format is available at TBD.
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
Thanks to Sanket Kanjalkar whose notes on this topic formed the initial basis of this BIP. Also
|
||||
thanks to Pieter Wuille, Jonas Nick, Tim Ruffing, Marko Bencun, Salvatore Ingala, and all others who
|
||||
have participated in discussions about these fields.
|
||||
@ -332,4 +332,7 @@ This Table lists all available Script expressions and the BIPs specifying them.
|
||||
|-
|
||||
| <tt>tr(KEY)</tt>, <tt>tr(KEY, TREE)</tt>
|
||||
| [[bip-0386.mediawiki|386]]
|
||||
|-
|
||||
| <tt>musig(KEY, KEY, ..., KEY)</tt>
|
||||
| [[bip-0390.mediawiki|390]]
|
||||
|}
|
||||
|
||||
117
bip-0390.mediawiki
Normal file
117
bip-0390.mediawiki
Normal file
@ -0,0 +1,117 @@
|
||||
<pre>
|
||||
BIP: 390
|
||||
Layer: Applications
|
||||
Title: musig() Descriptor Key Expression
|
||||
Author: Ava Chow <me@achow101.com>
|
||||
Comments-Summary: No comments yet.
|
||||
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0390
|
||||
Status: Draft
|
||||
Type: Informational
|
||||
Created: 2024-01-15
|
||||
License: CC0-1.0
|
||||
</pre>
|
||||
|
||||
==Abstract==
|
||||
|
||||
This document specifies a <tt>musig()</tt> key expression for output script descriptors.
|
||||
<tt>musig()</tt> expressions take multiple keys and produce an aggregate public key using BIP 327.
|
||||
|
||||
==Copyright==
|
||||
|
||||
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
|
||||
|
||||
==Motivation==
|
||||
|
||||
BIP 327 introduces the MuSig2 Multi-Signature scheme. It is useful to have a way for keys to be used
|
||||
in a MuSig2 aggregate key to be expressed in descriptors so that wallets can more easily use MuSig2.
|
||||
|
||||
==Specification==
|
||||
|
||||
A new key expression is defined: <tt>musig()</tt>.
|
||||
|
||||
===<tt>musig(KEY, KEY, ..., KEY)</tt>===
|
||||
|
||||
The <tt>musig(KEY, KEY, ..., KEY)</tt> expression can only be used inside of a <tt>tr()</tt>
|
||||
expression as a key expression. It additionally cannot be nested within another <tt>musig()</tt>
|
||||
expression. Repeated participant public keys are not allowed. The aggregate public key is produced
|
||||
by using the <tt>KeyAgg</tt> algorithm on all KEYs specified in the expression after performing all
|
||||
specified derivation. As with script expressions, KEY can contain child derivation specified by
|
||||
<tt>/*</tt>. A new aggregate public key will be computed for each child index. Keys must be sorted
|
||||
with the <tt>KeySort</tt> algorithm after all derivation and prior to aggregation<ref>'''Why must
|
||||
the keys be sorted prior to aggregation?''' Although the descriptor's written form sets an order
|
||||
for the keys that could be used for aggregation, the order should not matter as MuSig2 philosophically
|
||||
operates over a set of keys, with the order merely being an implementation detail in aggregation
|
||||
itself. Requiring sorting of keys prior to aggregation enforces this philosophy as keys can be
|
||||
written in the descriptor in any order with the end result still being the same. Furthermore, this
|
||||
aids with recovery where the descriptor was not backed up as users will not need to also have
|
||||
backed up, or guess, the correct order of keys.</ref>.
|
||||
|
||||
===<tt>musig(KEY, KEY, ..., KEY)/NUM/.../*</tt>===
|
||||
|
||||
<tt>musig(KEY, KEY, ..., KEY)/NUM/.../*</tt> expressions are also allowed, with the same usage
|
||||
restrictions as in the previous section. The aggregate public key
|
||||
is first computed as described above, with the keys also being sorted after all derivation and prior
|
||||
to aggreation. Then further BIP 32 derivation will be performed on the aggregate public key as described in
|
||||
[[bip-0328.mediawiki|BIP 328]]. As there is no aggregate private key,
|
||||
only unhardened derivation from the aggregate public key is allowed, and thus the derivation steps
|
||||
following the <tt>musig()</tt> expression cannot contain
|
||||
<tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation.
|
||||
For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from
|
||||
xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>.
|
||||
|
||||
==Test Vectors==
|
||||
|
||||
Valid descriptors containing followed by the scripts they produce. Descriptors involving derived child keys
|
||||
will have the 0th, 1st, and 2nd scripts listed.
|
||||
|
||||
* <tt>rawtr(musig(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
** <tt>5120789d937bade6673538f3e28d8368dda4d0512f94da44cf477a505716d26a1575</tt>
|
||||
* <tt>tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
** <tt>512079e6c3e628c9bfbce91de6b7fb28e2aec7713d377cf260ab599dcbc40e542312</tt>
|
||||
* <tt>rawtr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*)</tt>
|
||||
** <tt>51209508c08832f3bb9d5e8baf8cb5cfa3669902e2f2da19acea63ff47b93faa9bfc</tt>
|
||||
** <tt>51205ca1102663025a83dd9b5dbc214762c5a6309af00d48167d2d6483808525a298</tt>
|
||||
** <tt>51207dbed1b89c338df6a1ae137f133a19cae6e03d481196ee6f1a5c7d1aeb56b166</tt>
|
||||
* <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*,pk(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9))</tt>
|
||||
** <tt>51201d377b637b5c73f670f5c8a96a2c0bb0d1a682a1fca6aba91fe673501a189782</tt>
|
||||
** <tt>51208950c83b117a6c208d5205ffefcf75b187b32512eb7f0d8577db8d9102833036</tt>
|
||||
** <tt>5120a49a477c61df73691b77fcd563a80a15ea67bb9c75470310ce5c0f25918db60d</tt>
|
||||
* <tt>tr(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,pk(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*))</tt>
|
||||
** <tt>512068983d461174afc90c26f3b2821d8a9ced9534586a756763b68371a404635cc8</tt>
|
||||
** <tt>5120368e2d864115181bdc8bb5dc8684be8d0760d5c33315570d71a21afce4afd43e</tt>
|
||||
** <tt>512097a1e6270b33ad85744677418bae5f59ea9136027223bc6e282c47c167b471d5</tt>
|
||||
|
||||
Invalid descriptors
|
||||
|
||||
* <tt>musig()</tt> is not allowed in <tt>pk()</tt>: <tt>pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>pkh()</tt>: <tt>pkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>wpkh()</tt>: <tt>wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>combo()</tt>: <tt>combo(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>sh(wpkh())</tt>: <tt>sh(wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>sh(wsh())</tt>: <tt>sh(wsh(pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>wsh()</tt>: <tt>wsh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* <tt>musig()</tt> is not allowed in <tt>sh()</tt>: <tt>sh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))</tt>
|
||||
* Ranged <tt>musig()</tt> requires all participants to be xpubs: <tt>tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)/0/0)</tt>
|
||||
* Cannot have ranged participants if <tt>musig()</tt> is also ranged: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*)</tt>
|
||||
* <tt>musig()</tt> cannot have hardened derivation steps: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0h/*)</tt>
|
||||
* <tt>musig()</tt> cannot have hardened child derivation: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*h)</tt>
|
||||
|
||||
==Backwards Compatibility==
|
||||
|
||||
<tt>musig()</tt> expressions use the format and general operation specified in
|
||||
[[bip-0380.mediawiki|BIP 380]]. As these are a set of wholly new expressions, they are not compatible
|
||||
with any implementation. However the keys are produced using a standard process so existing software
|
||||
are likely to be familiar with them.
|
||||
|
||||
==Rationale==
|
||||
|
||||
<references/>
|
||||
|
||||
==Reference Implementation==
|
||||
|
||||
TBD
|
||||
|
||||
==Acknowledgements==
|
||||
|
||||
Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
|
||||
participated in discussions on this topic.
|
||||
Loading…
Reference in New Issue
Block a user