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.
In this commit, we add a final test case that exercises the act of
generating partial signatures amongst 100 signers, combining them into a
single signature, and finally verifying to make sure the final signature
is valid.
In this commit, we build on the prior two commits by adding the ability
to generate partial musig2 signatures, validate them individually, and
finally combine them into a single signature.
Much of the logic here is unoptimized, and will be optimized in a later
commit. In addition, we also want to eventually have a nicer API to
support the book keeping necessary during multi signing.
In this commit, we add the ability to generate the secret+public nonces,
as well as combine a series of nonces into a single combined nonce
(which is used when doing multi signing).
In this commit, we add the set of key aggregation routines for musig2.
This includes the main public key aggregation method, as well as the
aggregation coefficient which is used to compute "mu" when signing.
The logic in this implementation is based on the musig2 paper, as well
as this spec:
https://github.com/ElementsProject/secp256k1-zkp/blob/master/doc/musig-spec.mediawiki.
Adds a GitHub workflow, and custom docker file, using docker buildx
which builds docker container images for common platforms and publishes
these images to GitHub packages.
The existing values were copied over from the testnet deployment, which
uses a much larger miner confirmation window. As a result, the main
taproot deployment would require thousands of blocks to properly
activate in development environments.
Restrict the available set of system calls to the daemon to the basic
network and filesystem operations on OpenBSD. Further reduce potential
harm by limiting file system access to the btcd data dir and the rpc
files.
Update the fields of GetNetworkInfoResult to reflect the current number
of inbound and outbound peer connections.
* ConnectionsIn - The number of inbound peer connections
* ConnectionsOut - The number of outbound peer connections
BIP-0174 defines the derivation path being encoded as
"<32-bit uint> <32-bit uint>*"
with the asterisk meaning 0 to n times. Which in turn means that an
empty path is valid, only the key fingerprint is mandatory.
In this commit, we demote a series of log statements added while
debugging the modified BIP 9 state machine. These are rather spammy on
mainnet, so we demote the transition logs (moving to a new state) to
debug, and the remaining log (when we're still in started to trace).
In this commit, we update the top level module to use the newly tagged
sub-modules. Once we remove the circular dependant in these sub-modules,
then we'll no longer have to do things like this.
In this commit, we add the deployment parameters of taproot as specified
in the deployment section of BIp 341:
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment.
Take note of the custom activation threshold, as well as the specified
min activation heights for mainnet only.
