btcd

blockchain: tolerate trailing bytes when loading stored blocks

In this commit, we relax the strict block deserialization introduced as
part of the trailing byte hardening. Databases written by older
versions of btcd may have persisted blocks with trailing bytes, so
refusing to load them would prevent a node from ever starting (or
serving such a block) after an upgrade, with no recovery path short of
a full resync.

We instead introduce a new dbBlockFromBytes helper, used by both
initChainState and dbFetchBlockByNode, that deserializes the block
leniently: any trailing bytes are logged, ignored, and excluded from
the serialization cached on the returned block, so downstream consumers
of the raw bytes never observe them.

rpcclient: add typed SubmitPackage method

Add SubmitPackage / SubmitPackageAsync / FutureSubmitPackageResult,
wrapping the submitpackage RPC the same way TestMempoolAccept wraps
testmempoolaccept: serialize the topologically-sorted package to hex,
issue the btcjson submitpackage command, and decode the response into
btcjson.SubmitPackageResult (which already maps the raw fields to
higher-level types via its UnmarshalJSON).

This keeps the multi-backend RPC layering intact so callers (e.g.
btcwallet's chain.Interface) can invoke a typed method instead of a
RawRequest. submitpackage is a Bitcoin Core RPC (v24+); btcd has no
server handler for it.

rpctest: scope shared state to the current process

Two pieces of rpctest's global state silently aliased across concurrent
test processes (which is what `go test ./...` does by default, so any
`make unit` that exercises -tags=rpctest hit this):

- btcdExecutablePath compiled to a fixed path /tmp/btcd/rpctest/btcd.
Two `go build` invocations would race on the same file, occasionally
yielding a truncated or stale binary and downstream "tls: certificate
signed by unknown authority" failures when the harness tried to talk
to the resulting node.

- lastPort started at the same defaultNodePort in every process. The
bind-test in NextAvailablePort closes the listener before returning,
so two processes climbing from the same base would frequently hand
out the same port and one harness would die with "connection refused"
when btcd failed to bind.

Suffix the executable with a random uint32 and seed lastPort with a
random offset into a 50k-port window so each process climbs through
its own range.

server: fix linter issue

txscript: turn into own module, use v2

wire: make own module, use v2

address: move to top-level module, use v2

multi: appease go 1.26 vet for non-const format + goroutine Fatalf

In this commit, we fix two go vet errors that go 1.26 now treats as
hard failures during test compilation.

In btcjson/help.go, the final result row of a complex help description
was emitted via fmt.Fprintf with a non-constant format string (the
result text could contain '%' chars). Switch to fmt.Fprint, since
there are no format args here anyway.

In btcec/schnorr/musig2/musig2_test.go, the nonce-registration loop
ran inside a goroutine and called t.Fatalf on failure. Fatalf only
exits the calling goroutine, so the test goroutine would keep running
with stale state. Use t.Errorf + return so the failure is recorded
correctly and the goroutine exits cleanly.

multi: bump Go toolchain to 1.25, build CI with 1.26.3

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).

btcutil: export interfaceAddr

server: guard OnVerAck with sync.Once

The prior select/default+close() guard on verAckCh is correct only
under the invariant that OnVerAck is invoked from a single goroutine
(peer.processRemoteVerAckMsg on the input handler). The two steps
are not atomic: any future change that invokes listeners off the
input goroutine would let two concurrent callers both observe
default and panic on double-close.

Replace the guard with sync.Once. This makes the close-once
contract obviously correct rather than correct-by-distant-invariant
and drops the dead "called more than once" log path.

make fmt

server, integration: add unit regression tests for peer lifecycle fix

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

Add three direct unit tests in server_test.go that exercise the fix
without the full server or rpctest harness:

- TestOnVerAckDoubleCall: call OnVerAck twice on the same serverPeer,
assert no panic and verAckCh remains closed.
- TestPeerLifecycleOrdering: verack before disconnect emits peerAdd
then peerDone in order.
- TestPeerLifecycleSimultaneousReady: both verAckCh and Peer.Done()
ready before the handler runs; assert peerDone always arrives and
peerAdd, if emitted, precedes it (100 iterations).

Harden integration tests in sync_race_test.go:

- Check fakePeerConn errors via require.NoError instead of discarding.
- Extract dialAndSendVersion helper for TestPreVerackDisconnect;
check all errors instead of silently continuing.
- Fix comment wording ("produces" -> "is expected to produce").

wire: separate protocol message limit from serialization bound

Revert MaxMessagePayload to 32MB and introduce MaxProtocolMessageLength
(~4MB) for p2p network message size enforcement. This mirrors Bitcoin
Core's separation between MAX_SIZE (32MB serialization bound) and
MAX_PROTOCOL_MESSAGE_LENGTH (~4MB network limit) introduced in
bitcoin/bitcoin#5843.

The previous commit reduced MaxMessagePayload to 4MB, but that constant
is also used as a serialization bound for deriving maxTxInPerMessage,
maxTxOutPerMessage, and variable-length string limits in contexts beyond
network messages (e.g. database deserialization via MsgTx.Deserialize).
While consensus limits keep real values well below the 4MB-derived
bounds, conflating the two constants is architecturally incorrect and
diverges from Bitcoin Core's design.

The new MaxProtocolMessageLength is now enforced in all four network
read/write paths: WriteMessageN, WriteMessageWithEncodingN,
ReadMessageWithEncodingN, and ReadV2MessageN (which previously had no
overall message size check).

peer: add panic recovery to message handling goroutines

Add a recoverFromPanic method that catches panics in peer goroutines,
logs the error with a stack trace, and disconnects the offending peer
instead of crashing the entire node. This provides defense-in-depth
against future unknown panics in message parsing or handling.

Protect two goroutine boundaries:
- The negotiation goroutine in start(), which handles pre-handshake
message decoding via BtcDecode.
- The inHandler goroutine, which processes all post-handshake messages.

Refactor inHandler cleanup from manual end-of-function calls to
defer-based cleanup, ensuring close(p.inQuit) always runs even on
panic, which prevents stallHandler from hanging.

netsync: require peer argument in fetchHeaderBlocks

Refactor fetchHeaderBlocks and buildBlockRequest to take an explicit
peer parameter instead of implicitly using sm.syncPeer. This makes the
caller responsible for choosing which peer to fetch from and adds a nil
guard to prevent a panic if the sync peer has been cleared.

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".

fix spelling error

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.