Sync with Upstream#1
Open
2a5A1Ghu1 wants to merge 1241 commits into
Open
Conversation
Add robust property-based tests for the assertNoTimeWarp function using the rapid testing library. The tests verify the following scenarios: - Basic property tests: - Only retarget blocks (block height divisible by blocksPerRetarget) are checked - Valid timestamps (within maxTimeWarp of previous block) pass validation - Invalid timestamps (too early) fail with appropriate ErrTimewarpAttack - Correct boundary behavior (exactly at maxTimeWarp limit) - Invariant tests: - Function never panics with valid inputs - Non-retarget blocks always return nil regardless of timestamps - Security tests: - All retarget blocks are protected from timewarp attacks - Non-retarget blocks are not affected by the timewarp check
…tion 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.
multi: implement testnet4 and add support for soft forks that are always active
…ocks-from-same-height-peers netsync: don't ask for blocks from peers on the same block height
Signed-off-by: xinhangzhou <shuangcui@aliyun.com>
multi: deprecation goacc
docs: update contribution link
refactor: use map.Copy for cleaner map handling
psbt: check path minimum length
Currently btcd keeps downloading blocks and fails to verify them if the disk is out of space. We exit immediately if we detect that the disk is out of space to ensure the database is at a recoverable state later on.
…ng-out-of-disk-space database: shut the program down immediately if we run out of disk space
Protect against overflows when parsing malformed Taproot BIP32 derivation fields. This ensures that deserialization fails safely if the declared number of leaf hashes would otherwise cause an integer overflow.
Cap the `value` slice to `MaxPsbtValueLength` to prevent potential out-of-memory conditions during parsing. This ensures that total allocation remains bounded and consistent with other PSBT fields.
The BIP324 ElligatorSwift test vectors are also included.
This package introduces FSChaCha20 and FSChaCha20Poly1305 primitives that are behind the v2 encrypted handshake. Handshake code is also introduced which allows a caller to initiate a v2 handshake.
This adds the v2 software flag to the list of services btcd supports and adds functionality to optionally use v2 transport if the peer supports it.
This commit introduces detailed logging throughout the v2 transport implementation using the `btclog` package. Logging has been added to key functions to provide better visibility into the handshake process, packet encryption/decryption, and underlying network operations. Log levels are used as follows: - Debug: High-level steps within functions (e.g., starting handshake, creating ciphers, sending/receiving major components). - Trace: Detailed internal state, cryptographic operations, byte-level data (e.g., derived keys, intermediate values, raw bytes sent/received, loop iterations). - Info: Significant state changes or events (e.g., reverting to v1). - Warn/Error/Critical: Issues encountered during operation. Logging includes variable states using the format "key=%v" for easier parsing and debugging. This enhances observability during connection establishment and data transfer using the v2 transport protocol.
…v1 peers When ShouldDowngradeToV1() returns true, we'll: - mark in pendingReconnects that we should attempt v1 bitcoin p2p transport when the connmgr successfully re-establishes the outbound TCP connection. - set a bit on the associated *serverPeer that will cause us to tell the connmgr to reconnect. This is needed because not all outbound peers are permanent and we might otherwise not reconnect to them if the initial v2 transport negotiation failed.
This changes the Disconnect function to accept a `reconnect` argument. Also change handleDisconnected to have reconnection logic.
Add VerifyLowS helper function to ECDSA signature
In this commit, we pin every in-tree go.mod to the freshly cut submodule tags ahead of a btcd point release: btcec/v2.4.0, btcutil/v1.2.0, btcutil/psbt/v1.2.0, and chaincfg/chainhash/v1.2.0. The btcec bump also drags secp256k1 up to v4.4.0 (and blake256 to v1.1.0 transitively) for every module that imports btcec. v2transport stays at v1.0.1 since no v2transport code changed since the last tag, but its go.mod is bumped here so the workspace resolves to a consistent set of internal deps.
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).
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 in-tree go.mod files to new submodule tags
mod: remove `btcutil` circular dependency with main module
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.
multi: pin new v2 submodule tags and bump to v0.26.0-beta.rc1
`make build`, `make unit-cover`, and `make unit-race` all use plain `go test` without the rpctest build tag, so anything under //go:build rpctest -- the entire integration/ package outside of rpctest/, and parts of rpctest/ itself -- is not exercised by CI. Bugs that only surface under -tags=rpctest can land on master without detection. Add a test-rpctest job that runs `make unit` (which sets -tags=rpctest) so rpctest-tagged tests are part of every push and PR.
p2a_test.go calls btcutil.NewAddressPayToAnchor, but the NewAddressPayToAnchor constructor lives in the address/v2 module's address package. Import that package and call it through there so the integration package builds when -tags=rpctest is set.
StringOrArray.MarshalJSON emits JSON null for a nil slice (see existing test "nil slice marshals as null" in TestStringOrArrayMarshalJSON), but UnmarshalJSON did not have a matching case for null and fell to the default branch, returning "invalid string_or_array value: <nil>". A round trip of a nil slice therefore failed. This bit the rpcclient against btcd's own getblockchaininfo, whose Warnings field is a StringOrArray that the server leaves as a nil slice when there are no warnings. Every rpctest integration test that touches GetBlockChainInfo (TestBIP0009, TestBIP0068AndBIP0112Activation, TestBIP0113Activation, TestPrune) failed to decode the response. Handle the nil case explicitly so null decodes back to a nil slice, and add regression cases for "warnings: null" and an omitted warnings field to TestGetBlockChainInfoWarnings.
handleInvMsg early-returned for any inv from a non-syncPeer whenever sm.current() was false, with the comment that it prevents fetching a mass of orphans. That guard assumes a syncPeer is already fetching blocks; when syncPeer is nil, the assumption breaks down and the early return becomes a deadlock. The deadlock is reachable whenever two nodes connect at equal heights: startSync exits without picking a syncPeer (no peer is "higher"), and nothing later promotes the freshly-mined blocks the peer announces via inv. The pre-verack disconnect and sync-race regression tests in integration/sync_race_test.go fail consistently because of this. Only skip the inv when we actually have a syncPeer. When syncPeer is nil, fall through and let the normal request path queue the block -- the inv is the only signal that there are blocks to fetch.
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.
…ken-integration-tests-1 .github: actually run the integration tests in the CI
Commit 26124d2 made every peer a sync candidate on regtest and simnet so that nodes on non-localhost networks (e.g. Docker bridge networks) can be synced from. Dropping the address requirement was the intent, but the change also dropped the service-flag requirement, so light clients became eligible sync peers. A light client (e.g. neutrino) advertises a recent best height but can serve neither headers nor blocks. Electing one as the sync peer stalls the sync until the stall handler disconnects it, and with other light client connections present the next one is elected and stalls again, livelocking the sync indefinitely. This surfaced in neutrino's sync tests, where a btcd simnet node connected to both a neutrino instance and other btcd nodes never synced. Keep accepting any peer address on regtest/simnet, but require the peer to signal SFNodeNetwork or SFNodeNetworkLimited like on any other network.
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.
…ackage rpcclient: add typed SubmitPackage method
netsync: require block-serving services on regtest/simnet sync peers
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.