Bitcoin Core

This commit adds a new automated fuzz test for Bitcoin Core's private transaction broadcast feature. It is purely a testing/quality-assurance change and does not modify any production networking or consensus code. There is no security vulnerability here.

This commit only adds a new test case to Bitcoin Core's script test suite. It verifies that a special edge-case number ('negative zero') is treated as plain zero by the CHECKSEQUENCEVERIFY opcode and therefore fails with the expected 'unsatisfied locktime' error rather than a 'negative number' error. There is no change to production code, no bug fix, and no security patch.

This commit only adds new test cases to a JSON test file for the Bitcoin Core test suite. It exercises ways the CHECKLOCKTIMEVERIFY (CLTV) script operation can fail, but does not change any production code, consensus rules, or network behavior. It is a test-only addition with no direct security impact on running software.

This commit only adds release notes describing a prior code change (PR #32800). It documents that several RPC calls now expose two separate virtual-size fields and that the old `vsize` field is deprecated. There is no code change here, only documentation.

This commit adds a new read-only field called vsize_adjusted to the getrawtransaction RPC output, but only when the transaction is currently in the memory pool. It exposes information the node already calculates for mempool policy, so it does not change behavior, fix a bug, or introduce a vulnerability. It is a transparency/feature improvement for RPC users.

This Bitcoin Core change fixes a labeling problem in several RPC (remote procedure call) responses. The old 'vsize' field was actually reporting a sigop-adjusted size, not the plain BIP 141 virtual size its documentation claimed. The patch keeps the old 'vsize' value for backward compatibility but marks it deprecated, and adds two new clearly-named fields: 'vsize_bip141' for the true BIP 141 virtual size and 'vsize_adjusted' for the sigop-adjusted size. It is an API clarity/documentation correction, not a consensus or mempool rule change.

This commit is a straightforward internal code reorganization: it moves the LoadGenesisBlock function from the Chainstate class to the ChainstateManager class, marks its return value as important to check, and slightly rewords two rare error log messages. There is no change to how Bitcoin Core validates blocks, handles transactions, or protects against attacks. It does not fix a security bug or introduce a known vulnerability.

This is a tiny change to a single unit test in Bitcoin Core. It swaps which test transaction is used in one assertion so the test matches the scenario described in the comment above it. There is no change to production code, no security fix, and no vulnerability.

This is a trivial code-cleanup commit. It removes a duplicate [[nodiscard]] marker from a function definition in a source file, because the same marker is already present on the function's declaration in the header file. The duplicate had no effect on program behavior or security.

This commit changes the error code returned when Bitcoin Core's private broadcast transaction queue is full. Previously, the node reported an 'out of memory' error (-7), which was misleading because the server is not actually running out of memory. The new error code (-37, RPC_LIMIT_EXCEEDED) more accurately tells the caller that a configured capacity limit has been reached. This is a correctness and clarity improvement, not a security fix for a vulnerability.

This commit only changes test code. It swaps generic true/false checks for equality checks on an enum and adds a helper so that if a test fails, the output shows the actual enum value (e.g., 'QueueFull') instead of just 'false'. There is no change to production code, no bug fix, and no security relevance.

This commit fixes a crash bug in Bitcoin Core's wallet coin selection. When the wallet tried to estimate fees for spending unconfirmed coins, it took two separate snapshots of the mempool. If the mempool changed between those snapshots—such as when someone artificially lowered a transaction's fee priority—the second fee could be higher than the first. That produced a negative 'discount' value, which then triggered an internal assertion that the value must be zero or positive, causing the wallet process to crash. The fix simply skips applying the discount when it would be negative.

This commit only adds a new automated test to Bitcoin Core. It checks that a user-configured onion address still gets advertised even when the node is told to only use IPv4. There is no code change to the actual Bitcoin node behavior, so this commit does not introduce or fix a security vulnerability on its own.

This commit only adds a new automated test to Bitcoin Core. It checks that the -externalip command-line option can bypass the -onlynet restriction when a user explicitly configures an external address, while normal local-address registration still respects network reachability rules. There is no change to production code, no bug fix, and no security vulnerability being patched.

This commit fixes a configuration bug in Bitcoin Core. Previously, if a user told their node to only use one network type (for example, only IPv4) and also manually set an external address on a different network (for example, a Tor onion address), the node would silently ignore the manually configured address. The change makes the node honor the user's explicit -externalip setting even when it belongs to a network otherwise excluded by -onlynet. It is a usability/configuration fix, not a vulnerability that allows attackers to take over nodes or steal funds.

This commit is a small, non-functional code cleanup. It adds a new optional parameter to an internal networking function so that a future change can allow user-specified local addresses to bypass a network-reachability check. The new parameter defaults to false, so existing behavior is unchanged. There is no security bug or fix here.

This is a small performance cleanup in Bitcoin Core's network code. A temporary cache used when reconstructing compact blocks used to be fully sized up front, meaning the code would repeatedly scan empty placeholder slots. The change instead grows the cache only as it fills, so reconstruction skips unused slots. There is no direct security vulnerability being fixed; it is an optimization that may slightly reduce CPU work during block reconstruction.

This commit simply archives the release notes for Bitcoin Core version 31.1. It adds a documentation file summarizing what changed in that release, but does not change any program code. There is no direct security risk from this documentation-only change.

This change is a small network-efficiency cleanup, not a security fix. Bitcoin Core's 'feeler' connections are brief probes used to check whether another node is online. Previously, the software would ask feeler peers for addresses (sending a GETADDR message) even though it disconnects almost immediately and never reads the reply. The patch stops that unnecessary request, saving a little bandwidth. It does not fix a vulnerability and does not change how attackers could interact with the network.

This commit fixes a bug where Bitcoin Core could hang during shutdown if the user started a 'reindex' and then asked the program to quit before it finished loading the very first block. The fix adds a notification so the shutdown request is noticed, plus a test that simulates this exact scenario. It is a reliability/availability fix, not a security vulnerability that an attacker can exploit.

This is a minor code cleanup in Bitcoin Core. It swaps one internal error-message helper for another that produces the exact same text on macOS and Linux, and removes an unused header include. There is no functional change and no security impact.

This is a minor continuous-integration (CI) build fix for Bitcoin Core's OpenBSD cross-compilation job. It changes one package name so the build system installs the matching version of the LLVM linker (lld-22) instead of accidentally installing a different version (lld-21). It does not change any code that runs on users' wallets, nodes, or the Bitcoin network, and there is no security issue here.

This commit is a build-system cleanup. It moves the handling of the FreeBSD software development kit (SDK) out of the shared dependency build files and into the continuous integration (CI) configuration. The actual compiler flags and download logic remain essentially the same; they are just placed in a more appropriate file. There is no user-facing change and no security fix or vulnerability introduced.

This commit simply updates the FreeBSD version number used in automated testing from 15.0 to 15.1. It is a routine CI (continuous integration) maintenance change with no security relevance.

This commit only adds two new test cases to a JSON test file used by Bitcoin Core's automated test suite. The tests verify that certain script operations (CHECKSIGVERIFY and CHECKMULTISIGVERIFY) produce the expected error codes when they fail. No production code was changed, so this cannot introduce or fix a security vulnerability on its own.