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.
In this commit, we create a series of new interfaces that'll allow us to
abstract "when" exactly a deployment starts and ends. As is, all
deployments start/end based on a unix timestamp, which is compared
against the MTP of a given block to determine if a new deployment has
started or ended. This works fine for BIP 9 which uses time based
timeouts, but not so much for BIP 8. In order to prep a future refactor
that allows our version bits implementation to support both time and
block based start/end times, this new abstraction has been introduced.
Now that the new `btcutil/v1.0.0` tag has been pushed, we update the new
internal modules to point to the top-level `btcd` repo via replace
directives.
In this commit, we adapt the Makefile that was being used for the
btcutil project to work for btcd as well. The Makefile is pretty simple,
and is just a series of templated commands. Overtime, we can pull in
some of the `lnd` additions as well, which we use to handle our
reproducible build and verification system.
