Bitcoin Core

This commit removes unused helper code from a single Bitcoin Core functional test file. It deletes three methods/variables that are no longer referenced after an earlier commit. There is no change to production code, network behavior, or wallet logic, and no security relevance.

This commit removes a single unused variable from Bitcoin Core's test framework. It is a cleanup change with no effect on live Bitcoin node software or user funds, and no security relevance.

This commit simply removes an unused helper class from Bitcoin Core's test framework. It is a routine code cleanup with no effect on the actual Bitcoin network software or its security.

This commit simply removes an optional Python linting tool called Vulture from Bitcoin Core's continuous integration setup. Vulture was used to detect unused ('dead') Python code in the project's own scripts. Removing it does not change any code that runs the Bitcoin network or wallet, and it does not introduce a security vulnerability. It is a routine maintenance change.

This is a code cleanup (refactor) of an internal Bitcoin Core RPC helper. It rewrites how the gettxspendingprevout command walks through a list of outpoints and builds its answer, but it does not change what the command does or what data it returns. There is no security-relevant change visible in the diff.

This commit simply updates the version numbers of third-party GitHub Actions used to save and restore build caches during automated testing. There is no change to Bitcoin Core's actual code, consensus rules, wallet behavior, or network logic. It is a routine maintenance update to the continuous integration (CI) configuration.

This commit simply pins a Python linting tool (vulture) to an older version in the continuous integration setup. It is a build/maintenance workaround, not a code change affecting Bitcoin Core's runtime behavior, consensus, networking, or wallet security.

This is a tiny quality-assurance change that adds a compiler-checked note saying the mempool mutex must be acquired after the main chain mutex. It does not change program behavior at runtime; it only helps automated tools detect potential lock-order mistakes during development. There is no direct security fix for users here.

This commit only adds a new test case to Bitcoin Core's functional test suite. It checks that a wallet transaction containing an oversized data output (OP_RETURN) is rejected from the mempool and that the wallet correctly reports the funds as 'nonmempool'. There is no change to production wallet, mempool, or consensus code, so it does not introduce or fix a live security issue.

This commit changes how Bitcoin Core wallets report balances for coins that are spent by transactions no longer in the memory pool. It adds a new 'nonmempool' balance category so users can see these amounts separately, rather than having them silently affect other balance figures. This is a transparency/accounting improvement, not a fix for a code execution or theft vulnerability.

This commit only adds a documentation comment explaining that the btck_WriteBytes callback should return 0 to indicate success. No code behavior was changed.

This commit only adds a release note describing a previously merged feature: the `dumptxoutset` RPC can now write its output to a named pipe on UNIX-like systems. There is no code change, no bug fix, and no security-related content in the diff.

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