btcd

server: serialize peer lifecycle via single goroutine

Address review feedback on the peer add/done race fix:

- Make peerLifecycleHandler (renamed from peerDoneHandler) the sole
sender of both peerAdd and peerDone events for each peer. OnVerAck
now closes a signal channel (verAckCh) instead of sending directly,
and peerLifecycleHandler selects on verAckCh vs peer.Done() to
decide whether to send peerAdd before peerDone. This guarantees
ordering by construction: a single goroutine sends both events
sequentially, eliminating the negotiateTimeout race window.

- Add Done() method to peer.Peer exposing the quit channel read-only,
enabling select-based disconnect detection from server code.

- Remove the now-unused AddPeer method.

- Address style feedback: 80-char line limit, empty lines between
switch cases, break long function calls, use require.GreaterOrEqualf
instead of if+Fatalf, bump syncRaceConcurrency to 300 for
backpressure testing, add TestPreVerackDisconnect for disconnect
prior to verack.

server: fix peer add/done race between peerHandler and syncManager

peerDoneHandler ran as a separate goroutine per peer and independently
notified both peerHandler (via donePeers channel) and the sync manager
(via syncManager.DonePeer) about a peer disconnect. Because these two
sends were unsynchronized, the sync manager could observe DonePeer
before NewPeer when a peer connected and disconnected quickly. This
caused the sync manager to log "unknown peer", then later register the
already-dead peer as a sync candidate that was never cleaned up,
potentially leaving it stuck with a dead sync peer.

Two structural changes eliminate the race:

1. Merge the newPeers and donePeers channels into a single
peerLifecycle channel. Since OnVerAck (add) always fires before
WaitForDisconnect returns (done), a single FIFO channel guarantees
peerHandler always processes add before done for a given peer,
removing the select-ambiguity where Go could pick done first.

2. Move the syncManager.DonePeer call and orphan eviction from
peerDoneHandler into handleDonePeerMsg, which runs inside
peerHandler. All sync manager peer lifecycle notifications now
originate from the single peerHandler goroutine and flow into
sm.msgChan in guaranteed add-before-done order.

btcec/schnorr: fix nonce generation comments

The comments in schnorrSign and Sign incorrectly stated that CustomNonce
triggers RFC6979 nonce generation. The actual behavior is the opposite:

- With CustomNonce: BIP-340 compliant nonce derivation (steps 6-8)
- Without CustomNonce (default): RFC6979 deterministic nonce generation

Also fixes typo "set 14" -> "step 14".

build: bump version of Go container for release builds

fix spelling error

regtest: align activations with Bitcoin Core

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.

blockchain: run BIP30 check at BIP0034Height

Sync the behaviour with Bitcoin Core.

See https://github.com/bitcoin/bitcoin/pull/6931

In Core, the BIP30 flag is cleared only if the previous block's ancestor chain
already contains the BIP34 activation block. For the activation block itself
(height = BIP0034Height), pindex->pprev->GetAncestor(BIP34Height) returns
nullptr, so the flag stays on and BIP30 is still enforced. In other words, Core
enforces BIP30 for the activation block and skips it starting with the following
block.

blockchain: make BIP30 enforcement logic testable

Upcoming commits tweak the conditions under which the expensive BIP30
duplicate-coinbase check should run. To unit-test those changes, this
commit moves the decision logic out of BlockChain.checkConnectBlock and
into a dedicated helper, bip0030CheckNeeded. The behaviour is unchanged;
the new helper is covered by tests in bip30_test.go.

blockchain: fix overly eager BIP30 bypass

Bitcoin Core PR https://github.com/bitcoin/bitcoin/pull/12204 tightened BIP30
handling: re-enable the check once height 1,983,702 is reached.

This change ports that logic into btcd and adds a regression test.

blockchain: run BIP30 if we are on non-BIP34 fork

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.

treap, ffldb: change Put() to take in multiple key-value pairs

Previously, the Put() function took in a single key-value pair,
resulting in memory allocation overhead as the intermediary treapNodes
got allocated and immediately garbage collected, resulting in
performance loss due to the garbage collection overhead.

We're able to recycle the intermediary treapNodes allocated by taking in
multiple key-value pairs. This results in better performance of the
node especially during UTXO cache flushes.

treap: add recycle() method on treapNode

The recycle method resets and puts the treapNode into the treapNodePool
to be recycled at a future date.

treap: return newly created treapNodes in put()

The newly created treapNodes in put() are now returned so that the
caller has access to them. This is done so that the caller can put back
some of the treapNodes to sync.Pool.

For multiple put operations, an immutable treap will allocate many
treapNodes that will immediately be garbage collected. Let's say
there's 3 key-value pairs that are going to be inserted:

key 1: 50
key 2: 10
key 3: 4

Then the insertion is like so:

1: allocate 50.

50

2: clone 50, allocate 10.

50
/ \
10

3: clone 50, clone 10, allocate 4

50
/ \
10
/
4

In this example, only the nodes allocated during insertion of (3) is
going to be used. The rest is going to be garbage collected and they
can be safely be put in the sync.Pool if there's a guarantee that the
previous copies are not being accessed. This is true if the put
operations are going to be called in batches.

By returning the pointers of these allocated treapNodes, we allow the
caller to make such optimizations.

rpcclient: ensure http dial respects timeout

Ensure that the dial phase of rpcclient's HTTP posts respects the http.Client's Timeout. It was instead falling back to the OS settings.

build: bump version to v0.25

musig2: add combinedNonce getter

musig2: add Session.RegisterCombinedNonce

This commit adds a new function to musig2.Session, which allows the caller
to add an external aggregated nonce to the session.

build: bump version to v0.25.0-beta.rc1

treap: add treapNodePool and fetch from it for cloneTreapNode and
newTreapNode

The treapNodePool will allow for less memory allocations during
immutable treap operations. We first change the cloneTreapNode and
newTreapNode to allocate a treapNode from the sync.Pool.

The allocated treapNodes will be put back into the sync.Pool in later
commits.

treap: refactor the Put() code into exported and unexported versions

We do this to later add batch put logic into the exported Put()
function.

Makefile+workflows: fallback to `GOPATH/bin` on non-existent `GOBIN`

Co-authored-by: Oliver Gugger <gugger@gmail.com>

Dockerfile: update go base image

rpcclient: add bitcoind version dependent error matching

Fixes #2404.
If different versions of bitcoind return different error strings, we
need a way to match those as well.