btcd

This commit fixes a bug in btcd's address manager where certain invalid IPv6 addresses starting with '0:' were incorrectly treated as valid internet-routable addresses. These addresses belong to a reserved block that should never be routed. The fix adds a check to reject them, with a special exception for a specific translated-IPv4 range. Because Bitcoin nodes share peer addresses with each other, accepting such addresses could let an attacker pollute the peer database with unusable or specially crafted entries, potentially degrading network connectivity.

This commit swaps the template engine used to build Bitcoin scripts from Go's HTML-aware template package to a plain-text template package. The old engine would automatically escape characters like angle brackets and quotes for safe web display, but because the output here is raw binary script data, that escaping could quietly change the bytes produced. The fix removes a source of silent data corruption when users generate transaction scripts from templates.

This commit adds a safety net to btcd's peer networking code. Previously, a bug in message parsing or handling could crash the entire Bitcoin node. Now, if a peer-handling goroutine panics, the node catches the panic, logs it, and disconnects only the offending peer. It also fixes cleanup so that internal shutdown signals are always sent, even during a panic. The change is defensive and does not by itself fix any known specific crash bug.

This commit only adds a new unit test. It does not change any production code. The test checks that ReadMessage correctly rejects Bitcoin wire messages that have extra garbage bytes appended after the expected payload. The test is verifying behavior that was apparently added in a prior commit (the message mentions a 'new trailing-bytes check'). On its own, this commit is not a security fix and does not introduce a vulnerability.

This change tightens how btcd reads network messages from other Bitcoin peers. Previously, a peer could tack extra bytes onto the end of a valid message and btcd would silently accept it. Now those messages are rejected. The commit message notes that such trailing bytes could have been stored, for example in the block database, so this closes a potential avenue for injecting unwanted data or causing confusion.

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 bug in btcd's transaction decoding where a malformed Bitcoin transaction could claim witness data larger than the internal decode buffer. Before the fix, this could cause a panic (crash) when the code tried to copy data into a too-small buffer. The patch adds a size check so the transaction is rejected cleanly instead of crashing the node.

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