btcd

This commit only adds a new integration test that sends a null value for the optional verbosity parameter of the getblock RPC and checks that the server returns a normal verbose block response. It does not change any production code. The test is described as covering a previously fixed server panic, but the fix itself is not present in this commit.

This patch fixes a server crash in btcd's JSON-RPC 'getblock' command. When a caller did not provide an optional 'verbosity' parameter, the code later dereferenced a nil pointer, causing the entire btcd process to panic. The fix supplies a default verbosity value of 1 when the parameter is missing, preventing the crash.

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 client-side method called SubmitPackage to btcd's RPC client. It does not change any server-side code, mempool logic, or consensus rules. It simply lets programs ask a Bitcoin Core node (version 24+) to submit a group of related transactions using an existing Bitcoin Core RPC. There is no obvious security vulnerability in the change itself.

This commit fixes a test-only reliability bug, not a security vulnerability. When running btcd's integration tests in parallel, two test processes were accidentally sharing the same temporary file path and the same starting port number. That caused random test failures: one process could overwrite the other's freshly built test binary, or two processes could try to use the same network port. The fix gives each test process its own random file name and a random starting port range. It does not change anything in the live Bitcoin node software end users run.

This is a one-line code cleanup that silences a Go linter warning by explicitly discarding the return value of a function call. It does not change program behavior or fix any security issue.

This commit is a routine code reorganization: it splits the Bitcoin transaction-script library (txscript) into its own Go module and updates all internal references to use new v2 versions of related packages. There are no visible security fixes or behavior changes in the script engine, signature validation, or consensus logic. The changes are mostly import-path updates and replacing one test helper library with inline code to avoid a circular dependency.

This commit is a large code reorganization: it moves the Bitcoin address-handling code into its own top-level Go module and upgrades its internal import path to version 2. The actual address/base58/bech32 logic appears to be copied over largely unchanged, with only minor additions such as a new pay-to-anchor address type. There is no obvious security bug introduced by the move itself, and the commit message does not describe any security fix.

This commit is a routine Go module restructuring: it makes the `wire` package its own standalone Go module and updates its import path to version 2 (`github.com/btcsuite/btcd/wire/v2`). It also updates internal imports of the `chainhash` package to use its new v2 path. There are no functional code changes, no bug fixes, and no security-relevant modifications visible in the diff.

This commit fixes two minor issues flagged by Go 1.26's vet tool. One is a test-only bug where a failing test inside a goroutine used the wrong error-and-exit call, which could leave the test running with bad state. The other is a non-security formatting bug in help text generation where percent signs in user-visible descriptions could be misinterpreted as format codes. Neither appears to be an exploitable security vulnerability.

This commit simply updates the Go programming language version required to build the project from 1.22/1.23.2 to 1.25, and updates the continuous integration build environment to use Go 1.26.3. It also fixes documentation that incorrectly stated the minimum version. There are no code logic changes and no security vulnerability is introduced or fixed.

This commit simply renames a small helper function from interfaceAddrs to InterfaceAddrs, making it usable by other packages. It does not change any behavior, fix a bug, or alter security logic.

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 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 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 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 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 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 fixes documentation comments in the code. It corrects a description about which nonce-generation method is used when a custom nonce option is provided. No actual signing logic or behavior was changed, so there is no security risk from this patch itself.

This commit fixes a typo in a log message only: 'alloacting' is corrected to 'allocating'. There is no functional code change, no security fix, and no behavior change.

This commit adds a new public getter method called CombinedNonce to the MuSig2 signing session in btcd. It simply lets callers read the already-computed combined public nonce, returning an error if it isn't ready yet. There is no change to cryptographic logic, no bug fix, and no security-relevant behavior.

This commit adds a new public method called RegisterCombinedNonce to the MuSig2 multi-signature code in btcd. It lets a signing session accept an already-aggregated public nonce from an external coordinator, instead of requiring each signer to collect every individual nonce itself. The change is a feature addition with explicit safety checks: it rejects registering a combined nonce twice, rejects mixing combined-nonce and individual-nonce registration on the same session, validates the nonce parses as two valid public keys, and preserves the existing one-sign-per-session nonce-reuse guard. Nothing in the commit message or diff suggests a security bug is being fixed; it appears to be a normal API enhancement for coordinator-based signing workflows.