Add Musig2 module #716

jlest01 · 2024-07-29T00:41:46Z

This PR adds a musig module based on bitcoin-core/secp256k1#1479.
The structure is based on @sanket1729's BlockstreamResearch/rust-secp256k1-zkp#48, but I removed the code related to adaptor signatures.

There is an example file in examples/musig.rs and can be run with cargo run --example musig --features "rand std".
The ffi functions were added to secp256k1-sys/src/lib.rs and the API level functions to the new src/musig.rs file.

Kixunil

Awesome!!! I would wait until the upstream PR merges (and releases) before merging this but I'm looking forward to it. I gave it a quick look anyway.

Kixunil · 2024-07-29T06:36:27Z

src/musig.rs

+            // - Key agg cache is valid
+            // - extra input is 32 bytes
+            // This can only happen when the session id is all zeros
+            Err(MusigNonceGenError::ZeroSession)


IMO this should be just panic. It can only happen if someone passes wrong value to dangerous ID creation function.

src/musig.rs

tcharding · 2024-08-29T19:46:08Z

This is a 10 thousand line diff, is something commited that shouldn't be?

apoelstra · 2024-08-29T21:22:20Z

It updates the vendored library to bring in the upstream MuSig PR.

jlest01 · 2024-08-29T22:12:56Z

It updates the vendored library to bring in the upstream MuSig PR.

Yes. For now, only the last three commits matter for review purposes.
The others will be discarded when the upstream MuSig PR is merged.

tcharding · 2024-08-29T22:59:56Z

Cool, thanks. To clarify this is going to wait till upstream merges before being considered for merge, right? What sort of review are you chasing?

Kixunil · 2024-08-30T04:38:36Z

@tcharding I will definitely not ack this until it's upstream is released. However I appreciate the experiment/demo.

jlest01 · 2024-08-31T14:22:15Z

To clarify this is going to wait till upstream merges before being considered for merge, right? What sort of review are you chasing?

Yes, the idea is to wait for the upstream PR to be merged.
Regarding the review, I mean that the last three commits are the ones that are intended to be merged.

Kixunil · 2024-08-31T18:11:50Z

secp256k1-sys/src/lib.rs

+impl MusigSecNonce {
+    pub fn new() -> Self {
+        MusigSecNonce([0; MUSIG_SECNONCE_LEN])
+    }


Isn't this highly misleading? If it's all-zeros it's not a nonce and thus broken. Where would one need it?

Same as here: #716 (comment)

Kixunil · 2024-08-31T18:12:45Z

secp256k1-sys/src/lib.rs

+        MusigSecNonce([0; MUSIG_SECNONCE_LEN])
+    }
+
+    /// Don't use this. Refer to the documentation of wrapper APIs in the crate.


The documentation of these methods is intended for the higher-level API implementors not for for end consumers so it should rather properly describe what's going on here.

Done. Thanks.

Kixunil · 2024-08-31T18:13:07Z

secp256k1-sys/src/lib.rs

+impl_raw_debug!(MusigPubNonce);
+
+impl MusigPubNonce {
+    pub fn new() -> Self {


Looks also broken.

Same as here: #716 (comment)

Kixunil · 2024-08-31T18:14:24Z

secp256k1-sys/src/lib.rs

+    fn default() -> Self {
+        Self::new()
+    }
+}


It looks to me that none of these Defaults should exist. People should just use arrays or MaybeUninit<T> to represent the uninitialized state.

Are you suggesting something like this ?

let key_agg_cache = MaybeUninit::<ffi::MusigKeyAggCache>::uninit(); let mut key_agg_cache = key_agg_cache.assume_init();

This will cause UB (without MaybeUninit::write).
The reason for pub fn new() is that the internal array is private (ex: pub struct MusigKeyAggCache([c_uchar; MUSIG_KEYAGG_LEN]);), which is consistent with the other structs in the code.

No, provide a function that constructs initialized types only.

Oh, now I see that I was confused because these are the FFI structs. However, I still maintain they are highly confusing.

The correct usage (inside secp256k1::musig::MusigKeyAggCache::new) is this:

let mut key_agg_cache = MaybeUninit::<ffi::MusigKeyAggCache>::uninit(); let mut agg_pk = MaybeUninit::<ffi::XOnlyPublicKey>::uninit(); unsafe { if ffi::secp256k1_musig_pubkey_agg( cx, agg_pk.as_mut_ptr(), key_agg_cache.as_mut_ptr(), pubkeys.as_ptr(), pubkey_ptrs.len(), ) == 0 { panic!(...); } else { // secp256k1_musig_pubkey_agg overwrites the cache and the key so this is sound. let key_agg_cache = key_agg_cache.assume_init(); let agg_pk = agg_pk.assume_init(); MusigKeyAggCache(key_agg_cache, pk); } }

Thanks for the clarification.
Done in 2ea5674

I've also applied the same approach to the other structs.

Kixunil · 2024-08-31T18:28:09Z

secp256k1-sys/src/lib.rs

+
+#[repr(C)]
+#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
+pub struct MusigPartialSignature([c_uchar; MUSIG_PART_SIG_LEN]);


FTR these struct declarations looked wrong but are indeed correct based on the current API.

Do you think they should be changed?

Kixunil · 2024-08-31T18:31:24Z

src/musig.rs

+#[derive(Debug, Clone, Copy, Eq, PartialEq, PartialOrd, Ord, Hash)]
+pub enum ParseError {
+    /// Length mismatch
+    ArgLenMismatch {


We usually name these InvalidLength.

Done. Thanks.

sanket1729 · 2024-11-06T00:45:51Z

Upstream was released yesterday

apoelstra · 2024-11-06T15:07:51Z

Can you rebase and format each commit with the nightly formatter? That should fix CI.

jlest01 · 2024-11-07T16:57:14Z

Can you rebase and format each commit with the nightly formatter? That should fix CI.

Yes, done. Thanks.

tcharding · 2024-11-11T03:58:19Z

Patch 1 can be removed now, right? Then your shellcheck CI fail should disappear.

philipr-za · 2025-01-28T14:25:40Z

src/musig.rs

+///
+/// MuSig differs from regular Schnorr signing in that implementers _must_ take
+/// special care to not reuse a nonce. If you cannot provide a `sec_key`, `session_secrand`
+/// UNIFORMLY RANDOM AND KEPT SECRET (even from other signers). Refer to libsecp256k1-zkp


The references to libsecp256k1-zkp and secp256k1-zkp in the comments below seem to be left over from Sanket's original PR?

Correct. Good catch.
Updated in 4012ed5

stevenroose · 2025-03-05T12:47:04Z

What is the status of this PR?

Kixunil · 2025-03-05T20:43:31Z

@stevenroose it needs reviewers, I guess. :) This is quite difficult to review. I really wanted to but it requires a significant chunk of undisrupted time and I had more pressing things to do. I suspect I might be able to do it Friday. The good news is over the previous reviews and some more digging I got to understand Musig much better so it should be easier now.

jirijakes · 2025-03-18T13:18:00Z

src/musig.rs

+#[derive(Debug, Clone, Copy, Eq, PartialEq, PartialOrd, Ord, Hash)]
+pub enum ParseError {
+    /// Parse Argument is malformed. This might occur if the point is on the secp order,
+    /// or if the secp scalar is outside of group order
+    MalformedArg,
+}


Wouldn't it make more sense to use Option in the from_byte_array functions? The underlying functions do not provide information about why they failed anyway, so this type is not too useful (unless it is expected to be expanded in the future, in which case it should be #[non_exhaustive]).

IMO we should make it #[non_exhaustive].

Even if we didn't intend to expand it, an empty error type is often better than Option (which is the case here since passing malformed argument is clearly an error as opposed to stuff like passing non-existing key to get function on a map).

jirijakes

As an exercise, I am adding test vectors from BIP327, so far they revealed this. Will continue tomorrow.

jirijakes · 2025-03-18T14:28:21Z

src/musig.rs

+    pub fn serialize(&self) -> [u8; 32] {
+        let mut data = MaybeUninit::<[u8; 32]>::uninit();


Suggested change

pub fn serialize(&self) -> [u8; 32] {

let mut data = MaybeUninit::<[u8; 32]>::uninit();

pub fn serialize(&self) -> [u8; ffi::MUSIG_PART_SIG_SERIALIZED_LEN] {

let mut data = MaybeUninit::<[u8; ffi::MUSIG_PART_SIG_SERIALIZED_LEN]>::uninit();

(Edited, previously suggested wrong constant)

jirijakes

Correcting my previous review comments.

Partial signature occupies 36 bytes in memory but it is 32 in serialized form.

jirijakes · 2025-03-19T00:16:58Z

src/musig.rs

+#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
+pub struct AggregatedSignature([u8; 64]);
+
+impl AggregatedSignature {


This one is missing from_byte_array.

jirijakes · 2025-03-19T01:55:37Z

secp256k1-sys/src/lib.rs

+pub const MUSIG_AGGNONCE_SERIALIZED_LEN: usize = 66;
+pub const MUSIG_PUBNONCE_SERIALIZED_LEN: usize = 66;
+pub const MUSIG_SESSION_LEN: usize = 133;
+pub const MUSIG_PART_SIG_LEN: usize = 36;


Suggested change

pub const MUSIG_PART_SIG_LEN: usize = 36;

pub const MUSIG_PART_SIG_LEN: usize = 36;

pub const MUSIG_PART_SIG_SERIALIZED_LEN: usize = 32;

FTR, I previously suggested changing MUSIG_PART_SIG_LEN to 32 but that is wrong. It really holds 36 bytes in memory, however, it is 32 bytes in serialized form. Therefore need for another constant.

Comments on the constants explaining this would be great too.

Good catch. Fixed the serialized size and also added comments explaining the constants.

jirijakes · 2025-03-19T01:57:57Z

src/musig.rs

+    /// # Errors:
+    ///
+    /// - MalformedArg: If the signature [`PartialSignature`] is out of curve order
+    pub fn from_byte_array(data: &[u8; ffi::MUSIG_PART_SIG_LEN]) -> Result<Self, ParseError> {


Suggested change

pub fn from_byte_array(data: &[u8; ffi::MUSIG_PART_SIG_LEN]) -> Result<Self, ParseError> {

pub fn from_byte_array(data: &[u8; ffi::MUSIG_PART_SIG_SERIALIZED_LEN]) -> Result<Self, ParseError> {

jirijakes · 2025-03-19T08:50:35Z

At some point, it would be useful to somehow have a way of creating SecretNonce from bytes, which is needed for testing, either of this module via test vectors or for downstream users.

The upstream does not provide parse function (there is no standard serialization) but it also needs to be able to create SecretNonces for its tests.

Test vectors contain secnonce as 97-byte, see footnote 11:

The algorithms as specified here assume that the secnonce is stored as a 97-byte array using the serialization secnonce = bytes(32, k1) || bytes(32, k2) || pk. The same format is used in the reference implementation and in the test vectors. However, since the secnonce is (obviously) not meant to be sent over the wire, compatibility between implementations is not a concern, and this method of storing the secnonce is merely a suggestion.

Internal memory representation of secnonce has 132 bytes:

4 bytes: magic 0x22, 0x0e, 0xdc, 0xf1
32 bytes: k1
32 bytes: k2
64 bytes: group element of pk (is it curve coordinates?)

And this is how libsecp256k1 converts the 97-byte values from tests into 132-byte secnonce: loads public key in musig_test_set_secnonce and prepends magic in secp256k1_musig_secnonce_save.

Kixunil · 2025-03-19T10:09:02Z

We should just generate them from session. We don't have to use every single test vector since upstream already uses them.

stevenroose · 2025-04-09T02:31:41Z

How about doing a rc for the release containing this? I suspect there are quite some teams already using some flavor of this code in some ways (I am in two different ways on sanket's old branch and on this new branch), so maybe when they move over they can provide feedback while they might not have time to review.

stevenroose · 2025-04-09T02:38:36Z

I can already comment about the SecretNonce that the previous iteration that had the serialization functions marked "dangerous" were useful. We have to store a signing session in our database so we have to serialize the nonce and deserialize it later so we can finish the session.

This can be secure because all the other parameters of the session are already known at that time. Why don't we finish the session and store the signtature? Because we have potentially hundreds of thousands of them at the same time and might not have to use any of the signatures, so storing everything at least an order of magnitude faster than signing :)

jlest01 · 2025-04-09T20:36:24Z

@stevenroose I believe you are referring to the function below

impl SecretNonce {
    // ...
    pub fn dangerous_into_bytes(self) -> [c_uchar; MUSIG_SECNONCE_LEN] {
        self.0
    }
}

If I recall, it was removed due to a review.
It can be reintroduced if necessary.

@jirijakes Does this also suit your case?

jirijakes · 2025-04-10T08:10:32Z

Does this also suit your case?

I did not have a particular case in mind. My idea was that it might be needed to create secret nonces from raw bytes (and apparently also the other way), however I do not have a specific need myself.

apoelstra · 2025-04-17T13:25:11Z

Yeah, we should retain the methods (though they still should be marked dangerous!). I asked on IRC if there's a better way to do what Steven is suggesting and the designers of MuSig basically said "no, but this is exactly what we tell people not to do and it's dangerous".

So there isn't really an alternative -- and even if we take away a byte-conversion method there are other ways to get the bytes (e.g. by transmuting). I think as long as both sides of the conversion are clearly marked dangerous the methods should exist in the API.

michael1011 · 2025-04-17T13:51:41Z

I think as long as both sides of the conversion are clearly marked dangerous the methods should exist in the API.

Agreed. Can be very useful and not having those methods makes the life of the library user unnecessarily hard

Kixunil · 2025-04-19T16:35:47Z

This can be secure because all the other parameters of the session are already known at that time.

As I understand it, this is not true. There are attacks involving reentrancy where the attacker sends multiple different nonces. If you want to make it secure, you need to store it in a separate database that is never backed up, is locked such that only a single piece of code/thread can operate on a secret and makes sure to wipe it from DB once it's consumed.

I think the method is not strictly required - one can already store the session and, if the same inputs are provided, same secret should get generated from it. But it is arguably more annoying and I'm not opposed to having the dangerous_ method as long as the danger is correctly explained in detail.

Side note: I have a different case where it'd be nice to have a bunch of nonces generated deterministically from a seed which gets handled the way I describe above. Having a constructor for that would be likely helpful but I don't remember all the details to be certain that I don't need the session anyway. Makes me wonder if such approach would be useful to you too @stevenroose

apoelstra · 2025-04-21T21:25:56Z

I think what @stevenroose is doing is a fair bit less dangerous than what you're describing -- in his use case all the nonces have already been determined. Everything has been done except computation of the final signature; all the inputs have been determined and the signature is also determined. He's just deferring the heavy computation until he's sure that he's necessary.

What you want to do (precomputing nonces) is much harder, for all the reasons you list.

Kixunil reviewed Jul 29, 2024

View reviewed changes

jlest01 force-pushed the musig2-module branch 6 times, most recently from 447a94c to e730b8b Compare July 31, 2024 18:20

jlest01 mentioned this pull request Aug 11, 2024

[WIP] Add a Musig2 example file rust-bitcoin/rust-bitcoin#3158

Open

jlest01 force-pushed the musig2-module branch 3 times, most recently from a91d293 to 8bbd0d2 Compare August 29, 2024 11:39

jlest01 force-pushed the musig2-module branch from 8bbd0d2 to c313387 Compare August 30, 2024 01:40

jlest01 force-pushed the musig2-module branch 3 times, most recently from 0a2361b to 86e2b28 Compare August 30, 2024 22:13

Kixunil reviewed Aug 31, 2024

View reviewed changes

jlest01 force-pushed the musig2-module branch from 86e2b28 to 071ac15 Compare September 17, 2024 02:01

Ademan mentioned this pull request Oct 7, 2024

Musig2 support BlockstreamResearch/rust-secp256k1-zkp#48

Closed

ekrembal mentioned this pull request Oct 14, 2024

Use musig2 from libsecp256k1 chainwayxyz/clementine#339

Closed

jlest01 force-pushed the musig2-module branch from 071ac15 to 7f76102 Compare November 7, 2024 16:55

jlest01 force-pushed the musig2-module branch 2 times, most recently from 5198d9a to 97fb6d1 Compare January 26, 2025 20:05

apoelstra mentioned this pull request Jan 27, 2025

Investigate use of bindgen for producing bindings #775

Open

philipr-za reviewed Jan 28, 2025

View reviewed changes

jlest01 force-pushed the musig2-module branch from 97fb6d1 to ae8597c Compare January 29, 2025 20:43

Ademan mentioned this pull request Mar 6, 2025

Add Musig2 PSBT fields rust-bitcoin/rust-bitcoin#4207

Open

danielgranhao mentioned this pull request Mar 7, 2025

Support wasm SatoshiPortal/boltz-rust#91

Merged

2 tasks

luckysori mentioned this pull request Mar 13, 2025

Temporarily vendor rust-secp256k1-zkp crate ArkLabsHQ/ark-rs#37

Closed

jirijakes reviewed Mar 18, 2025

View reviewed changes

jirijakes suggested changes Mar 18, 2025

View reviewed changes

jirijakes reviewed Mar 19, 2025

View reviewed changes

stevenroose mentioned this pull request Mar 21, 2025

WIP: Add musig support stevenroose/hal#57

Open

jlest01 added 4 commits April 8, 2025 17:31

Add Rust FFI for Musig2 module

ad15839

Add function to sort public keys

732933d

Add Musig2 module

52a1eaf

Add Musig2 example file

b5558c5

jlest01 force-pushed the musig2-module branch from ae8597c to b5558c5 Compare April 8, 2025 20:31

apoelstra mentioned this pull request Apr 16, 2025

Update rand dependency #789

Closed

		pub fn serialize(&self) -> [u8; 32] {
		let mut data = MaybeUninit::<[u8; 32]>::uninit();

	pub const MUSIG_PART_SIG_LEN: usize = 36;
	pub const MUSIG_PART_SIG_LEN: usize = 36;
	pub const MUSIG_PART_SIG_SERIALIZED_LEN: usize = 32;

	pub fn from_byte_array(data: &[u8; ffi::MUSIG_PART_SIG_LEN]) -> Result<Self, ParseError> {
	pub fn from_byte_array(data: &[u8; ffi::MUSIG_PART_SIG_SERIALIZED_LEN]) -> Result<Self, ParseError> {

Add Musig2 module #716

Are you sure you want to change the base?

Add Musig2 module #716

Conversation

jlest01 commented Jul 29, 2024

Kixunil left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tcharding commented Aug 29, 2024

apoelstra commented Aug 29, 2024

jlest01 commented Aug 29, 2024

tcharding commented Aug 29, 2024

Kixunil commented Aug 30, 2024

jlest01 commented Aug 31, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sanket1729 commented Nov 6, 2024

apoelstra commented Nov 6, 2024

jlest01 commented Nov 7, 2024

tcharding commented Nov 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevenroose commented Mar 5, 2025

Kixunil commented Mar 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jirijakes left a comment

Choose a reason for hiding this comment

jirijakes Mar 18, 2025 • edited Loading

Choose a reason for hiding this comment

jirijakes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jirijakes commented Mar 19, 2025 • edited Loading

Kixunil commented Mar 19, 2025

stevenroose commented Apr 9, 2025

stevenroose commented Apr 9, 2025

jlest01 commented Apr 9, 2025

jirijakes commented Apr 10, 2025

apoelstra commented Apr 17, 2025

michael1011 commented Apr 17, 2025

Kixunil commented Apr 19, 2025

apoelstra commented Apr 21, 2025

tcharding commented Nov 11, 2024 •

edited

Loading

jirijakes Mar 18, 2025 •

edited

Loading

jirijakes commented Mar 19, 2025 •

edited

Loading