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.

Kixunil

Still not deep review, just some problems I noticed when I was digging into the API for other reasons.

Kixunil · 2025-01-26T11:07:04Z

secp256k1-sys/src/lib.rs

+    #[cfg_attr(not(rust_secp_no_symbol_renaming), link_name = "rustsecp256k1_v0_11_ec_pubkey_sort")]
+    pub fn secp256k1_ec_pubkey_sort(
+        ctx: *const Context,
+        pubkeys: *const *const PublicKey,


This signature is invalid. It's supposed to be a mut pointer pointing to a const pointer. IIUC this is unsound.

@apoelstra this is exactly why I advocate for using bindgen. Bugs like this can happen and without it we have to spend time to audit every single function to make sure the signature is correct.

Yeah, ok, we should use bindgen. But (at least initially) I would like to commit the generated code and verify it in CI rather than putting it as part of the build process, to minimize the number of dependencies that downstream users need.

We would also need to figure out what to do about secp256k1-sys/src/types.rs. Will bindgen require some sort of tweaking to use these types? Or will we need a post-processing step? Or maybe we should just bump our MSRV to 1.64 so we don't need this file anymore?

Good catch. Fixed in ff77611

However, it is interesting that Rust does not enforce the const modifier in this case.

But (at least initially) I would like to commit the generated code and verify it in CI rather than putting it as part of the build process, to minimize the number of dependencies that downstream users need.

Yes, but maybe use xtask pattern for that? Rather than committing, we would have a subcrate that generates it and the developers would run it when contributing or publishing the crate (so the code would still be on crates.io). The upside is no CI job needed, the downside is that every contributor has to run the xtask even for unrelated contributions.

Rust does not enforce the const modifier in this case.

The compiler has no way of understanding the C code.

Moved bindgen discussion to #775

Kixunil · 2025-01-26T11:07:46Z

src/key.rs

+/// # pubkey_sort(&secp, pubkeys_ref);
+/// # }
+/// ```
+pub fn pubkey_sort<C: Verification>(secp: &Secp256k1<C>, pubkeys: &[&PublicKey]) {


This is definitely unsound. The function is mutating the argument but it's not using mut.

Fixed in 2755c15

Kixunil · 2025-01-26T11:13:12Z

src/musig.rs

+
+/// Musig tweaking related errors.
+#[derive(Debug, Clone, Copy, Eq, PartialEq, PartialOrd, Ord, Hash)]
+pub enum MusigTweakErr {


Given this has only one variant, either it should be a struct or it should have #[non_exhaustive] if we anticipate new errors in the future (personally I don't believe we have a reason to think there will be new ones).

Done in 404a93b

Kixunil · 2025-01-26T11:15:07Z

src/musig.rs

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


To deserialize(...) ?

Now I saw it in the comment above.
Updated to from_byte_array() in 3e9d296

Kixunil · 2025-01-26T11:19:08Z

src/musig.rs

+#[allow(missing_copy_implementations)]
+#[derive(Debug)]
+pub struct SecretNonce {
+    data: ffi::MusigSecNonce


Damn, I was unclear. I only meant to have named fields in structs that have more than one field. This could've been tuple struct. You don't have to change it back if you don't want to but you can if you wish.

No problem. Reverted to the tuple struct those with only one field in 5cf37bd.

Kixunil · 2025-01-26T11:21:27Z

src/musig.rs

+/// A Musig partial signature.
+#[derive(Copy, Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
+#[repr(transparent)]
+pub struct PartialSignature{ 


Missing space.

Updated in 5cf37bd

Kixunil · 2025-01-26T11:54:24Z

src/musig.rs

+}
+
+impl AggregatedSignature {
+    /// Returns the aggregated signature [`schnorr::Signature`] assuming it is valid.


Thanks for doing this! I'd like the doc toe be more in-depth.

/// Returns the aggregated signature [`schnorr::Signature`] assuming it is valid. /// /// The `partial_sig_agg` function cannot guarantee that the produced signature is valid because participants /// may send invalid signatures. In some applications this doesn't matter because the invalid message is simply /// dropped with no consequences. These can simply call this function to obtain the resulting signature. However /// in applications that require having valid signatures before continuing (e.g. presigned transactions in Bitcoin Lightning Network) this would be exploitable. Such applications MUST verify the resulting signature using the /// [`verify`](Self::verify) method. /// /// Note that while an alternative approach of verifying partial signatures is valid, verifying the aggregated /// signature is more performant. Thus it should be generally better to verify the signature using this function first /// and fall back to detection of violators if it fails.

Thanks for this. Updated in 982e877.

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.

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.

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 7 times, most recently from 690b72f to 2d8b4a3 Compare January 26, 2025 02:48

Kixunil requested changes Jan 26, 2025

View reviewed changes

Kixunil reviewed Jan 26, 2025

View reviewed changes

jlest01 force-pushed the musig2-module branch from 2d8b4a3 to 1fec645 Compare January 26, 2025 19:19

Add Rust FFI for Musig2 module

ff77611

jlest01 force-pushed the musig2-module branch from 1fec645 to d8b07df Compare January 26, 2025 19:43

Add function to sort public keys

a42b6b2

jlest01 force-pushed the musig2-module branch 3 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 added 2 commits January 29, 2025 17:43

Add Musig2 module

4012ed5

Add Musig2 example file

ae8597c

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

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

		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

Kixunil 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

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

Kixunil Jan 26, 2025 • edited Loading

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

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

jirijakes commented Mar 19, 2025 • edited Loading

Kixunil commented Mar 19, 2025

tcharding commented Nov 11, 2024 •

edited

Loading

Kixunil Jan 26, 2025 •

edited

Loading

jirijakes Mar 18, 2025 •

edited

Loading

jirijakes commented Mar 19, 2025 •

edited

Loading