b43dd83b43eac0ca8ad9ee1f557e9126c9e08d9e musig: add missing static keyword to function (Jonas Nick)
068e6a036a953e48bc90f9a96b318e350f474a3a musig: add test vectors from BIP MuSig (Jonas Nick)
36621d13bedf44eeedd2a1773e30e849972e5bff musig: update to BIP v1.0.0-rc.2 "Add ''pk'' arg to ''NonceGen''" (Jonas Nick)
d717a4980bc3e2e36bd32a02466226ef49a5d625 musig: update to BIP v0.8 "Switch from X-only to plain pk inputs." (Jonas Nick)
304f1bc96d6bdb5c1b5b1b9a321eac8f9a27fde4 extrakeys: add pubkey_sort test vectors from BIP MuSig2 (Jonas Nick)
ae89051547435cab5042a13d85562def9cabdd61 extrakeys: replace xonly_sort with pubkey_sort (Jonas Nick)
98242fcdd9519d0d5a349b0344aeea0ab4e796e9 extrakeys: add secp256k1_pubkey_cmp (Jonas Nick)
73d5b6654d472eb0cebbffd5a934caf174d29307 musig: update to BIP v0.7.0 (NonceGen) (Jonas Nick)
060887e9d749062242b4de3935b27fdcb0802c87 musig: update to BIP v0.5.1 "Rename ordinary tweaking to plain" (Jonas Nick)
cbe2815633411479e8305deb8b69bce94df723af musig: update to BIP v0.4 "Allow the output of NonceAgg to be inf" (Jonas Nick)
206017d67d9bb8b21d5cc924ba53e1618274774c musig: update to BIP v0.3 (NonceGen) (Jonas Nick)
d800dd55db28a710bb510a2a5fc33519d355a91c musig: remove test vectors (Jonas Nick)
Pull request description:
Version 1.0.0-rc.3 of BIP MuSig2 can be found [here](https://github.com/jonasnick/bips/pull/75). This PR does _not_ implement the following optional features that have been added to BIP MuSig2:
- variable length messages
- deterministic signing
- identifiable aborts
The PR also does _not_ yet change the `secnonce` structure to also contain the signer's public key (which would also imply changing the seckey argument in `sign` to a keypair). Additionally, we may want to rename some things in the future to be more consistent with the BIP (e.g. keyagg_cache vs. keyagg_ctx, applytweak vs. tweak_add).
ACKs for top commit:
ariard:
Light Code Review ACK b43dd83b, mostly looks on how the user API will make sense for Lightning, thanks for the answers!
real-or-random:
ACK b43dd83b43eac0ca8ad9ee1f557e9126c9e08d9e
Tree-SHA512: 9b1410951b55a1b0e6590b8c302052996d1fb6d9771765498b4282ff68b44ab0d6add8144c9330217b682ec5a93508b5546099db9a1f2c865f99253010dd76f4
Provides a method that will give an upper bound on the size of a rangeproof,
given an upper bound on the value to be passed in and an upper bound on the
min_bits parameter.
There is a lot of design freedom here since the actual size of the rangeproof
depends on every parameter passed to rangeproof_sign, including the value to
be proven, often in quite intricate ways. For the sake of simplicity we assume
a nonzero `min_value` and that `exp` will be 0 (the default, and size-maximizing,
choice), and provide an exact value for a proof of the given value and min_bits.
_tagged_sha256 simply cannot have invalid inputs.
The other functions could in some sense have invalid inputs but only in
violation of the type system. For example, a pubkey could be invalid but
invalid objects of type secp256k1_pubkey either can't be obtained
via the API or will be caught by an ARG_CHECK when calling pubkey_load.
This is consistent with similar functions in the public API, e.g.,
_ec_pubkey_negate or _ec_pubkey_serialize.
8088eddc534cbbb89dd5f892828c4013416c4f2b musig: add test vector for ordinary (non xonly) tweaking (Elliott Jin)
57a17929fc0056efb5436a6001597d656591e1ad musig: add ordinary and xonly tweaking to the example (Jonas Nick)
37107361a0ff3b8764903e3b384cfc12ed484e7a musig: allow ordinary, non-xonly tweaking (Jonas Nick)
c519b468791670654f8b66368a675655cd337ae8 musig: add pubkey_get to obtain a full pubkey from a keyagg_cache (Jonas Nick)
Pull request description:
In short, `musig_pubkey_tweak_add` now allows for xonly _and_ "ordinary" tweaking. Also, in order to allow using `ec_pubkey_tweak_add` on the non-xonly aggregate public key, there's a new function `musig_pubkey_get` that allows obtaining it from the `keyagg_cache`.
One alternative would be that instead of adding `musig_pubkey_get`, we could change `pubkey_agg` to output an ordinary (non-xonly) pubkey. Then users of the API who do not need ordinary (BIP32) tweaking would be forced to call `xonly_pubkey_from_pubkey`. And we'd probably want to change the spec. And it would be a bit weird to output a pubkey that can't be directly schnorrsig_verify'd.
Based on #131
ACKs for top commit:
robot-dreams:
ACK 8088eddc534cbbb89dd5f892828c4013416c4f2b based on https://github.com/ElementsProject/secp256k1-zkp/pull/151#issuecomment-1005198409 and the following `range-diff`:
Tree-SHA512: a4a0100f0470c870f88a8da27dbcc4684fcc2caabb368d4340e962e08d5ee04634e6289bafa3448dbfd0b5793a3e70de5bd6ddca7a619cc3220ff762d518a8fe
ac1e36769dda3964f7294319ecb06fb5c414938d musig: turn off multiexponentiation for now (Jonas Nick)
3c79d97bd92ec22cc204ff5a08c9b0e5adda12e6 ci: increase timeout for macOS tasks (Jonas Nick)
22c88815c76e6edb23baf9401f820e1a944c3ecf musig: replace MuSig(1) with MuSig2 (Jonas Nick)
Pull request description:
The main commit comprises `905 insertions(+), 1253 deletions(-)`. The diff isn't as small as I had hoped, but that's mostly because it was possible to simplify the API quite substantially which required rewriting large parts. Sorry, almost all of the changes are in one big commit which makes the diff very hard to read. Perhaps best to re-review most parts from scratch.
A few key changes:
- Obviously no commitment round. No big session struct and no `verifier` sessions. No `signer` struct.
- There's a new `secnonce` struct that is the output of musig_nonce_gen and derived from a uniformly random session_id32. The derivation can be strengthened by adding whatever session parameters (combined_pk, msg) are available. The nonce function is my ad-hoc construction that allows for these optional inputs. Please have a look at that.
- The secnonce is made invalid after being used in partial_sign.
- Adaptor signatures basically work as before, according to https://github.com/ElementsProject/scriptless-scripts/pull/24 (with the exception that they operate on aggregate instead of partial sigs)
- To avoid making this PR overly complex I did not consider how this implementation interacts with nested-MuSig, sign-to-contract, and antiklepto.
- Testing should be close to complete. There's no reachable line or branch that isn't exercised by the tests.
- [x] ~In the current implementation when a signer sends an invalid nonce (i.e. some garbage that can't be mapped to a group element), it is ignored when combining nonces. Only after receiving the signers partial signature and running `partial_sig_verify` will we notice that the signer misbehaved. The reason for this is that 1) this makes the API simpler and 2) malicious peers don't gain any additional powers because they can always interrupt the protocol by refusing to sign. However, this is up for discussion.~ EDIT: this is not the case anymore since invalid nonces are rejected when they're parsed.
- [x] ~For every partial signature we verify we have to parse the pubnonce (two compressed points), despite having parsed it in `process_nonces` already. This is not great. `process_nonces` could optionally output the array of parsed pubnonces.~ EDIT: fixed by having a dedicated type for nonces.
- [x] ~I left `src/modules/musig/musig.md` unchanged for now. Perhaps we should merge it with the `musig-spec`~ EDIT: musig.md is updated
- [x] partial verification should use multiexp to compute `R1 + b*R2 + c*P`, but this can be done in a separate PR
- [x] renaming wishlist
- pre_session -> keyagg_cache (because there is no session anymore)
- pubkey_combine, nonce_combine, partial_sig_combine -> pubkey_agg, nonce_agg, partial_sig_agg (shorter, matches terminology in musig2)
- musig_session_init -> musig_start (shorter, simpler) or [musig_generate_nonce](https://github.com/ElementsProject/secp256k1-zkp/pull/131#discussion_r654190890) or musig_prepare
- musig_partial_signature to musig_partial_sig (shorter)
- [x] perhaps remove pubnonces and n_pubnonces argument from process_nonces (and then also add a opaque type for the combined nonce?)
- [x] write the `combined_pubkey` into the `pre_session` struct (as suggested [below](https://github.com/ElementsProject/secp256k1-zkp/pull/131#issuecomment-866904975): then 1) session_init and process_nonces don't need a combined_pk argument (and there can't be mix up between tweaked and untweaked keys) and 2) pubkey_tweak doesn't need an input_pubkey and the output_pubkey can be written directly into the pre_session (reducing frustration such as Replace MuSig(1) module with MuSig2 #131 (comment))
- [x] perhaps allow adapting both partial sigs (`partial_sig` struct) and aggregate partial sigs (64 raw bytes) as suggested [below](https://github.com/ElementsProject/secp256k1-zkp/pull/131#issuecomment-867281531).
Based on #120.
ACKs for top commit:
robot-dreams:
ACK ac1e36769dda3964f7294319ecb06fb5c414938d
real-or-random:
ACK ac1e36769dda3964f7294319ecb06fb5c414938d
Tree-SHA512: 916b42811aa5c00649cfb923d2002422c338106a6936a01253ba693015a242f21f7f7b4cce60d5ab5764a129926c6fd6676977c69c9e6e0aedc51b308ac6578d
BIP340's default signing algorithm always requires an aux_rnd argument,
but permits using an all-zero one when no randomness is available.
Make secp256k1_schnorrsig_sign follow this even when aux_rnd32==NULL,
by treating the same as if an all-zero byte array was provided as
input.
adec5a16383f1704d80d7c767b2a65d9221cee08 Add missing null check for ctx and input keys in the public API (Elichai Turkel)
f4edfc758142d6e100ca5d086126bf532b8a7020 Improve consistency for NULL arguments in the public interface (Elichai Turkel)
Pull request description:
I went over the public API and added missing explanations on when a pointer can be null and when it cannot,
and added some missing checks for null ctx and null pubkey pointers.
Open questions IMHO:
1. Can `secp256k1_context_create` return NULL? right now it could return null if you replaced the callbacks at compile time to ones that do return(unlike the default ones which never return).
2. Related to the first, should we document that the callbacks should never return? (in the tests we use returning callbacks but we can violate our own API) right now we say the following:
> After this callback returns, anything may happen, including crashing.
Is this enough to document answer `no` for the first question and just saying that if the callback returned then you violated the API so `secp256k1_context_create` can return NULL even though it is promised not to?
Right now we AFAICT we never check if it returns null
Another nit I'm not sure about is wording `(does nothing if NULL)`/`(ignored if NULL)`/`(can be NULL)`
More missing docs:
1. Documenting the `data` argument to the default nonce functions
ACKs for top commit:
ariard:
ACK adec5a16
jonasnick:
ACK adec5a16383f1704d80d7c767b2a65d9221cee08
Tree-SHA512: 6fe785776b7e451e9e8cae944987f927b1eb2e2d404dfcb1b0ceb0a30bda4ce16469708920269417e5ada09739723a430e270dea1868fe7d12ccd5699dde5976
unsigned char foo[4] = "abcd" is not valid C++ because the string
literal "abcd" does not fit into foo due to the terminating NUL
character. This is valid in C, it will just omit the NUL character.
Fixes#962.
Varlen message support for the default sign function comes from recommending
tagged_sha256. sign_custom on the other hand gets the ability to directly sign
message of any length. This also implies signing and verification support for
the empty message (NULL) with msglen 0.
Tests for variable lengths follow in a later commit.
This makes the default sign function easier to use while allowing more granular
control through sign_custom.
Tests for sign_custom follow in a later commit.
