Bitcoin Core

This commit changes how Bitcoin Core's internal thread pool shuts down. Instead of the shutdown thread passively waiting for worker threads to finish leftover tasks, it now pitches in and processes tasks itself while workers finish up. The goal is a faster node shutdown when many RPC/REST requests are still queued. The change itself is a performance/cleanup improvement, not a security fix.

This commit simply deletes an outdated explanatory comment from a test helper script. No code behavior changes, no security fix or vulnerability is introduced.

This commit simply adds new pre-calculated snapshot data for a Bitcoin Core feature called 'assumeutxo.' It does not change any security logic, fix a bug, or introduce a vulnerability. It is a routine data update.

This commit updates the internal tuning numbers used by Bitcoin Core when a new node downloads block headers from the network. It pushes the target date forward by six months and refreshes the generated parameters for mainnet, testnet, testnet4, and signet. There is no bug fix, behavior change, or security patch visible in the diff—it is routine parameter maintenance.

This commit updates routine network statistics in Bitcoin Core's chain parameters. It refreshes the recorded number of transactions, timestamps, and transaction rates for mainnet, testnet, signet, and regtest networks based on recent blockchain data. There is no security issue here—this is normal maintenance data.

This commit updates two routine Bitcoin network parameters—minimumChainWork and defaultAssumeValid—to newer block heights for mainnet, testnet, signet, and regtest. These values are checkpoints that help nodes sync faster by skipping validation of very old blocks. The change is a standard, scheduled maintenance update with no security vulnerability.

This commit simply updates Bitcoin Core's built-in estimates of how large the blockchain and chainstate data are on disk. These numbers are used to warn users about required disk space before downloading the chain. The values are being increased to reflect real-world blockchain growth. There is no security bug or vulnerability here.

This commit updates Bitcoin Core's built-in list of network seed nodes—the addresses new wallets use to find peers for the first time. It replaces old, stale addresses with a fresh set of IPv4, IPv6, I2P, and Tor onion-service entries. There is no code change and no indication of a security vulnerability; it is routine network-maintenance data.

This commit fixes a small bug in an internal Bitcoin Core seed-list generator script. When the script saw the same IP address and port more than once, it used to keep whichever entry it encountered last. Now it keeps the one with the most recent successful contact. This makes the generated list of network peers slightly more accurate and reliable, but it is not a security fix for the Bitcoin software itself.

This commit simply updates the list of recognized Bitcoin Core version numbers in a helper script used to generate the network seed list. It is a routine maintenance change with no security relevance.

This is a documentation-only update. It changes the Guix installation instructions for Debian and Ubuntu users because the `guix` package is no longer available in recent distribution repositories. There is no code change and no security issue.

This commit updates Bitcoin Core's automated multiprocess (IPC) tests to match fixes made in an upstream library. The test changes describe that two previously crash-causing IPC scenarios—disconnecting during a call and overloading a server thread—now behave gracefully. A third change documents a macOS-specific exception-handling quirk. The commit itself only changes test code, not the production Bitcoin Core code that handles IPC, so it does not introduce or fix a direct vulnerability in the shipped software. It is evidence that related crash bugs were fixed elsewhere.

This commit updates Bitcoin Core's internal IPC helper library (libmultiprocess) to fix crash and race-condition bugs that can happen when an IPC client disconnects while a server call is still running. It also removes an earlier 'thread busy' limitation so multiple calls can now be queued on the same worker thread. The changes are defensive hardening of inter-process communication, not a new user-facing feature.

This Bitcoin Core change adjusts how the network's memory pool (mempool) handles tiny-value 'dust' transactions when a blockchain reorganization occurs. Previously, during a reorg, transactions that had been mined in a block were re-checked under normal mempool rules, which could wrongly reject related transactions that spend dust outputs. The fix skips that specific dust-spending check during reorgs, allowing legitimate reorged transactions to re-enter the mempool. It is a policy/standardness fix, not a consensus bug, so it cannot change which blocks are valid or steal funds.

This change stops Bitcoin Core from writing the computer's own internet addresses to log files unless the user has turned on the -logips option. Previously, the software logged these addresses even when -logips was off, which could leak private network information in shared logs or backups. The fix is a straightforward privacy improvement, not a fix for an active attack.

This is a test-only code cleanup. It swaps one internal synchronization mechanism for another inside Bitcoin Core's thread pool unit tests. There is no change to the actual Bitcoin node software that users run, and the commit message explicitly says 'No-behavior change.' It cannot affect live funds, network consensus, or security.

This patch fixes a timing bug in Bitcoin Core's internal worker-thread pool. If someone started the thread pool while it was still stopping, the program could freeze (deadlock) or crash. The fix keeps the pool marked as 'stopping' until every worker thread has fully exited, so a new start request is rejected during that window.

This commit updates Bitcoin Core's internal transaction-cluster linearization code with a new set of performance-cost estimates derived from benchmark data. It also tweaks a fuzz test to skip single-transaction cases. There is no change to network protocol, consensus rules, wallet behavior, or any externally observable security property. It is a routine algorithm-tuning change.

This commit is a non-security internal tuning change for Bitcoin Core's transaction mempool linearization logic. It multiplies several cost constants by 38 to prepare for future algorithm changes, and updates corresponding test/fuzz thresholds. There is no bug fix, no vulnerability, and no user-facing behavior change beyond slightly different internal cost budgets.

This is a code cleanup in Bitcoin Core's startup sequence. It changes how an internal notification object is created so it is only created once instead of being deleted and recreated during startup. The commit message says this is needed so that other parts of the program (like mining code) can safely read this object's state while the node is starting up or shutting down, because the object's mutex would otherwise be destroyed and recreated, which could cause crashes or race conditions. There is no direct evidence in the diff of an exploitable security bug.

This commit fixes a crash in Bitcoin Core that could happen when external programs talk to the node over the IPC mining interface while the node is still starting up. Before the fix, calling mining methods too early could trigger an internal assertion failure and crash the node. The fix makes external mining clients wait until the node's chain data is fully loaded before they can proceed.

This commit is a pure internal refactoring of Bitcoin Core's transaction linearization code. It replaces a simple numeric cost counter with a pluggable 'CostModel' class so future work can experiment with different ways of measuring algorithmic work. The default cost model behaves exactly like the old code. There is no user-facing change, no network change, and no security-relevant behavior change.

This commit is a pure rename/refactor. It changes variable names, comments, and constant names from 'iterations'/'iters' to 'cost' throughout the cluster linearization and transaction graph code. No logic, behavior, or security properties are altered.

This is a routine improvement to a Bitcoin Core unit test. It reorganizes when an index is started during the test and adds an extra check that the index fully catches up to the latest block. There is no change to production code, no security fix, and no vulnerability.

This is a small internal code cleanup in Bitcoin Core's startup code. It changes how two internal interfaces (chain and mining) are created, using direct function calls instead of going through an intermediate 'init' object. The commit message explicitly states there is no change in behavior, and the diff shows only two lines changed in a straightforward way. There is no security issue visible here.