Bitcoin Core

This commit only adds a new automated test. It checks that a Bitcoin Core utility can convert the live UTXO set to an SQLite database when the data is fed through a named pipe (FIFO), without first writing a disk dump. There is no change to production code, no bug fix, and no security-relevant behavior.

This change lets Bitcoin Core's `dumptxoutset` RPC command write its UTXO snapshot directly to a named pipe (FIFO) instead of only to a regular file. Previously the command always wrote to a temporary file and then renamed it into place, which doesn't work for a pipe. The patch detects a named pipe and, if one is supplied, writes directly to it and skips the rename step. It also skips the 'file already exists' error for pipes because a pipe is a communication channel, not a stored file. This is a convenience feature for external tools, not a fix for a known security bug.

This commit removes a piece of bookkeeping data called m_starting_height that tracked a peer's reported block height when it first connected. The value is still logged once when the peer's version message is received, but it is no longer stored permanently in the peer's state or shown in other debug logs. There is no security issue here; it is a small cleanup/refactoring change.

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 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 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 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 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 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 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 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 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 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.