mirror of
https://github.com/bitcoin/bips.git
synced 2025-10-27 14:09:10 +00:00
81 lines
3.4 KiB
Plaintext
81 lines
3.4 KiB
Plaintext
<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.
|