1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
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.
|
