Bitcoin Core

This commit is a performance optimization, not a security fix. It stops Bitcoin nodes from building unnecessary 'bloom filters' (a data structure used to track recently confirmed transactions) while they are still downloading the historical blockchain (IBD). Previously, the node wasted CPU recalculating these filters for old blocks even though it wasn't accepting new transactions from peers yet. The functional test was updated to reflect that transactions confirmed during IBD will now be requested again once the node is fully synced, because those filters were not built during IBD.

This commit only adds a new automated test to Bitcoin Core. It does not change any production code. The test documents that transactions confirmed during initial block download (IBD) are remembered and not re-requested from peers once IBD finishes. There is no security fix or vulnerability here.

This is a one-line fix in a Bitcoin Core test script. It changes a test assertion to check the correct expected number of peer broadcasts, preventing a flaky test failure. It does not change any production code or network behavior, so it has no security impact on users.

This commit only moves two test blocks to the end of a single functional test file. It fixes a flaky test failure caused by mock time advancing and prematurely disconnecting private broadcast connections. There is no change to production code, no security fix, and no vulnerability.

This is a build-system fix for Bitcoin Core's CMake configuration when cross-compiling macOS binaries from Linux. It replaces a workaround that disabled a CMake tool check with a harmless stub command, restoring compatibility with newer CMake versions. There is no security issue in the change itself.

This commit adds a new 'interrupt()' button to Bitcoin Core's mining interface so outside callers can stop two long-running mining operations (waiting for a new chain tip and creating a new block) instead of waiting for them to finish on their own. It is a feature/refactoring change, not a fix for an active security bug. The only security-relevant note is that the new interrupt flag is accessed under a lock but is not formally marked as guarded by that lock, which the commit message itself flags as a known imperfection.

This commit only adds release-note documentation describing two new behaviors in the mining inter-process communication (IPC) interface: a startup cooldown for createNewBlock and a new interrupt() method. It contains no code changes and no security fix or vulnerability.

This change adds a short waiting period (cooldown) when Bitcoin Core creates a new block template while the node is still catching up to the network. The goal is to stop mining software from receiving a flood of rapidly changing templates during initial sync. It is a performance and robustness improvement, not a fix for a direct money-stealing or remote-code-execution bug. The patch itself is careful to avoid a known risk: if a malicious miner announced a far-ahead header but withheld the actual block, waiting forever could stall honest miners. The new code caps the wait and only waits while the best header extends the current tip, not a competing branch.

This commit simply adds a new read-only field called 'optimal' to the getmempoolinfo RPC output. It exposes whether the mempool is currently in a known-optimal transaction ordering. There is no change to transaction processing, consensus rules, or network behavior—only an additional diagnostic value returned by an RPC call.

This commit only adds extra logging messages. It does not change how the mempool behaves or fix any bug. It lets developers see, via debug logs, when the mempool's internal transaction ordering is not in the best possible state after routine events such as adding transactions, handling blockchain reorganizations, or processing a new block. The change is observability-only and not a security patch.

This commit removes three source files from the LevelDB build list in Bitcoin Core's CMake configuration. The files (c.cc, dumpfile.cc, histogram.cc) are reportedly unused. This is a routine build cleanup with no apparent security relevance.

This commit changes the Bitcoin Core Guix build scripts to stop using the 'sponge' tool from the 'moreutils' package. Instead of writing a checksum file directly through a pipeline, the scripts now write to a temporary file and then move it into place. This removes a third-party dependency from the trusted build environment, which is a hardening improvement rather than a fix for a known active vulnerability.

This commit is a routine update of the English translation files for the Bitcoin Core graphical user interface. It adds, removes, and reorders user-facing text strings so that translators can work with the latest version of the software. There is no code that changes how the program behaves, and nothing in the commit fixes or introduces a security problem.

This commit removes a temporary workaround in Bitcoin Core's automated testing setup that relaxed a security policy for checking the cryptographic signature on LLVM's software repository. The workaround was added because LLVM's signing key still used the older SHA1 hash algorithm, which newer Linux systems began rejecting. Now that LLVM has fixed its key, the workaround is no longer needed and is being removed. This is a cleanup change that restores normal, stricter security checks in the continuous integration (CI) environment. It does not change the Bitcoin Core software that users run.

This is a minor test-only change in Bitcoin Core's own test suite. It adjusts how long the tests wait for certain log messages to appear, removing unnecessary waits for some checks and adding short waits for others. It does not change the Bitcoin software that users run and has no security impact.

This commit fixes a timing issue in a Bitcoin Core functional test. The test checks that orphan transactions are removed when a block connects, but the check was running before a background queue had finished processing the block. Adding a synchronization call makes the test wait for that background work, so the test reliably sees the expected log message. It does not change production node behavior or fix a security bug in the Bitcoin protocol.

This commit tightens the timing of when Bitcoin Core's RPC call 'gettxspendingprevout' consults the optional on-disk 'txo spender index'. Previously, the code would wait for that index to finish syncing before even looking at the mempool. Now it searches the mempool first, releases the mempool lock, and only then waits for the index if it actually needs to. The goal is to reduce a small window where a block has just arrived, the spending transaction left the mempool, but the index hasn't recorded it yet, so the RPC could incorrectly report no spender. It is a robustness improvement, not a fix for a clear exploit.

This commit only adds a new unit test for Bitcoin Core's address manager. It checks that an address with many recent connection failures is correctly marked as 'terrible' and filtered out when peers are returned, while still remaining in the unfiltered list. There is no change to production code.

This change adds a new convenience field called coinbase_tx to the getblock RPC response in Bitcoin Core. It exposes only small, already-public metadata about the first transaction in a block (the coinbase transaction), such as version, locktime, sequence, coinbase script, and witness data. It does not expose transaction outputs or any new sensitive data. This is a feature addition, not a security fix or vulnerability.

This commit only adds a release note describing a previously implemented feature: automatic Tor hidden services created by Bitcoin Core will use Tor's proof-of-work (PoW) defenses when supported by the Tor daemon. The commit itself changes only documentation and contains no code.

This commit only updates documentation. It adds a note in the Tor setup guide suggesting users enable a Tor hidden-service proof-of-work defense if their Tor version supports it. No code behavior changes.

This change makes Bitcoin Core nodes that advertise themselves as hidden services on the Tor network ask Tor to enable a built-in anti-spam feature called 'Proof-of-Work defenses' when creating those hidden services. If the installed Tor version is too old to understand that option, the code falls back to creating the hidden service without it. It is a hardening improvement, not a fix for an active vulnerability in Bitcoin Core itself.

This is a minor code cleanup change. It moves two Tor status code numbers (250 for OK, 510 for unrecognized command) from one file to a shared header so both the main program and a test fuzzer use the same named constants instead of hard-coding the numbers twice. There is no security fix here and no behavior change.

This commit adds a new optional Bitcoin Core index called the transaction output spender index. When enabled with -txospenderindex=1, it records which transaction spent a given output, allowing the gettxspendingprevout RPC to find confirmed spending transactions, not just mempool ones. It is a feature addition, not a security fix, and does not by itself create a vulnerability. The main security-relevant consideration is that it increases disk and memory use, requires disabling pruning, and exposes more historical chain data through RPC.

This commit simply re-enables an automated test (wallet_multiwallet.py) in the Windows cross-build continuous integration job. It removes the temporary exclusion that was put in place while a bug was being fixed. There is no change to Bitcoin Core's actual wallet code, network code, or consensus logic, so it does not affect users' funds, node security, or network behavior.