In this commit, we strip all of the local `replace ... => ../...`
directives that were introduced as part of #1825 (the v2 module
restructuring), now that proper tags exist for every freshly carved-out
submodule. Every in-tree go.mod is pinned to the newly published tags:
chainhash/v2.0.0, wire/v2.0.0, chaincfg/v2.0.0, address/v2.0.0,
txscript/v2.0.0, btcutil/v2.0.0, psbt/v2.0.0, and btcec is bumped to
v2.5.0 since it now depends on chainhash/v2 (previously
chaincfg/chainhash).
While here, we also unify the Go toolchain to 1.25 across every
submodule so the workspace resolves a consistent set of language
features.
Finally, we bump the main btcd version to v0.26.0-beta.rc1 in
preparation for the upcoming release candidate.
In this commit, we update every in-tree go.mod to declare go 1.25 and
have CI build with 1.26.3 (Dockerfile uses the golang:1.26-alpine base).
Docs that mention the minimum required Go version are aligned with the
new floor as well.
Fixes#2527, which flagged the README.md / go.mod version mismatch (the
README claimed 1.22 while the root + v2transport go.mod files already
required 1.23.2).
Add NewHashFromStrStrict and DecodeStrict for callers that must
parse full txids or block hashes exactly.
Keep NewHashFromStr and Decode lenient for compatibility, but add
NOTE docs steering typical parsing to the strict helpers.
Add tests for the new strict behavior and preserve coverage for the
existing lenient short and odd hex behavior.
Set regtest buried heights to match Core: BIP34/65/66 at height 1 and make
CSV/SegWit/Taproot always active. Added regtest coverage for header version
floors, coinbase height enforcement, and deployment state to ensure we now
reject the blocks Core rejects and accept the ones Core accepts.
Updated package fullblocktests to generate BIP34-compliant blocks.
Test helpers now set prev block height to 0 (not the default -1) so generated
blocks start at height 1 and satisfy coinbase height rules.
Mirror BIP34-aware BIP30 skip logic from Bitcoin Core.
PR https://github.com/bitcoin/bitcoin/pull/6931 in Bitcoin Core introduced
an optimization that skips the expensive BIP30 duplicate coinbase check once
BIP34 is active *and* the chain actually contains the recorded activation block.
See the comment in that PR "//Only continue to enforce if we're below BIP34
activation height or the block hash at that height doesn't correspond."
btcd used to drop the check purely based on height. On a fork that lacks the
BIP34 activation block, that difference lets a duplicate coinbase slip through
consensus. This patch ports the missing pieces: we store the activation hash in
chain parameters and only disable BIP30 after we see that block on-chain.
This commit introduces the concept of `AlwaysActiveHeight` to the
deployment mechanism, allowing a deployment to be forced into the active
state if the next block's height meets or exceeds this threshold.
This is intended primarily to be used alongside the new Testnet4
deployment, as the past major soft forks are meant to be active from the
very first block height.
* chaincfg: remove unresponsive dnsseed on testnet
testnet-seed.bitcoin.schildbach.de is unresponsive and doesn't return
any ips. Bitcoin Core has already removed it and we don't also be
getting rid of it as well.
* chaincfg: add dnsseeds from Sjors Provoost
His seeds work well and we don't have any for signet and it's good to
replace the lost dns seed on testnet.
* chaincfg: remove bad dnsseed (seed.bitcoinstats.com)
seed.bitcoinstats.com doesn't respect filter requests even though it's
advertised as it does. Plus it often returns nodes that are unreachable.
In my testing over the past week, it's been the most unreliable dns seed
and since we have plenty of mainnet seeds, it's better to do away with
this.
I documented my findings for this in a Bitcoin Core issue:
https://github.com/bitcoin/bitcoin/issues/29911
* chaincfg: add dnsseed from wiz
It's the same infrastructure that mempool . space runs on and has been
reliable. The same seed is also included in Bitcoin Core as well.
DoubleHashRaw provides a simple function for doing double hashes. Since
it uses the digest instead of making the caller allocate a byte slice, it
can be more memory efficient vs other double hash functions.
Recent commits 1d6e578 and 72ea23e introduced a change in the way Hashes
are serialized and deserialized. This change could cause errors in
downstream applications that persisted hashes serialized using the previous
methods.
This introduces support for legacy-serialized hashes unmarshaling and restores
the compatibility with previous versions.
This commit emulates the behavior of Bitcoin Core introduced in
https://github.com/bitcoin/bitcoin/pull/6853 that disables retargeting
of the required proof of work for regtest.
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.
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.
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.
In this commit, we add a new function to verify the taproot merkle
commitment of a given tapscript leaf. Along the way we add some helper
functions which can be used to construct a taproot output given the raw
script root.
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.
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 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 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 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.
In this commit, we update all the btcutil imports to point to the new
sub-module.
In the same commit, we also modify the recently added `btcutil/go.mod`
file as we need to continue pointing to the _old_ version of btcd, until
we merge this PR and push a new tag.
On signet all previous soft forks and also taproot are always activated,
meaning the version is always 0x20000000 for all blocks. To make sure
they activate properly in `btcd` we therefore need to use the correct
bit to mask the version.
This means that on any custom signet there would need to be 2016 blocks
mined before SegWit or Taproot can be used.
Currently, the only way to register HD version bytes is by initializing
chaincfg.Params struct, and registering it during package init.
RegisterHDKeyID provides a way to populate custom HD version bytes,
without having to create new chaincfg.Params instances. This is useful
for library packages who want to use non-standard version bytes for
serializing extended keys, such as the ones documented in SLIP-0132.
This function is complementary to HDPrivateKeyToPublicKeyID, which is
used to lookup previously registered key IDs.
This commit adds set of BIP0009 (Version Bits) deployment parameters
for all networks detailing the activation parameters for the segwit
soft-fork.
Additionally, the BIP0009 integration test has been updated to test for
the proper transitioning of version bits state for the segwit soft
fork. Finally, the `getblockchaininfo` test has also been updated to
properly display the state of segwit.
The IsBech32SegwitPrefix method takes a string prefix and
determines if it is a valid prefix for a Bech32 encoded segwit
address for any of the default or registered networks.
