btcd

This commit lowers the largest single network message btcd will accept from 32 MB down to 4 MB, matching the limit used by Bitcoin Core. The change is a hardening/configuration alignment, not a fix for a known active attack. It mainly reduces the memory and processing exposure from a peer sending an oversized protocol message, which could help mitigate denial-of-service or memory-pressure issues. There is no direct evidence in the commit that a specific vulnerability was being exploited.

This commit fixes a network-address handling bug in btcd, a Bitcoin implementation. When another node sent an IPv4 address disguised as an IPv6 address inside newer 'addrv2' peer messages, btcd would accept it. The change makes btcd reject those mismatched addresses, matching the behavior of the main Bitcoin Core software. This prevents inconsistent address records from spreading between nodes and avoids potential confusion or attacks that rely on address format tricks.

This commit fixes a network-address classification bug in btcd, a Bitcoin implementation. It makes sure a special type of IPv6 address (ORCHIDv2, defined in RFC 7343) is treated as non-routable, so btcd will not try to connect to it as a regular peer. The change aligns btcd with Bitcoin Core and was found by comparing the two implementations through differential fuzzing.

This commit only adds a new unit test. It does not change any production code, fix a bug, or alter behavior. The test checks that the Bitcoin sync manager does nothing when the local chain is already up to date and no peer has a higher block height. There is no security issue here.

This commit only adds a new unit test. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The test checks that the sync manager does not disconnect a peer that is at the same block height when a stall is sampled.

This commit only adds a new unit test to the Bitcoin-related btcd project. It checks that when the header chain is already up-to-date but the actual block chain is behind, the sync manager skips downloading headers and directly requests blocks. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit only adds a new automated test file for the Bitcoin sync manager. It does not change any production code, so it cannot introduce a security vulnerability or fix one in the running software. The change is purely defensive testing: it simulates various Initial Block Download (IBD) scenarios to make sure the sync logic behaves correctly.

This commit is a simple rename of an internal variable from 'headersFirstMode' to 'ibdMode' (short for 'initial block download mode') and updates related comments. No behavior of the Bitcoin node software changes; it is purely a code clarity and naming improvement.

This commit refactors how the Bitcoin node decides which peer to sync blocks from. It switches the sync logic to rely on the new 'processed headers' state rather than the older internal header list. The change removes direct handling of SegWit peer filtering, checkpoint-based headers-first mode, and some equality fallback logic, delegating those concerns to helper functions like fetchHigherPeers, fetchHeaders, and fetchHeaderBlocks. There is no explicit security fix described in the commit, but any refactor of consensus-critical sync code carries a risk of subtle bugs that could affect which blocks a node accepts.

This commit refactors how btcd's network sync manager handles incoming blocks during the initial blockchain download. It moves checkpoint/header-list logic into a helper function and changes the conditions for switching from 'headers-first' mode to normal mode. The change appears to be a code cleanup and logic simplification rather than a clear security fix. There is no explicit security claim in the commit message or diff.

This commit is a routine cleanup that removes leftover code for a 'headers-first' download mode and checkpoint tracking that is no longer used. There is no security issue here; it simply deletes unused fields and helper functions to make the code smaller and easier to maintain.

This commit only adds a new regression test file. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The test documents a previously fixed bug in block reorganization handling and verifies the fix remains effective.

This change is a defensive refactor in btcd's network synchronization code. It makes a block-downloading helper function take the target peer as an explicit argument instead of silently relying on a shared 'sync peer' field. It also adds checks so the function does nothing if that peer is missing, preventing a program crash (panic) in cases where the sync peer has been disconnected or cleared. There is no direct evidence this fixes an actively exploitable remote vulnerability, but it removes a crash path during peer churn.

This commit fixes a bug in btcd's block-download logic. Previously, when the node asked its sync peer for blocks, it could accidentally request the same blocks twice if a routine refill triggered while those blocks were still in-flight. The duplicate block would then be treated as 'unrequested' and the peer would be disconnected, slowing or stalling synchronization. The fix builds block requests from the processed header chain and skips any blocks already marked as requested.

This commit refactors how btcd handles incoming block headers during peer synchronization. It replaces a custom header-list processing path with a centralized `ProcessBlockHeader` function. The most notable behavioral change is that the code no longer disconnects peers merely for sending headers when the node is not in 'headers-first sync' mode. This could allow unrequested headers to be processed, but the actual validation work is now delegated to the chain's standard header verification logic. There is no explicit security claim in the commit, and the change appears primarily architectural.

This commit adds a new helper function called isInIBDMode to btcd's network synchronization code. It simply checks whether the local node is still catching up to the rest of the Bitcoin network (Initial Block Download mode). The change is purely additive: it introduces the helper and its unit tests, but does not change any existing behavior or fix any visible bug on its own.

This commit adds a new read-only helper function that reports where the chain of fully-downloaded blocks and the chain of known block headers last shared a common block. It does not change any existing behavior, fix a bug, or alter security logic. It simply exposes information already maintained internally so other code can use it for block downloads after reorganizations.

This commit adds a new internal helper function called fetchHeaders to the Bitcoin network synchronization code. It simply picks a peer that claims to have a higher block and asks that peer for block headers. There is no indication of a bug fix or security patch; it appears to be a normal feature/refactoring addition.

This commit adds a new internal helper function called fetchHigherPeers to the Bitcoin network synchronization code, along with unit tests. It simply returns a list of peer connections that advertise a higher blockchain height than a given value and are eligible for syncing. There is no security issue visible in this change.

This commit adds a new internal helper function called checkHeadersList to the Bitcoin network synchronization code, along with unit tests. It decides whether a block being downloaded during initial sync should use a faster verification path (BFFastAdd) and whether the block is a known checkpoint. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability; it appears to be a correctness or refactoring change.

This commit adds a new public function, ProcessBlockHeader, to btcd's blockchain package. It is a feature addition that exposes existing internal header-validation logic so callers can download and validate block headers before receiving full blocks. There is no indication in the commit or supplied references that this fixes a security bug or introduces a vulnerability.

This commit fixes a bug in btcd's blockchain handling where accepting a full block could overwrite an existing header-only entry in the block index. That overwrite would leave an internal 'best header' view pointing to an orphaned record, causing later checks that rely on header membership to fail. The fix reuses the existing index entry and upgrades its status instead of replacing it.

This commit fixes a logic bug in btcd (a Bitcoin implementation in Go). Previously, when the software was asked 'Do you already have this block?', it answered 'yes' if it knew the block's header, even if it did not actually have the full block data stored. Now it correctly checks that both the header is known and the full block data exists on disk. This could have caused the node to skip downloading a block it thought it already had, leading to incomplete data or inconsistent behavior.

This commit adds five new public read-only helper methods to btcd's blockchain package so other parts of the program can query the 'header chain' tip (the longest chain of block headers). The methods only expose information that was already tracked internally; they do not change any behavior, permissions, or validation rules. There is no indication this fixes a bug or closes a security hole.

This change fixes a backwards-compatibility problem in btcd, a Bitcoin implementation. Previously, when a newer btcd stored information about a block header without the full block data, it could write that header-only record to disk. If the user later opened the same database with an older btcd version, the older software would assume the full block existed and fail unrecoverably. The patch now avoids writing those header-only records to disk. It also skips unnecessary database write transactions during header-only sync, which is a performance improvement. There is no direct evidence in the commit of an active security exploit, but the unrecoverable-error scenario is a reliability and availability concern.