Bitcoin Core

This commit removes an old, optional field called 'startingheight' from the 'getpeerinfo' command in Bitcoin Core. The field had already been marked as deprecated in a previous release and was only returned if a user explicitly enabled it. This is a routine cleanup, not a security fix.

This commit simply updates the version numbers of several GitHub Actions used in Bitcoin Core's automated build and test system. There is no indication of a security vulnerability being fixed; it is a routine maintenance change to keep CI dependencies current.

This commit only adds documentation to the depends/README.md file explaining how to set compiler variables when building Bitcoin Core's dependency system. It does not change any code, build scripts, or behavior. There is no security issue here.

This commit is a simple code cleanup: it replaces a function that took two separate arguments with a small options structure. The behavior of the software is unchanged; only the internal organization of the code is different. There is no security issue here.

This is a small internal code cleanup in Bitcoin Core's RPC help system. It replaces a single boolean flag (`skip_type_check`) with a small options structure (`RPCResultOptions`) so future options can be added more easily. No behavior changes, no security fixes, and no user-facing changes.

This commit adds a new automated CI (Continuous Integration) test step for macOS releases. After building the macOS app bundle, the script now unzips the produced file and runs Apple's `codesign --verify` to confirm the application is properly code-signed. It does not change any wallet, networking, or consensus code, and it does not fix a security bug in the software itself. It is purely a build/verification improvement.

This is a one-line fix in the macOS packaging script for Bitcoin Core. The script now looks for Qt's 'plugins' folder instead of its 'translations' folder when deciding where Qt is installed. The old check could fail on newer Homebrew Qt installs because the translations directory no longer exists there, which would prevent the macOS app bundle from being built correctly. There is no direct security vulnerability here—it's a build/packaging robustness fix.

This change fixes how the macOS version of Bitcoin's wallet app is packaged into a ZIP file. The old method silently turned file shortcuts (symlinks) inside the app into duplicate copies, which can make the app bundle larger and may break macOS code-signing or notarization checks. The fix calls the system's `zip` command with an option that preserves symlinks. There is no direct evidence this was exploitable as an attack, but it removes a packaging defect that could cause a shipped app to be rejected or behave incorrectly.

This change makes the encryption initialization vector (IV) used by Bitcoin Core's AES-256-CBC routines live in locked, non-swappable memory and be securely erased when no longer needed. Previously the IV was a normal stack-like array, which could potentially be swapped to disk or remain in memory after use. The IV is not a secret key, but it is cryptographic material that should be handled carefully. The patch is a hardening improvement rather than a fix for a known active attack.

This commit adds a new performance benchmark that measures how long it takes to encrypt a Bitcoin wallet containing many keys. It does not change any wallet, networking, consensus, or cryptographic code that runs in production. It only adds test/benchmark code, so it does not introduce or fix a security vulnerability.

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.