-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MuSig2 support #208
Comments
Edit: a more precise version of these specs was posted on Delving Bitcoin. BIP-0327 discusses the necessity to keep some state during a signing session. However, a "signing session" in BIP-0327 only refers to the production of a single signature. In the typical signing flow of a wallet, it's more logical to consider a session at the level of an entire transaction. All of the inputs of the transactions are likely to be obtained from the same descriptor, and the signer would produce the pubnonce/signature for all of them at the same time. Therefore, in the flow of BIP-0327, you would expect one MuSig2 signing session per input to be active at the same time. That's problematic as it would require to persist state for an unbounded number of signing sessions. Instead, we want a psbt-level session with a small state persisted on the device, that allows to complete a full signing flow for the entire PSBT; the necessary state for the each actual session for each internal input (possibly, one session per-input and per-placeholder of the wallet policy) can be synthetically generated. Signing flowFor now, we assume that the app can handle a single psbt-level session; this could be generalized to multiple parallel psbt-level sessions in the future. In the following, a session always refers to the psbt-level signing session. Phase 1: pubnonce generation: A PSBT is sent to the bitcoin app, and it does not contain any pubnonce.
Phase 2: partial signature generation: A PSBT is sent to the bitcoin app, and contains the pubnonces. **
Security considerationsState reuse avoidanceStoring the session in persistent memory only at the end of Phase 1, and deleting it before beginning Phase 2 simplifies auditing and making sure that there is no reuse of state across signing sessions. Security of synthetic randomnessGenerating Malleability of the PSBTIf the optional parameters are passed to the However, that does not constitute a security risk, as those parameters are only used as additional sources of entropy in |
Extend wallet policies with
musig
support, as tentatively specified here.For wallet policies, expressions of the form:
will suffice;
KEY
can be restricted to xpubs (although it's possible to generalize to other key expressions if there are use cases). It is unclear if there is any benefit in supporting things likemusig(KEY/**, ..., KEY/**)
, which seems inherently inefficient.References
Tasks:
musig
descriptorsmusig
descriptormusig
descriptor.musig()
(per this)musig
musig()
(per this)Add musig() xpub generation to Rust clientmoved to Add MuSig2 support to the Rust and JS client #303Add musig() xpub generation to JS clientmoved to Add MuSig2 support to the Rust and JS client #303Extensive testsmoved to Add more e2e tests for MuSig2 #302The text was updated successfully, but these errors were encountered: