Bitcoin Core

This commit is a straightforward internal code cleanup: it moves the logic for listing wallet descriptors from the RPC command code into a reusable wallet helper function. There is no user-facing behavior change, no bug fix, and no security-relevant change visible in the diff.

This change fixes a wallet bug where a newly added descriptor's pre-existing cache was kept in memory but never saved to disk. If the cache is lost, the wallet may need to rescan the blockchain to recover key derivation data, causing delays or apparent balance issues. It is a data-durability fix rather than a remote-exploitable vulnerability.

This is a small Bitcoin Core wallet change that lets the wallet generate addresses from certain descriptors even when it does not have private keys and has already used up its pre-derived address range. It only affects descriptors that can expand entirely on their own (public-only, no cached data needed). The change is more of a correctness/availability fix than a security flaw, and there is no direct evidence in the commit that it fixes a vulnerability.

This commit adds a new helper method called CanSelfExpand() to Bitcoin Core's descriptor system. It lets the code ask whether a wallet descriptor can produce its Bitcoin address(es) on its own, without needing a saved cache or private keys. The change is mostly a new capability with matching tests; it does not by itself fix a known bug or change user-facing behavior, but it lays groundwork that could later be used to avoid loading private keys just to display addresses.

This commit simply updates the Boost dependency used by Bitcoin Core's build system from version 1.90.0 to version 1.91.0-1, including the new download URL and cryptographic hash. There is no indication in the commit itself that this fixes a security issue. It appears to be a routine dependency version bump.

This commit adds a safety check in Bitcoin Core when it talks to an external hardware wallet or signer tool. Previously, the software accepted whatever 'fingerprint' string the external tool returned. Now it requires that fingerprint to be exactly 8 hexadecimal characters. Without this check, a misbehaving or malicious signer could supply an oddly formatted fingerprint that might later confuse wallet logic, cause crashes, or be used to trick the user into pairing with the wrong device. The change is small and defensive: it rejects bad fingerprints early and throws a clear error.

This commit is a minor cleanup in Bitcoin Core's continuous integration (CI) configuration. It changes the way some on/off settings are written in shell scripts from quoted strings like "true" and "false" to unquoted true and false. There is no security issue here; it is purely a style or consistency improvement in test automation files.

This commit simply changes one CI (continuous integration) job to use a smaller GitHub Actions runner size, from 16x to 8x. It is a cost or resource tuning change with no security relevance.

This commit only adds new test code to Bitcoin Core. It checks that a locked wallet refuses an empty importdescriptors request, and that an unlocked wallet accepts one. There is no change to production wallet logic, so it does not fix or introduce a security issue on its own.

This commit only adds a release note explaining that a new index format uses slightly less disk space. It is documentation only and contains no code changes that could affect security.

This is a minor storage optimization for a Bitcoin Core index. It changes the on-disk value stored alongside each index entry from an empty string to a zero-byte value, saving one byte per entry when the index is rebuilt. The lookup logic only reads the keys, so existing indexes with the old format continue to work normally. There is no security issue.

This commit removes two logging-only functions from a Bitcoin Core test file. The functions only printed messages to the console when kernel warnings were set or unset during tests. Their removal does not change any production code, network behavior, or security logic. It is a minor cleanup of test output.

This commit adds a new public API to Bitcoin Core's libbitcoinkernel that lets callers create a custom 'signet' network with their own challenge script. Signet is a test network where blocks must be signed by a known key. The change only exposes existing internal functionality through the kernel library and adds a test; there is no indication it fixes a security bug.

This commit adds a new fuzz test for Bitcoin Core's inter-process communication (IPC) system. Fuzz tests are automated quality-assurance tools that feed random or semi-random data into code to find crashes or bugs. The change only introduces test code and build configuration; it does not alter any production networking, consensus, or wallet logic. There is no indication this commit fixes or introduces a security vulnerability.

This Bitcoin Core change tightens how three RPC commands—deriveaddresses, scanblocks, and scantxoutset—handle the JSON value null when it is passed for an optional parameter. Previously, passing null could be treated the same as not passing the argument at all, which in some cases caused the command to proceed with missing required data and either crash or behave unexpectedly. The patch makes the RPC framework explicitly reject null for these parameters, returning a clear error instead. It is a defensive hardening fix rather than a fix for an active exploit.

This commit only changes Bitcoin Core's internal functional test code. It introduces a small test helper class called NodeSigner so that one specific test (feature_taproot.py) can run even when Bitcoin Core is compiled without its built-in wallet. There is no change to production node or wallet code, and nothing in the commit suggests a security bug or fix.

This is a small test-only code cleanup. A helper function used only in Bitcoin Core's functional test suite now returns the full private/public key pair instead of just the public key, so that future tests can spend coins sent to a generated address. It does not change any production wallet, node, or consensus code, and it does not introduce a security vulnerability.

This commit only adds a release note describing a previously implemented limit on a transaction queue. It does not change any code behavior, so it has no direct security impact on its own. The note tells users that a privacy-related transaction queue now holds at most 10,000 entries and that callers must manage it if it fills up.

This commit adds a hard cap of 10,000 transactions to Bitcoin Core's private-broadcast queue. Before the change, that queue could grow without bound, potentially consuming large amounts of memory and CPU if many transactions were submitted, if network rules differed between nodes, or if fees were set badly. The patch rejects new submissions once the cap is reached, returning a clear RPC error instead of silently growing. It is a defensive hardening change, not a fix for an active exploit.

This commit changes how Bitcoin Core holds an internal lock (cs_main) when retrying private transaction broadcasts. Previously, the lock was held for the entire batch of stale transactions; now it is released and re-acquired between each individual transaction. The stated goal is to make the node more responsive when hundreds or thousands of transactions are being revalidated in quick succession. This is a performance and liveness improvement, not a fix for a clear security vulnerability.

This commit only adds a release note describing a performance improvement for block validation. It contains no code changes, no bug fixes, and no security-related content.

This commit adds a new automated test (a fuzzing harness) for Bitcoin Core's coin database view. It does not change any production code, user-facing behavior, or network protocol. It only adds a test that exercises reading the LevelDB-backed coin database concurrently with other operations. There is no indication of a security fix or vulnerability.

This commit changes how Bitcoin Core fetches transaction input data (the 'coins' spent by transactions in a block). Instead of doing all lookups one-by-one on the main thread, it now submits the work to a thread pool. The change is described by its authors as a performance improvement only. There are no obvious security bugs in the diff, but it adds new multi-threaded state and fallback paths, which increases complexity slightly.

This commit only updates a code comment (docstring) in a header file. It explains how a new parallel coin-fetching mechanism works. No actual code logic was changed, so it cannot introduce or fix a security vulnerability on its own.

This commit only adds and updates unit tests for an existing Bitcoin Core component called CoinsViewOverlay. It does not change any production code that runs on the live Bitcoin network, so it cannot directly introduce a security vulnerability or fix one in shipped software. The changes make the test block creation more realistic by allowing some transactions to spend outputs from earlier transactions in the same block, and they add tests for edge cases like out-of-order coin access, disabled worker threads, and reusable overlay state.