In this commit, we add a new signatureVerifier interface that will allow
us to consolidate a lot of code as we'll now have 4 distinct sig+sighash
types to verify:
1. pre-segwit
2. segwit v0
3. segwit v1 (taproot key spend)
4. tapscript spends
We'll need to be able to handle 3 of the cases for the modified
OP_CHECKSIG operator. This new abstraction allows us to keep the
implementation of the function somewhat succinct.
In this commit we implement a verifier for #3 which is needed to verify
the top-level taproot keyspend. We expose the verifier using a new
VerifyTaprootKeySpend function.
In this commit, we make the sigCache slightly more general in order to
be able to cache both ECDSA and Schnorr signatures. The cache is now
based off of byte slices (the values) rather than the direct objects. We
rely on the fact that the sighash for ecdsa and the schnorr types are
distinct, so we can keep using the same top-level sighash key.
In the future with Go type params, we can use a type param here instead
as they all have an `IsEqual` method.
In this commit, we implement the new BIP 341+342 taproot sighash digest
computation. The digest is similar, but re-orders some fragments and
also starts to commit to the input values of all the transactions in the
SIGHASH_ALL case. A new implicit sighash flag, SIGHASH_DEFAULT has been
added that allows signatures to always be 64-bytes for the common case.
The hashcache has been updated as well to store both the v0 and v1 mid
state hashes. The v0 hashes are a double-sha of the contents, while the
v1 hash is a single sha. As a result, if a transaction spends both v0
and v1 inputs, then we 're able to re-use all the intermediate hashes.
As the sighash computation needs the input values and scripts, we create
an abstraction: the PrevOutFetcher to give the caller flexibility w.r.t
how this is done. We also create a `CannedPrevOutputFetcher` that holds
the information in a map for a single input.
A series of function options are also added to allow re-use of the same
base sig hash calculation for both BIP 341 and 342.
With PR #1785 multiple coverage reports are sent to coveralls. This
makes coveralls only consider the last report sent. This fix treat all
reports has parallel reports so they can all be compiled later by coveralls.
Fixes a negative index bug that makes the node crash on chain
reorganizations. The bug is detailed in
github.com/btcsuite/btcd/issues/1660.
A better design than just skipping the transaction would make
the fee estimator more accurate and that should implemented
at a later date.
This was the version tagged that created the new `ecdsa` and `schnorr`
packages. Updating these pinned version lets importers properly use
these packages and build. Things build as is since we use replace
directive to point to the latest version _in the repo_ when we build.
In this commit, we optimize our signature implementation slightly, by
defining pre-computed sha256(tag) variables for the commonly used
values. If a tag matches this, then we'll use that hash value to avoid
an extra round of hashing.
In this commit, we add an initial implementation of BIP-340. Mirroring
the recently added `ecsda` package, we create a new `schnorr` package
with a unique `Signature` type and `ParsePubkey` function. The new
`Signature` type implements the fixed-sized 64-byte signatures, and the
`ParsePubkey` method only accepts pubkeys that are 32-bytes in length,
with an implicit sign byte.
The signing implementation by default, deviates from BIP-340 as it opts
to use rfc6979 deterministic signatures by default, which means callers
don't need to always pass in their own `auxNonce` randomness. A set of
functional arguments allows callers to pass in their own value, which is
the way all the included test vectors function.
The other optional functional argument added is the `FastSign` option
that allows callers to skip the final step of verifying each signature
they generate.
In this commit, we add an implementation of the BIP-340 tagged hash
scheme. This initial version can be optimized quite a bit, for example,
we can hard code the output of frequently used `sha256(tag)` values and
save two `sha256` invocations.
In this commit, we create a new package to house the ECDSA-specific
logic in the new `btcec/v2` pacakge. Thsi c hange is meant to mirror the
structure of the `dcrec` package, as we'll soon slot in our own custom
BIP-340 implementation.
The `goveralls` tool we use to handle code coverage upload seems to not
understand that a `v2 module can exist, without having a v2 file path on
disk. We use a `sed` command to remove the `v2` module prefix so the
tool can reach into the correct file to extract the source code.
In this commit, we turn the package into a new Go module (version 2),
and then port over the current set of types and functions to mainly
alias to the more optimized and maintained dcrec variant.
Taking a look at the benchmarks, most operations other than
normalization (which IIRC is a bit slower now due to constant time
fixes) enjoy some nice speeds up:
```
benchcmp is deprecated in favor of benchstat: https://pkg.go.dev/golang.org/x/perf/cmd/benchstat
benchmark old ns/op new ns/op delta
BenchmarkAddJacobian-8 464 328 -29.20%
BenchmarkAddJacobianNotZOne-8 1138 372 -67.27%
BenchmarkScalarBaseMult-8 47336 31531 -33.39%
BenchmarkScalarBaseMultLarge-8 42465 32057 -24.51%
BenchmarkScalarMult-8 123355 117579 -4.68%
BenchmarkNAF-8 582 168 -71.12%
BenchmarkSigVerify-8 175414 120794 -31.14%
BenchmarkFieldNormalize-8 23.8 24.4 +2.39%
BenchmarkParseCompressedPubKey-8 24282 10907 -55.08%
```
In this commit, we extract the BIP 9 state transition logic from the
thresholdState method into a new thresholdStateTransition function that
allows us to test all the defined state transitions, including the
modified "speedy trial" logic.
In this commit, we extend the existing version bits state machine to add
support for the new minimum activation height and custom block threshold
for activation. We then extend the existing BIP 9 tests (tho this isn't
really BIP 9 anymore...) to exercise the new min activation height
logic.
In this commit, we add a new "dummy" deployment that adds the new params
used to activate taproot. We chose to add a new deployment as unlike the
bitcoind codebase, we don't currently "bury" soft forks that have
happened in the past (hard code an activation height).
The old taproot deployment has been removed as with the way the array
works, a deployment needs to be defined for _all_ networks.
In this commit, we update our version bits logic to use the newly added
HasStarted and HasEnded methods for consensus deployments. Along the
way, wee modify the thresholdConditionChecker` interface to be based off
the new chaincfg interfaces. In addition, we add a new method
`PastMedianTime`, in order to allow the chain itself to be used as a
`chaincfg.BlockClock`.
This serves to make the logic more generic in order to support both
block height and time based soft fork timeouts.
In this commit, we utilize the recently added ConsensusDeploymentStarter
and ConsensusDeploymentEnder interfaces. Concrete implementations of
this interface based on the median time past comparison are used now in
the ConsensusDeployment struct instead of hard coded start/end times.
Along the way, we had to switch to using the "zero time": time.Time{},
in place of 0 and math.MaxInt64 as comparison (After/Before) seems to be
broken in the Go stdlib for times very far in the future. It appears Go
isn't ready to handle the heat death of the universe.
