Previously the early nonce generation option was not being respected
when creating the context, with the WithKnownSigners option being
used. This commit fixes that.
The doc formatting changes introduced in the recent go version is
increasing the diff for all of the new commits. Formatting it all in
this commit will help the readability of future PRs by reducing the
diff.
In this commit, we fix the `BenchmarkPartialVerify` test. When we moved
to musig 1.0, we stopped requiring the input as an x-only key. So we
need to remove the round trip serialization to force the key to be
x-only.
This is a fix similar to https://github.com/btcsuite/btcd/pull/1905.
We'll always make a copy of the key in the local scope before passing it
around elsewhere. Depending on the parity of the public key, the private
key itself might need to be negated.
A similar test is added here that fails without the patch to the
signature.go file.
This commit adds a check that the public key of the private key
that is passed to the Sign function is included in the slice of public
keys.
Reference ea47d52e2d
The two _concrete_ changes between version 0.4.0 (where we are before
this commit), and version 0.7.0 are:
1. Variable length messages are now allowed, this comes with a new 8
byte prefix for the messages.
* Our implementation was already using a `[]byte` for the
message/hash, so no extra API changes are needed here.
2. The serialization for a blank message and a normal message (for
nonce gen) is now distinct. A single byte is added (either 0 or 1)
to indicate if a message was passed into nonce generation.
In this commit, we enable early nonce generation, allowing callers to
obtain generated nonces before the total set of signers is actually
known. This type of nonce generation is useful for contexts like LN
funding when we want to minimize the round trips and send nonces before
we know the pubkey of the other party.
In this commit, we update the nonce generation to support optional
parameters defined in the latest BIP draft. These parameters are
optional, but if specified my mitigate the effect of weak randomness
when generating the nonce.
Given the protocol doesn't require signers to prove how they generate
their nonces, this update is mainly to ensure strict spec compliance,
and is effectively optional.
In this commit, we add a series of new functional optinos to make
signing for an aggregated key where the final taproot output key was
derived using BIP 86. This can be used in cases where no script path
shuold be allowed, and only an n-of-n multi-sig should be used.
In this commit, we add a series of new options and methods to make it
easier to use the package in the context of a taproot output that
commits to a script root or some other value. Before this series of
changes, the API was hard to use in this context as the taproot tweak
actually includes the internal public key, which in this case is the
aggregated public key. So you actually needed to call that API w/o the
tweak, get that, then recompute the tweak itself.
To make things easier in the taproot context, we've added a series of
new options that'll return the aggregated key before any tweaks (to be
used as the internal key), and also handle computing the BIP 341 tweak
value for the caller.
In this commit, we add support for signing with tweaked aggregated keys.
Such signing is required when signing for a taproot output key that
actually commits to a script tree root, or was generated using BIP 86.
A series of new functional arguments (that can likely be de-dup'd using
Go's new type params), have been added to allow callers to optionally
flip on this new behavior.
In this commit, we introduce an easier to use API for musig2 signing in
the Session and Context structs.
The Context struct represents a particular musig2 signing context which
is defined by the set of signers. The struct can be serialized to disk
as it contains no volatile information. A given context can be kept for
each signer in the final set.
The Session struct represents an ephemeral musig2 signing session. It
handles nonce generation, key aggregation, nonce combination, signature
combination, and final sig verification all in one API. The API also
protects against nonce generation by not exposing nonces to the end user
and also attempting to catch nonce re-use (assuming no process forking)
across sessions.
