Bitcoin Core

This commit only updates user-facing help text and a tooltip to explain that wallets and indexes should be loaded and kept active while block pruning is enabled. It is a documentation-only change with no code behavior changes, no bug fix, and no security patch.

This commit only updates documentation links and adds Doxygen anchor comments in source code so that the developer documentation points to the right places. It does not change any program behavior, logic, or security settings.

This is a tiny code cleanup in a Bitcoin Core RPC command. It removes an unnecessary cast to uint64_t when reporting how many bytes were written to a file. The actual value being reported does not change, and there is no security issue.

This commit tweaks the Bitcoin Core dependency build system so that an environment variable used for reproducible builds (SOURCE_DATE_EPOCH) is cleared before generating package IDs. The goal is to avoid unnecessary rebuilds of dependencies when only that timestamp changes, improving build-cache reuse. There is no direct security vulnerability in the diff itself; it is a build-system hygiene change.

This commit adds a one-line configuration file telling CMake/CTest where to upload test results (a CDash dashboard URL). It does not change how Bitcoin Core is built or tested by default, and it does not introduce any security-relevant code change.

This commit simply adds a new person's PGP key to the project's security contact list in a documentation file. It is an administrative update with no code changes and no security vulnerability.

This commit fixes a bug in a Bitcoin Core fuzz test (a randomized testing harness), not in the main Bitcoin software. The test was building a sample P2SH (pay-to-script-hash) output incorrectly by placing an 'OP_EQUAL' instruction at byte 12 instead of byte 22. This only affects the test's internal data setup and has no effect on real transactions, wallets, or network behavior. The second change is a trivial typo fix in a comment.

This commit only changes a benchmark test file used to measure wallet coin-selection performance. It replaces an old, unrealistic benchmark with a more diverse and deterministic one. There is no change to production wallet code, consensus rules, networking, or any code that runs on real user wallets or nodes.

This is a minor code cleanup in a benchmark test file. It removes an unused wallet parameter from a helper function used only for performance testing of coin selection. The change does not affect live wallet behavior, network consensus, or user funds.

This is a minor code cleanup in a benchmark file. It changes a function parameter type from signed to unsigned to match how it is actually used, and removes a duplicated comment. It does not affect the live Bitcoin wallet or network code and has no security relevance.

This commit fixes a memory safety bug in Bitcoin Core's block validation. When checking a new block, the program creates a queue of script checks that may run on multiple threads in the background. It also precomputes some transaction data used by those checks. Previously, the precomputed data was destroyed before the background check queue finished, so the workers could read memory that had already been freed. An attacker could craft a malicious block to trigger this, potentially causing crashes, memory corruption, or worse. The fix simply moves the precomputed data variable so it is created before the queue and destroyed after it, guaranteeing the data stays alive as long as the checks need it.

This commit only changes a fuzz test file. Fuzz tests are automated tools that throw random inputs at code to find bugs. The change makes the fuzzer exercise more code paths in the connection manager, but it does not alter the actual Bitcoin Core networking code that runs on real nodes. There is no security vulnerability here.

This commit only updates a help text string in bitcoin-cli. It clarifies that the -rpcclienttimeout option does not work for local inter-process (IPC) connections. There is no code behavior change and no security fix.

This commit only changes a code comment explaining why the blockfilterindex gets 5% of the total cache budget. It adds a note that a typical two-week offline gap produces a working set of about 200 kB, which fits comfortably within that 5% allocation. No code behavior, cache sizes, or logic are modified.

This change loosens a security sandbox only for one 32-bit Linux continuous-integration test job. Docker's newer default profile was blocking an old 32-bit system call used for sockets, causing the CI job to fail. The patch tells Docker not to apply its default seccomp filter to that container so the tests can run. It does not change Bitcoin Core code that end users run, and it does not appear to be a fix for a vulnerability in Bitcoin itself.

This is a pure variable-name cleanup in Bitcoin Core's ARM SHA-256 code. The old names (ABEF_SAVE/CDGH_SAVE) were misleading labels; the new names (ABCD_SAVE/EFGH_SAVE) match how ARM's SHA-256 instructions actually order the hash state. No instructions, values, or behavior change.

This commit adds a new public function to Bitcoin Core's libbitcoinkernel library that lets outside programs ask the kernel to perform basic, context-free checks on a transaction (for example, whether it has valid outputs and no duplicate inputs). It is purely an API addition: it exposes an existing internal validation routine through a C interface and adds tests. There is no bug fix, no change to consensus rules, and no indication of a security vulnerability.

This is a minor code hygiene change that adds a missing C++ standard library header (<concepts>) to a utility header file. It does not change program behavior, fix a vulnerability, or introduce any security-relevant functionality. It is an 'include what you use' (IWYU) cleanup.

This commit changes a single internal lock in Bitcoin Core's networking code from a recursive mutex (one that lets the same thread lock it multiple times safely) to a plain non-recursive mutex. It also adds many compile-time and runtime checks to make sure no code path tries to lock it twice. The change is defensive hardening: it makes the locking rules stricter so that accidental deadlocks or re-entrancy bugs are caught earlier, but it does not by itself fix a known, exploitable vulnerability.

This is a small internal cleanup in Bitcoin Core's network code. It removes the only case where a particular network lock (m_nodes_mutex) was acquired twice in a nested/recursive way. The change reorders the logic so the list of high-bandwidth compact-block peers is updated without nested lock calls. There is no direct security vulnerability being fixed; it is a code-quality and future-proofing change that makes the locking simpler and easier to reason about.

This is a one-line build-system change for Bitcoin Core. Previously, when developers built the fuzzing test suite, the code automatically disabled a feature called IPC (inter-process communication). This change removes that automatic disable so the IPC fuzz target gets compiled along with the rest of the fuzzing surface. It is a build/test-coverage fix, not a fix for a runtime vulnerability in the Bitcoin node software itself.

This commit only adds a release note document. It describes a previously made change that blocks certain unusual wallet names (like paths containing '..' or '.', or just '/'). There is no code change here, and the note itself is informational documentation.

This change refactors how the standalone bitcoin-wallet tool figures out where a wallet file lives. Previously it computed the path itself; now it calls the same internal helper (GetWalletPath) that the main wallet code uses, which includes checks for invalid wallet names. The likely effect is to prevent mistakes or misuse involving odd wallet names/paths, rather than to fix an active remote-exploitable bug.

This Bitcoin Core change prevents users from importing a special 'unused()' wallet descriptor if the private key it refers to is already present in the wallet. The patch adds a check during descriptor import and a test to confirm the new behavior. The commit message does not describe this as a security fix, and no external security references are provided, so its security relevance is uncertain. It appears to be a defensive correctness fix that could prevent confusion or wallet-state inconsistencies rather than a fix for an active exploit.

This change blocks users from importing a special type of Bitcoin wallet descriptor called unused() into wallets that have private keys disabled. Such wallets are watch-only: they can see transactions but cannot spend. The unused() descriptor is meant to reserve a key for future use. Allowing it in a no-private-key wallet could have led to confusion or situations where the wallet believes it controls funds it cannot actually spend, but the patch is a simple guard with no demonstrated exploit.