Skip to content

Latest commit

 

History

History
80 lines (58 loc) · 3.35 KB

bip-0328.mediawiki

File metadata and controls

80 lines (58 loc) · 3.35 KB
Raw

  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

Table of Contents

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 868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965[1]. 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

  1. ^ Where does this constant chaincode come from? It is the SHA256 of the text MuSig2MuSig2MuSig2

Reference Implementation

TBD

Acknowledgements

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