Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

328, 390, 373: BIPs for MuSig2 derivation, descriptors, and PSBT fields #1540

Merged
merged 3 commits into from
Jun 25, 2024
Merged

328, 390, 373: BIPs for MuSig2 derivation, descriptors, and PSBT fields #1540

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
48ebcb2
BIP 328: add MuSig2 derivation BIP
achow101 Jan 15, 2024
6b9138c
BIP 390: Add MuSig2 descriptor BIP
achow101 Jan 15, 2024
806b8b8
BIP 373: add MuSig2 PSBT Fields BIP
achow101 Jan 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions README.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -1142,6 +1149,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
Expand Down Expand Up @@ -1212,6 +1226,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
Expand Down
60 changes: 60 additions & 0 deletions bip-0174.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the specification for the descriptor says that keys must be sorted with KeySort. If unsorted keys are allowed here, then its possible to have a psbt for a musig aggregate key that's not expressible in a descriptor. Maybe that's ok, just flagging it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.

makes sense, you want PSBTs to be a super-set of what you can express in a descriptor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).

There's no descriptor in psbts.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right I was commenting on KeySort-ing the participant keys in the descriptor. Seemed on-topic for this thread but I'll put the comment where it belongs.

|
|
| 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>
Expand Down Expand Up @@ -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>
Expand Down
80 changes: 80 additions & 0 deletions bip-0328.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
<pre>
BIP: 328
Layer: Applications
Title: Derivation Scheme for MuSig2 Aggregate Keys
Author: Ava Chow <[email protected]>
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>.
achow101 marked this conversation as resolved.
Show resolved Hide resolved
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.
Loading