mirror of
				https://github.com/bitcoin/bips.git
				synced 2025-10-27 14:09:10 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			98 lines
		
	
	
		
			4.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			98 lines
		
	
	
		
			4.9 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: Proposed
 | |
|   Type: Informational
 | |
|   Created: 2024-06-04
 | |
|   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==
 | |
| 
 | |
| * Aggregate pubkey <tt>0354240c76b8f2999143301a99c7f721ee57eee0bce401df3afeaa9ae218c70f23</tt>
 | |
| ** Synthetic xpub <tt>xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwXEKGEouzXE6QLLRxjatMcLLzJ5LV5Nib1BN7vJg6yp45yHHRbm</tt>
 | |
| ** Keys:
 | |
| *** <tt>03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9</tt>
 | |
| *** <tt>02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9</tt>
 | |
| * Aggregate pubkey <tt>0290539eede565f5d054f32cc0c220126889ed1e5d193baf15aef344fe59d4610c</tt>
 | |
| ** Synthetic xpub <tt>xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwVk5TFJk8Tw5WAdV3DhrGfbFA216sE9BsQQiSFTdudkETnKdg8k</tt>
 | |
| ** Keys:
 | |
| *** <tt>02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9</tt>
 | |
| *** <tt>03DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659</tt>
 | |
| *** <tt>023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66</tt>
 | |
| * Aggregate pubkey <tt>022479f134cdb266141dab1a023cbba30a870f8995b95a91fc8464e56a7d41f8ea</tt>
 | |
| ** Synthetic xpub <tt>xpub661MyMwAqRbcFt6tk3uaczE1y6EvM1TqXvawXcYmFEWijEM4PDBnuCXwwUvaZYpysLX4wN59tjwU5pBuDjNrPEJbfxjLwn7ruzbXTcUTHkZ</tt>
 | |
| ** Keys:
 | |
| *** <tt>02DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659</tt>
 | |
| *** <tt>023590A94E768F8E1815C2F24B4D80A8E3149316C3518CE7B7AD338368D038CA66</tt>
 | |
| *** <tt>02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9</tt>
 | |
| *** <tt>03935F972DA013F80AE011890FA89B67A27B7BE6CCB24D3274D18B2D4067F261A9</tt>
 | |
| 
 | |
| ==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==
 | |
| 
 | |
| A Python reference implementation is available in this BIP's [[bip-0328|Auxiliary Files]].
 | |
| 
 | |
| ==Acknowledgements==
 | |
| 
 | |
| Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
 | |
| participated in discussions on this topic.
 |