BIP 328: Derivation Scheme for MuSig2 Aggregate Keys
2024-01-15
View on GitHub
  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

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 868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965Where does this constant chaincode come from? It is the SHA256 of the text MuSig2MuSig2MuSig2. 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 IL 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

Reference Implementation

TBD

Acknowledgements

Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who participated in discussions on this topic.


Updated

2024-07-17

See an issue with rendering or formatting? Submit an issue on GitHub

Do you find this site useful? Please consider donating some sats to support ongoing development.

bips.dev is presented by nickmonad

All content is owned and licensed by the respective author(s). This website makes no claim of ownership.