btcd

This commit fixes a subtle internal race condition in btcd's peer-handling logic. Previously, a peer could disconnect at exactly the wrong moment, causing the server to tell its sync manager that a peer had finished even though it had never been properly registered. That produced only a warning and skipped cleanup, but it weakened the invariant that every 'peer done' event matches a prior 'peer add' event. The patch adds an explicit flag so the server only runs cleanup side effects for peers that were actually registered.

This commit hardens a Bitcoin peer handshake callback so it cannot accidentally close the same notification channel twice if future code changes call it from multiple goroutines. The old design was safe only because of a distant, unenforced rule about which goroutine could call it. The new design uses Go's sync.Once to make the 'close only once' guarantee obvious and robust. There is no currently reachable bug; it is a defensive correctness fix.

This commit only adds new test code for an existing feature called P2A (pay-to-anchor) script recognition. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its own. The tests verify that the software correctly identifies a special Bitcoin script type and does not confuse it with other script types.

This commit changes how btcd recognizes a new Bitcoin output type called 'pay-to-anchor' (P2A) when checking whether a transaction is allowed to spend it. Before the change, P2A outputs were treated as an unknown future witness version, which could cause btcd to reject valid P2A spends or behave differently from Bitcoin Core. The fix makes btcd explicitly accept P2A spends as valid 'anyone-can-spend' outputs, matching expected network rules. There is no direct evidence in the commit that this is a security bug, but inconsistent script validation between node implementations can lead to chain splits or transaction relay problems.

This commit adds support for a new Bitcoin address type called Pay-to-Anchor (P2A). It is a feature addition that lets btcd recognize and encode/decode a specific kind of SegWit address used for transaction fee bumping. There is no indication in the commit that it fixes a security bug or introduces a vulnerability.

This commit adds support in btcd's transaction-signing code for a new Bitcoin output type called P2A (Pay-to-Anchor). P2A outputs are intentionally designed to be 'anyone-can-spend,' meaning no signature is needed to spend them. The change simply tells btcd to return an empty script when asked to sign such an output, rather than failing because it doesn't recognize the type. This is a feature addition to keep btcd compatible with Bitcoin's evolving protocol, not a fix for a vulnerability in the cryptographic sense. However, because P2A outputs are anyone-can-spend by design, any wallet or node that mishandles them could in theory lose funds placed in such outputs, so the change has security-adjacent relevance.

This commit adds a new mempool policy rule for a special Bitcoin output type called Pay-to-Anchor (P2A). It ensures that transactions spending P2A outputs are only accepted into the memory pool if they have empty signature and witness data. It also adds tests confirming the dust threshold for these outputs. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a policy implementation aligning btcd with expected Bitcoin network behavior.

This commit only adds a new integration test file for the recently added Pay-to-Anchor (P2A) feature in btcd. It does not change any production code, consensus rules, or network behavior. The test verifies that P2A outputs can be created, spent without a signature, and that policy rules reject invalid variations (non-empty witness and sub-dust outputs). There is no security vulnerability here.

This small update teaches btcd's transaction-script parser to recognize a new Bitcoin output type called 'Pay-to-Anchor' (P2A). Without this change, the parser would treat P2A outputs as unsupported, which could cause btcd to reject or mishandle transactions that use this new output type. The patch also adds a safety check so that scripts without an associated address don't accidentally return a nil address. It is a forward-compatibility / robustness fix rather than a clear-cut vulnerability patch.

This commit adds support in btcd for a new Bitcoin output type called Pay-to-Anchor (P2A). It is a feature addition, not a fix for a known vulnerability. P2A outputs are designed to be 'anyone-can-spend' scripts used for fee-bumping (CPFP). The change itself appears defensive and correct, but because it introduces a new script class and address type, it could affect how wallets and downstream tools classify transactions. There is no direct evidence in the commit or supplied references that this is a security patch or that it addresses an active exploit.

This commit only adds new test code for a previously fixed bug. It does not change any production code, so it cannot introduce or fix a live security issue on its own. The tests verify that a type called StringOrArray can be safely converted to JSON without getting stuck in infinite recursion, and that a 'warnings' field can accept either a single string or a list of strings.

This commit adds a missing 'Warnings' field to btcd's JSON-RPC response structure for getblockchaininfo. It is a compatibility fix so btcd can parse responses from Bitcoin Core versions that include this field, whether it is a single string or an array of strings. There is no security vulnerability here.

This commit fixes a bug where a piece of code responsible for turning a list of text strings into JSON format accidentally called itself forever, eventually crashing the program with a stack overflow. The fix changes the code to convert the custom type to a plain list of strings before handing it to the JSON encoder, breaking the endless loop.

This commit fixes broken test code, not production code. After an earlier change made the regtest network follow stricter block-version and coinbase-height rules, several newer tests were still creating fake blocks the old way, causing them to fail. The patch updates those test helpers to produce valid regtest blocks and headers. There is no security issue in live software.

This commit only reformats code to match the project's style rules. It changes whitespace and indentation in three files and removes one blank line. There are no functional changes, no bug fixes, and no security implications.

This commit fixes a bug in btcd's RPC batch client. Previously, if sending a batch of RPC requests failed (for example, due to a network or server error), the client would clear its internal list of batched requests but would never signal the failure to each individual request's 'future' result object. Callers waiting for results could therefore block forever. The patch adds a helper that fans out the Send() error to every queued request and clears tracking state in one place, plus a regression test verifying queued futures complete with the same error.

This commit fixes a bug in btcd's RPC batch client where creating a batch client accidentally started two background goroutines for sending HTTP POST requests instead of one. That broke the intended single-file behavior: two RPC requests could be sent at the same time rather than one at a time. The patch makes NewBatch simply turn on batch mode instead of starting the handlers again, and adds a test to confirm only one POST is in flight at a time.

This commit improves how the btcd RPC client shuts down when using plain HTTP POST mode. Previously, an in-flight HTTP request could keep running after the client was asked to shut down, potentially making shutdown hang or wait for a network timeout. The change wires the shutdown signal into the HTTP request context so that pending requests are cancelled immediately, and it adds tests to confirm shutdown interrupts requests during retries and while reading response bodies.

This commit fixes a race condition in btcd's RPC client that could cause the client to hang forever during shutdown. When the client was shutting down at the same moment a request was being sent, the old code could both mark the request as failed due to shutdown and still place it in the outgoing queue. A cleanup loop would later try to send a second response on a channel that was already full, blocking indefinitely. The fix prioritizes the shutdown path so requests are failed immediately and never queued once shutdown has started. A regression test was added to confirm the behavior.

This commit only changes a test file in btcd. It adds helper functions so that btcd's transaction-script test runner can understand newer Bitcoin Core test vectors marked 'BADTX' (context-free invalid transactions). No production code is modified, so this cannot directly affect live Bitcoin nodes or wallets.

This is a tiny one-line change in btcd's transaction-script engine. It swaps the error code returned when a SegWit (witness) script leaves extra items on the stack after execution. Previously the code reported a generic 'evaluation returned false' error; now it reports the more specific 'clean stack' error expected by Bitcoin Core's reference test suite. The commit message frames this as test-compatibility, not a security fix, and the change does not alter whether a transaction is accepted or rejected—only which diagnostic error is produced.

This change fixes a subtle mismatch between btcd and Bitcoin Core in how they handle a specific edge case in transaction script validation. When a signature is empty in a CHECKSIG operation, btcd previously skipped checking whether the provided public key was properly encoded and simply returned 'false'. Bitcoin Core, however, checks the public key encoding first and fails the script if the key is malformed. This patch makes btcd behave the same way, which is important for keeping all Bitcoin nodes in agreement about which transactions are valid.

This commit fixes how btcd recognizes 'nested' SegWit transactions wrapped inside older P2SH outputs. Previously, two code paths guessed the redeem script by taking a raw slice of the signature script starting at the second byte (sigScript[1:]). That shortcut can mis-identify the redeem script when the signature script has more than one data push or unusual encoding. The patch makes all three relevant code paths agree: the redeem script is the last data push in the signature script. It also removes the requirement that a witness stack must be present to treat an input as nested SegWit, and tightens the malleability check so the signature script must be exactly one canonical push of the witness program. A related change makes unknown future SegWit versions enforce a clean stack instead of silently disabling SegWit behavior.

This commit only changes a test file so that btcd's internal test suite correctly reads the latest Bitcoin Core reference test vectors. It does not alter any production transaction-validation code, consensus rules, or network-facing behavior. There is no security issue here.

This commit fixes a minor policy-level mismatch between btcd and Bitcoin Core. A special script command called OP_CODESEPARATOR, when placed inside an 'IF' branch that never runs, was being rejected by Bitcoin Core's mempool but accepted by btcd. The change makes btcd reject it too, but only as a mempool policy rule—not a consensus rule—so already-mined transactions would still be valid to both. It was found through automated fuzz testing.