btcd

This commit refactors how btcd counts expected inputs and signature operations for a specific kind of Bitcoin transaction: P2SH (pay-to-script-hash) that hides a SegWit (witness) program inside. The main change is that nested P2SH-P2WSH transactions now also account for the inner witness script's expected stack arguments, which the previous code ignored. The commit does not claim to fix a vulnerability, but the change corrects an analysis gap that could cause fee-estimation or policy checks to undercount required inputs for these transactions.

This commit updates a single test data file (tx_invalid.json) used to check that btcd rejects invalid Bitcoin transactions. It pulls in newer test vectors from Bitcoin Core and adjusts some test flags. It does not change any production code, so it cannot directly introduce a live security bug. However, the new test cases include important consensus-related checks (e.g., duplicate inputs, bad coinbase sizes, null inputs, and stricter script rules). If btcd's existing code does not already handle these cases correctly, the tests may now fail and reveal latent consensus or denial-of-service issues.

This commit updates a single test data file (tx_valid.json) used by btcd's transaction-script test suite, syncing it with a newer version from Bitcoin Core. It changes test cases and the verification flags they are labeled with, but does not modify any production code. On its own, this is a test-maintenance change and not a direct security patch. However, the new test vectors are designed to exercise stricter signature rules (DERSIG, LOW_S, STRICTENC, NULLDUMMY, CONST_SCRIPTCODE, etc.) and segwit behavior. If btcd's script engine already enforces those rules, the tests should pass; if it does not, the updated tests would reveal discrepancies. The commit therefore signals an effort to keep btcd aligned with Bitcoin Core's consensus and standardness rules, which has indirect security relevance, but it does not by itself fix or introduce a vulnerability.

This commit only updates a single test data file (script_tests.json) used by btcd's transaction-script test suite. It pulls in the latest test vectors from Bitcoin Core. No production code, consensus logic, or network behavior was changed. It is a test-only synchronization and does not introduce or fix any security vulnerability on its own.

This commit only updates btcd's test code to understand the latest Bitcoin Core test file format. It adds new error-code names used in reference tests, skips taproot placeholder rows that are tested elsewhere, and cleans up field indexing. There is no change to the actual transaction-script validation engine that runs on the live Bitcoin network, so this does not create or fix a security vulnerability in production code.

This commit only changes test code. It updates the expected error messages in a test file to match a newer version of a cryptographic library and swaps one test-comparison helper for another. There is no change to the actual signature-recovery logic that runs in production, so it does not create or fix a security vulnerability in live code.

This commit adds a new helper function called VerifyLowS to the btcd Bitcoin library's ECDSA signature code. Its purpose is to detect signatures whose 'S' value is in the mathematically equivalent but non-standard 'high-S' form, which can make signatures malleable (one valid signature can be transformed into another valid one). The commit also adds unit tests. It does not by itself change any consensus or network validation rules; it only provides a reusable utility for callers to enforce low-S if they choose.

This commit only updates two dependency version numbers in Go module files (go.mod and go.sum). It bumps the secp256k1 cryptographic library from version 4.0.1 to 4.4.0, plus a minor update to an indirect dependency. The commit message says the newer version exposes an internal value used by a helper function elsewhere in the same branch. There is no actual code change in this commit, and no security problem or fix is described.

This commit changes how the btcd RPC client parses JSON string responses. Instead of using a full JSON parser to extract quoted strings, it now uses a custom helper that strips the surrounding quote characters directly. The stated goal is performance: fewer memory allocations and faster parsing. The change removes proper JSON validation from several code paths, which could in theory allow malformed or unexpected server responses to be processed incorrectly. However, the commit message frames this purely as an optimization, and no security bug or exploit is demonstrated in the materials.

This commit adds a new client method to request and decode a Bitcoin proof that a transaction was included in a block. It also adds a small helper that strips surrounding quote characters from a JSON string response instead of fully parsing it. There is no indication in the commit that this fixes a security bug; it appears to be a routine feature addition with a minor parsing optimization.

This commit only adds and improves regression tests for a previously fixed peer lifecycle race condition. It does not change production code, so it cannot introduce a new vulnerability or directly fix one. The tests verify that a prior fix behaves correctly under edge cases such as duplicate verack messages and peers disconnecting before handshake completion.

This commit adds new strict hash-parsing functions to btcd's chainhash package. The existing lenient functions accept shortened or odd-length hex strings and silently pad them with zeros, which can be risky when parsing transaction or block IDs. The new strict helpers require an exact 64-character hex string. The commit does not switch any callers to the strict versions, so it is a defensive API addition rather than an immediate fix for a known vulnerability.

This commit tightens the maximum allowed size of Bitcoin protocol 'reject' messages so it matches the general message-size limit already used elsewhere. Before the fix, a reject message could claim a legal size under one check but then fail to send under a stricter second check, which could cause inconsistent handling between reading and writing network messages.

This commit simply enables the `--wallet` command-line option to work on Bitcoin's regression test network (regtest) by assigning it the default port 18332. Previously, using `--wallet` with `--regtest` produced an error because the companion btcwallet software did not yet support regtest. There is no security issue here; it is a routine feature-enablement change.

This commit fixes a bug where IPv4 addresses were accidentally advertised as IPv6 addresses on the Bitcoin peer-to-peer network. Because of how Go stores IP addresses internally, a 16-byte IPv4-mapped IPv6 representation was being tagged with the IPv6 network type. Bitcoin Core silently ignores such mixed messages, so affected btcd nodes could have had their address announcements ignored by peers, potentially hurting connectivity and peer discovery. There is no direct evidence this was exploited as an attack.

This commit only adds a new unit test to btcd's networking code. It checks that a special IPv6 address format (the IPv4-mapped IPv6 address ::ffff:127.0.0.1) is correctly treated as an IPv4 address. There is no code change that fixes or changes behavior; it only adds a test verifying existing behavior.

This commit fixes a design mix-up in btcd's Bitcoin message handling. It restores the general 32 MB serialization safety limit and adds a separate ~4 MB limit specifically for peer-to-peer network messages. It also adds a missing size check for the newer v2 transport message reader. The change is defensive: it prevents very large messages from being accepted over the network while keeping internal database/RPC serialization limits consistent with Bitcoin Core.

This commit only adds a new unit test. It does not change any production code, so it cannot introduce a security vulnerability by itself. The test checks that btcd's sync-manager treats all peers as valid sync candidates on the Bitcoin 'regtest' private network, including Docker container addresses and remote IPs. This is expected behavior for regtest, which is meant for local testing and has no real-world Bitcoin value at stake.

This change loosens a network safety rule for two private Bitcoin test networks (regtest and simnet). Previously, nodes on these test networks would only accept initial block download from a peer running on the same computer (localhost). Now they will accept it from any reachable peer, such as another node in a Docker container. This is a deliberate usability fix for testing environments, but it removes a guard that helped prevent untrusted remote peers from feeding blocks to a regtest/simnet node. It is not a vulnerability in the public Bitcoin network (mainnet), which is unaffected.

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