btcd

This commit fixes a class of crash bugs in btcd's PSBT (Partially Signed Bitcoin Transaction) handling for Taproot transactions. Previously, if certain Taproot-related lists contained a nil (empty) entry, the code would panic when trying to sort, read, or finalize the transaction. The patch now rejects these malformed entries early with a proper error instead of crashing the program. It is a defensive hardening fix rather than a direct theft-of-funds vulnerability, but a crash in a wallet or node could still be disruptive.

This commit fixes two related bugs in btcd, a Bitcoin node implementation. First, it prevents the getblock RPC from using database memory after it has expired, which could previously cause crashes or corrupted block data. Second, it makes block reading from the node's own database more forgiving of old trailing garbage bytes, so historical blocks written by older btcd versions remain readable. The change is defensive maintenance rather than an active exploit fix, and it includes new tests to verify the behavior.

This commit fixes a race condition in btcd's peer networking code. If a peer was told to disconnect before a network socket had been attached, the socket could later be attached but never closed, leaking the connection. The fix adds a lock so that attaching a socket and disconnecting cannot happen at the same time, and any socket attached after a disconnect is started gets closed immediately instead of being left open.

This commit adds a new optional feature to btcd's connection manager that lets operators set a maximum number of simultaneous inbound connections. It is a defensive hardening change, not a fix for an active vulnerability. The default behavior remains unlimited, so existing users are unaffected unless they explicitly configure a limit.

This commit refactors how btcd handles incoming Bitcoin v2 transport handshakes. It adds a new admission-control hook so a responder can decide whether to spend CPU on a v2 handshake only after it has seen enough bytes to confirm the peer is actually attempting v2, not v1. It also fixes two smaller robustness issues: handshake write failures are now propagated to callers, and short writes are explicitly rejected. The change is defensive in nature and appears aimed at preventing CPU-exhaustion attacks and improving error handling, not at introducing new functionality.

This commit adds a new inbound connection rate-limiting and admission-control system to btcd. It is designed to reduce the risk of denial-of-service attacks where an attacker opens many incomplete handshake connections or forces the server to do expensive v2 transport cryptography for many sources at once. The change caps how many unfinished handshakes a single IP prefix can hold, limits the rate of CPU-heavy v2 responder handshakes both globally and per source, and reserves part of the peer budget for automatic outbound peers so inbound connections cannot starve them.

This commit fixes two problems in the way btcd reads Partially Signed Bitcoin Transactions (PSBTs). First, the parser could hang forever when reading from a network connection or pipe because it tried to read one extra byte to check for leftover data. Second, when given a base64-encoded PSBT, it would read the entire input into memory before checking whether it was valid, so a maliciously huge input could force the program to allocate enormous amounts of RAM. The patch limits how much base64 data is read and only checks for trailing bytes when the reader can safely report its remaining length.

This commit changes btcd so that when it reads old blocks from its own database, it ignores any extra bytes tacked onto the end of the stored block data instead of refusing to start. Older versions of btcd sometimes saved blocks with extra trailing bytes, and a previous stricter change made the node unable to start after an upgrade. The fix logs a warning, drops the extra bytes, and makes sure any cached copy of the block no longer contains them. It does not change how blocks received from the network or RPC are checked.

This commit adds a new test to the btcd PSBT (Partially Signed Bitcoin Transaction) library. The test checks that when extracting a final Bitcoin transaction from a PSBT, the library rejects a final witness value that has extra trailing bytes after a valid witness stack. Previously, this trailing data might have been silently accepted, which could lead to non-standard or invalid transactions being produced. The commit itself only adds a test, not a fix, so it implies a prior or pending code change that enforces this rejection.

This change tightens how a Bitcoin PSBT library extracts final witness data when turning a partially-signed transaction into a finished transaction. Previously, extra bytes after the declared witness stack were silently ignored. Now the library rejects such packets. That prevents malformed or crafted PSBTs from sneaking hidden data into the witness field, which could in some scenarios alter transaction behavior or be used to confuse downstream tools.

This commit fixes a bug in how btcd parses Schnorr (BIP-340) digital signatures. The code was supposed to reject signatures whose 's' number was larger than the allowed group order, but instead it silently wrapped the value around (modulo reduction) and accepted it. This could let invalid signatures pass validation, potentially allowing signature malleability or unexpected behavior in systems relying on strict BIP-340 compliance. The fix checks the overflow flag and now rejects such signatures with the already-defined ErrSigSTooBig error.

This change only fixes a flaky test. It does not change any production code, so it has no security impact on real users or the network.

This commit fixes a memory-usage issue, not a security vulnerability. When reading PSBT data, the code was keeping a pointer to a large 4 MiB internal memory block even for tiny scripts. The patch copies the small script into its own compact memory slice so the large block can be released. It does not fix a bug that lets an attacker steal funds, crash the program, or bypass validation.

This commit changes how btcd reads blocks from its internal database when starting up. Previously it used a loose block parser (wire.MsgBlock.Deserialize) that could accept data with extra trailing bytes. Now it uses btcutil.NewBlockFromBytes, which is stricter and rejects malformed or padded block data. The change is defensive: it makes the node refuse to load a block from disk if the stored bytes are not a clean, exact block. This could prevent certain database corruption or tampering scenarios from being silently accepted at startup.

This change makes the PSBT (Partially Signed Bitcoin Transaction) parser reject files or data that have extra bytes after the end of a valid PSBT. Previously, extra trailing data was silently ignored, which could let an attacker hide malicious content inside what looks like a legitimate PSBT, or cause two different byte strings to be treated as the same PSBT. The patch is only four lines and adds a check that the input is fully consumed after parsing.

This commit changes how submitted block proposals are decoded in the Bitcoin RPC server. It switches from a loose block parser to a stricter one that validates the block more thoroughly before accepting it. The likely goal is to prevent malformed or invalid block proposals from being processed further, which could otherwise cause incorrect behavior or resource waste.

This commit only adds a new test to the btcd blockchain package. The test verifies that when the software starts up, it rejects a stored 'best block' whose saved bytes contain extra trailing data after the valid block. It does not change any production code, so by itself it cannot introduce or fix a runtime security issue. It is a regression test that documents expected behavior already enforced elsewhere.

This commit fixes a bug in the MuSig2 multi-signature code where reading a partial signature from an input stream could fail silently. Previously, if the stream ended early or had a read error, the function would return 'no error' as if the signature had been decoded successfully. Now it correctly returns the actual read error. This could have allowed malformed or truncated signatures to be treated as valid, potentially leading to incorrect multi-signature behavior.

This commit only adds new unit tests. It does not change any production code. The tests verify that two helper functions already reject input that contains extra bytes after a valid Bitcoin block or transaction. Because no code behavior is changed, there is no direct security fix here.

This commit only adds a new unit test. It checks that the Bitcoin RPC command testmempoolaccept correctly rejects a transaction hex string that has extra trailing bytes. There is no code fix or behavior change in the main program—just a test verifying existing behavior.

This commit only adds a new test file. It does not change any production code. The test checks that the PSBT parser rejects transaction fields that have extra trailing bytes. Because no actual parser logic is modified, this commit by itself does not fix or introduce a security issue.

This is a one-byte fix in a test file. A test transaction used to exercise the Bloom filter code had an extra trailing zero byte, making it malformed. The change removes that extra byte so the test data is a valid serialized Bitcoin transaction. It does not change any production code, network behavior, or security logic.

This change tightens how base64-encoded PSBT (Partially Signed Bitcoin Transaction) data is decoded. Previously, the decoder could silently ignore extra whitespace or unexpected characters in the base64 stream. Now it rejects anything that isn't strict, clean base64. This is a defensive hardening fix: it prevents malformed or cleverly padded base64 inputs from being accepted, which could in theory be used to sneak invalid data past validation or cause inconsistent parsing between different PSBT implementations.

This commit changes how the 'decoderawtransaction' RPC command reads raw transaction bytes. Previously it used a looser deserialization method that could accept data beyond the end of the transaction. Now it uses a stricter parser that rejects trailing extra bytes. The likely security relevance is preventing malformed or padded transaction blobs from being accepted as valid, which could otherwise mislead wallets, explorers, or downstream services that rely on this RPC output.

This commit only changes Go module configuration so that the main btcd project uses local copies of two of its own sub-packages (btcutil and wire) instead of fetching them from the internet. There is no code behavior change, no bug fix, and no security relevance visible in the diff.