Bitcoin Core

This is a small Bitcoin Core wallet change that makes the encryption key-stretching benchmark use a mockable clock during testing. If the measured time is zero (likely because a test fakes the clock), it falls back to a fixed default number of iterations instead of trying to divide by zero or produce unstable results. It is a test-stability improvement, not a fix for an active security vulnerability.

This commit is a pure build-system refactor: it moves the file `lockedpool.cpp` from the `kernel` and `util` libraries into the `crypto` library. The change is organizational only and does not alter any code behavior. It is not a security fix and does not introduce a vulnerability.

This change makes Bitcoin Core store sensitive AES encryption/decryption context data in locked, non-swappable memory instead of ordinary memory. The goal is to reduce the chance that encryption keys or key-derived data leak into swap files or core dumps. It is a defensive hardening patch, not a fix for an actively exploitable bug.

This commit is a code cleanup (refactor) that changes how Bitcoin Core calculates how many password-stretching iterations to use when encrypting a wallet. It replaces a two-step manual timing-and-averaging process with a small loop that does the same thing more generally. There is no security bug visible in the change; it is purely a maintainability improvement.

This commit only improves the wording of an error message shown when a user sets a transaction fee rate that is too low. It adds suggestions to adjust wallet or network fee settings. There is no code behavior change, no bug fix, and no security impact.

This patch fixes a crash in a Bitcoin Core RPC command called gettxoutsetinfo. The command reports statistics about the set of unspent transaction outputs (UTXOs). The bug was a timing issue: the code briefly noted the current best block while holding one lock, then released that lock and later compared the saved block to a newer best block. If the blockchain advanced in between, an internal consistency check could fail and crash the node. The fix removes the stale saved block reference and instead uses the block that the statistics were actually computed against.

This change fixes a timing bug in how Bitcoin Core calculates statistics about all unspent coins (the UTXO set). Previously, the code could read the current best block, then briefly allow a new block to be connected, and only then start scanning the coin database. That could make the final report say it was for block X while the actual data came from block X+1. The fix captures both the block pointer and the database cursor while holding the same global lock, so they stay consistent. It is a correctness fix for an RPC/administrative feature, not a direct theft or remote-code-execution vulnerability.

This commit adds a new convenience feature to Bitcoin Core's internal thread pool: a way to submit a batch of tasks in a single call. It is purely a code-quality/performance improvement (one lock acquisition instead of many) and includes new unit tests. There is no security-relevant change.

This commit is a straightforward code cleanup: it changes the GetProxy function so that instead of returning true/false and writing a proxy value into a caller-provided variable, it returns the proxy value directly using std::optional when a proxy exists, or nothing when it doesn't. All callers are updated to match the new pattern. There is no change to security behavior, network logic, or user-facing functionality.

This commit is a straightforward code cleanup (refactor) that changes how a proxy configuration helper returns its result. It switches from an old-style output parameter and boolean success flag to a modern C++ optional return value. There is no security-relevant behavior change visible in the diff.

This commit only changes comments in a single source file. It updates documentation to describe how transaction ordering is chosen when multiple equally-good options exist. No actual code behavior was changed, so it cannot affect security on its own.

This commit replaces a binary routing/peer-mapping data file (asmap) with a newer version. There is no code change, no bug fix, and no indication of a security issue. It is a routine data refresh used to help Bitcoin nodes connect to peers across different internet networks.

This is a routine internal cleanup in Bitcoin Core. It swaps a recursive mutex (a lock that allows the same thread to lock it multiple times) for a plain mutex in the argument/settings manager, and adds compiler annotations so the code cannot accidentally try to hold the lock twice on the same call path. There is no user-facing bug fix or security patch here.

This is a code cleanup change that hides internal details of Bitcoin Core's command-line argument manager and improves how tests access it. It does not fix a security bug or change user-visible behavior.

This is a straightforward internal code cleanup in Bitcoin Core. It replaces public method calls with private equivalents inside functions that already hold a lock, so the same lock is not acquired twice. The commit explicitly states there is no behavior change, and the diff supports that: every change is a one-for-one replacement of a locked wrapper with its already-locked internal version. There is no security bug being fixed here.

This commit only changes Bitcoin Core's internal unit tests. It restructures how tests lock a shared mutex (cs_args) so that public methods are called without already holding the lock, preventing recursive lock attempts that would deadlock if the mutex were made non-recursive in the future. There is no change to production code, no user-facing behavior change, and no security vulnerability being fixed.

This commit is a pure internal code cleanup in Bitcoin Core's argument-handling module. It splits a few existing functions into private 'lock already held' helpers and adds compiler annotations that document which functions require a specific mutex to be held. There is no change to program behavior, no new feature, and no fix for a security bug.

This commit cleans up Bitcoin Core's code after Taproot has already activated. It removes Taproot's old activation parameters from the list of live BIP9 deployments and from the getdeploymentinfo RPC, because those parameters are no longer needed now that the rules are enforced. It also makes sure getblocktemplate still tells miners the 'taproot' rule is required. There is no direct security vulnerability here; it is routine post-activation maintenance, though any consensus-cleanup change carries a small risk of accidental behavior change.

This commit only updates two documentation files to reflect newer operating system versions tested by the project. It changes version numbers and web links in build guides for FreeBSD and macOS. There is no code change and no security relevance.

This change only modifies Bitcoin Core's internal fuzz testing harnesses (tools used to automatically find bugs during development). It registers the peer manager with the validation signal system during fuzz tests so that more code paths are exercised, and removes a no-op synchronization call. There is no change to production network code, no fix for a live vulnerability, and no user-facing impact.

This commit is a minor user-facing cleanup. It replaces hardcoded references to 'debug.log' with the actual custom log filename when a user has set one via the -debuglogfile option, and softens a few help/error strings to say 'debug log' instead of 'debug.log'. There is no security issue here.

This commit simply deletes three TODO comments from a CI helper script. There is no code behavior change, no bug fix, and no security relevance.

This commit simply updates the versions of several linting tools used in Bitcoin Core's continuous integration (CI) pipeline. Linting tools check code style and catch common mistakes, but they are not part of the actual Bitcoin software that users run. There is no indication this change fixes or introduces a security vulnerability.

This is a test-only change. It makes one functional test wait longer before giving up when running under slow tools like valgrind. It does not change Bitcoin Core's production code, network behavior, or wallet security.

This commit only updates a code comment in Bitcoin Core's build system. It replaces a vague remark about a Qt build option not working with a direct link to the upstream Qt bug report. No code behavior changes, no security fix, and no vulnerability is introduced or patched.