Bitcoin Core

This commit fixes a bookkeeping bug in Bitcoin Core's compact block handling. When receiving a compressed block, the node tries to match short transaction IDs against its own mempool and a small cache of recently seen transactions ('extra_txn'). A bug caused the node to incorrectly decrement the 'extra_count' counter when a mempool-sourced transaction collided with a short ID, even though no extra_txn transaction was actually lost. This could lead to wrong internal counts and, in edge cases, prevent a collided slot from being correctly marked as unusable, potentially allowing later transactions to refill a slot that should stay empty. The fix tracks whether each matched slot came from the mempool, extra cache, or a collision, and only adjusts the appropriate counters.

This commit adds a test case to Bitcoin Core that demonstrates a minor accounting bug in how compact block reconstruction counts 'extra' transactions. The test shows that when a fake transaction in the extra pool happens to have the same short ID as a real block transaction, the internal extra_count counter is reset to zero instead of staying at one. The commit message and a TODO comment make clear this is only a test characterizing the miscount, not a fix for a security vulnerability. There is no evidence this miscount can be exploited to steal funds, crash nodes, or break consensus.

This is a routine code refactor in Bitcoin Core's inter-process communication (IPC) layer. It updates how child processes are launched so the code can work with a future version of a supporting library that adds Microsoft Windows support. The change replaces an older function call with a newer one and adjusts how the child process receives its communication socket identifier. There is no indication this fixes a security vulnerability.

This commit renames and expands a command-line helper in Bitcoin Core. The old 'bitcoin-util netmagic' command, which only printed the network's magic bytes, is replaced by 'bitcoin-util getchainparams', which prints a JSON document containing chain parameters such as genesis block, ports, DNS seeds, and address prefixes. There is no security fix or vulnerability here; it is a routine feature change.

This commit adds a new read-only alias 'rpc.discover' that returns the same public API documentation already available via 'getopenrpcinfo'. It also fixes a metadata annotation so amount fields are described as numbers rather than strings. There is no security-relevant change: no new privileges, no authentication bypass, no code execution, and no bug fix for a vulnerability.

This commit only adds a release note describing a new RPC field called alternate_wtxids. It is documentation only and makes no code changes. There is no security issue in the commit itself.

This commit adds a new field called 'alternate_wtxids' to the output of the wallet RPC command 'gettransaction' (and related transaction listings). It simply shows other witness transaction IDs that share the same base transaction ID. This is an informational UI/API change, not a fix for a vulnerability.

This Bitcoin Core wallet commit changes how the wallet stores transactions that share the same transaction ID (txid) but have different witness data (wtxid). Previously, the wallet would overwrite the stored transaction when a version with witness data appeared. Now it keeps all known variants and picks a 'canonical' one based on rules: confirmed transactions win; otherwise, transactions with witness data are preferred, and lighter-weight transactions beat heavier ones. The change is a defensive refactor to support multiple transaction variants correctly, not a fix for a known active exploit.

This commit adds a new automated test for Bitcoin Core's wallet. It checks that when the same transaction can be spent in two different ways (a lighter 'key path' and a heavier 'script path' on a Taproot output), the wallet correctly reports which version is 'canonical' and lists the other versions as 'alternates'. The commit only adds test code; it does not change wallet logic or fix a bug.

This commit adds a new regression test to Bitcoin Core. It checks that when a wallet created on a newer version is loaded on an older version and then brought back to the newer version, the wallet still remembers alternative 'witness variants' of a transaction. It is purely a test file change and does not modify any production wallet or consensus code.

This Bitcoin Core wallet change lets the wallet remember multiple valid versions of the same transaction that look identical on-chain by transaction ID (txid) but differ by witness transaction ID (wtxid). For example, a Taproot spend can be signed in two different valid ways. Previously the wallet only kept one witness version, which could cause it to lose track of the actual confirmed version or show wrong balances/labels. The fix stores all variants and picks a canonical one, with older wallet software still able to read the main record safely.

This commit removes an unused explicit copy helper and strengthens a safety guard in Bitcoin Core's wallet code. Previously, copying a wallet transaction object was allowed through a private default copy constructor and an explicit CopyFrom() method. The change deletes both, so the object can no longer be accidentally duplicated. The commit message and code comment explain this is meant to prevent bugs where updates happen on the wrong copy of a transaction, not to fix an active security vulnerability.

This is a routine internal code cleanup in Bitcoin Core's wallet module. It makes the transaction pointer inside a wallet transaction object private and forces the rest of the code to read it through a getter function. There is no security fix here; the change prepares the code for a future feature where a wallet transaction might hold more than one transaction.

This commit changes how Bitcoin Core wallet transactions are loaded from disk or copied between wallets. Previously, a wallet transaction object could be created with no actual transaction inside it, and later filled in. The patch makes the transaction data mandatory from the start using a constructor that deserializes directly from a data stream. The stated goal is to prevent crashes (segfaults) caused by accidentally using a null transaction pointer, especially as more transaction types are stored in the wallet. It also improves error handling for corrupt wallet records.

This is a small code cleanup in a fuzz test file. It removes a helper function and changes one call site to use the standard serialization pattern instead. There is no security issue here.

This commit simply removes an unused helper function inside Bitcoin Core's fuzz testing code. Fuzz tests are internal developer tools used to find bugs, not code that runs on live Bitcoin nodes or wallets. There is no security-relevant change to production behavior.

This commit is a code cleanup that changes the way some Python test helper functions are written so that a linting tool (Ruff) can enforce a style rule. It does not change what the software does, only how the test code is formatted. There is no security issue here.

This is a code-quality cleanup, not a security fix. It changes two test-only comparisons from '== False' to 'is False' and removes a linter exception. The commit message says this preserves RPC semantics, but the change is inside Bitcoin's own functional test suite and does not alter the production Bitcoin node software that users run.

This commit is a build-system and test-file reorganization. It merges two test files into one and adjusts CMake rules so the combined test compiles with the required library paths. There is no change to Bitcoin Core's runtime code, consensus rules, wallet handling, or network behavior. It fixes a CI compile error where a test header could not be found, but it does not fix any security vulnerability.

This is a small defensive code change in Bitcoin Core's inter-process communication (IPC) code. It reorders two class member variables so that the event loop is destroyed before the background thread that runs it. The commit message says there is no behavior change and the goal is to clarify intent and avoid potential future bugs. The change itself does not fix a known exploitable vulnerability, but it addresses a real C++ object lifetime risk.

This is a small test-only cleanup that changes hardcoded Unix-style forward slashes in a test file to use the operating system's native path separator. It does not change any production code or fix a security bug.

This commit fixes a Windows build problem. The code included a Unix-only header file ('unistd.h') unconditionally, which caused Microsoft Visual C++ (MSVC) compilation to fail because that header does not exist on Windows. The fix wraps the include so it is only used on non-Windows builds. There is no security issue here—just a portability fix to make the project compile on Windows.

This is a straightforward code cleanup that renames the type used for process IDs from plain 'int' to a new 'ProcessId' alias. It makes the code compatible with a future library update that will support Windows, but does not change any actual behavior or fix any security issue.

This is a purely cosmetic code cleanup that reorders #include lines in a single source file. It moves two standard C++ library headers (<utility> and <vector>) to sit with the other standard headers, separate from POSIX system headers. There is no functional change, no bug fix, and no security relevance.

This commit is a straightforward code cleanup: it replaces the plain 'int' type with a new 'SocketId' type alias when referring to socket identifiers throughout Bitcoin Core's inter-process communication (IPC) code. The change is described by the author as preparation for a future version of the libmultiprocess library that will add Windows support. There is no security fix here and no change to program logic—only type names and a constant for the error value were updated.