Bitcoin Core

This is a small code cleanup in Bitcoin Core's internal fuzz-testing utilities. It swaps one type name for another that behaves identically and removes some unnecessary 'const' keywords. There is no change to how the software runs or any security fix.

This is a fix to a Bitcoin Core functional test, not to production wallet code. The test was predicting a backup filename based on a cached mock time, but the helper it called also changed mock time internally, which could make the predicted filename wrong and cause the test to fail. The fix calls the migration RPC directly and copies a wallet file explicitly. There is no security issue in the Bitcoin Core software itself.

This commit only adds a new test case to Bitcoin Core's functional test suite. It checks that the wallet's listdescriptors command, when asked to include private keys, still works correctly even when some descriptors were imported with only public keys (missing private keys). There is no change to production wallet code, no bug fix, and no security patch.

This commit tightens a Bitcoin Core wallet RPC command so that watch-only wallets (which intentionally never store private keys) can no longer be asked to export private-key versions of their descriptors. Previously, the command would attempt to produce a private descriptor string and fail with a generic error; now it rejects the request up front with a clear message. It also replaces an error-handling path with an internal consistency check. The change is defensive and reduces the chance of misleading behavior or future bugs, but it does not appear to expose funds on its own.

This Bitcoin Core change alters how wallet descriptors are printed when some (but not all) private keys are present. Previously, exporting a private descriptor would fail entirely if any single key was missing. Now it succeeds and exports the private keys it does have, falling back to public keys for the rest. The commit message and code comments frame this as a usability improvement for multi-key descriptors such as taproot (tr()). There is no direct evidence in the commit of a security vulnerability being fixed; it appears to be a behavior change that could affect information disclosure expectations.

This commit refactors how Bitcoin Core's descriptor code turns key information into text when private keys are requested but not available. Previously, if any private key was missing, the whole private-string output could be dropped or partially empty. Now the code falls back to including the public version of the missing key instead, and reports whether any private keys were actually included. It is a behavior change in output formatting, not a fix for an active exploit, and the commit message explicitly calls it setup for a later change.

This is a small internal refactoring change in Bitcoin Core's wallet migration code. It swaps one method for another when deciding whether a wallet descriptor should be treated as watch-only during migration. The commit message says this is to keep the current pull request focused on RPC behavior and that a follow-up change may refine the logic later. There is no direct evidence in the commit of a security bug being fixed.

This commit adds a new helper function called HavePrivateKeys() to Bitcoin Core's descriptor system. It is a preparatory refactor: it gives the code a clearer way to check whether a wallet descriptor is 'watch-only' (has no private keys) before an upcoming change to ToPrivateString(). The commit itself does not change user-visible behavior; it only introduces the new check and updates tests to use it. There is no direct evidence in the commit that this fixes an active security bug, but it is clearly related to correctly identifying whether private keys are present, which can affect wallet security logic.

This patch fixes a cleanup routine in Bitcoin Core's wallet tool. Previously, when creating a wallet from a dump file failed, the tool used a broad 'delete everything in this directory' command. The change makes it delete only the specific files that belong to the wallet it just created, reducing the risk of accidentally wiping unrelated files or directories.

This commit only adds new test code. It introduces test vectors for BIP 328 (a Bitcoin improvement proposal related to the MuSig2 multi-signature scheme) to verify that public-key aggregation and synthetic extended-public-key generation produce expected outputs. No production code is changed, so it cannot directly introduce a runtime security vulnerability.

This commit only adds a new automated test to Bitcoin Core. It checks that when a user tries to migrate an old wallet on a pruned node, and the wallet's last known block has already been pruned (deleted) from the local copy of the blockchain, the migration fails with a clear error message instead of doing something unsafe. There is no change to production wallet or node code.

This commit fixes a naming bug during Bitcoin Core wallet migration. When a user migrates the default wallet (which has no name), the newly created watch-only and solvables wallets were being given names like '_watchonly' and '_solvables' instead of 'default_wallet_watchonly' and 'default_wallet_solvables'. The fix applies the same 'default_wallet' prefix already used for backup files. This is primarily a correctness and usability fix, not a security vulnerability, though the resulting name collision could theoretically cause migration failures or confusion.

This commit only improves user-facing log messages during Bitcoin Core's wallet migration process. It adds a message saying the new wallets are being loaded after migration, and another message if a wallet fails to load and the migration must be rolled back. There is no security fix or behavior change beyond clearer logging.

This commit only adds a new automated test to Bitcoin Core. It does not change any production wallet code. The test checks that if migrating the default (unnamed) wallet fails, the main wallets directory is not deleted, a backup file is created, and the original wallet is restored. It is a regression test for a previously fixed bug, not a security fix itself.

This commit fixes a bug in Bitcoin Core's wallet migration feature. When a user tried to migrate an old-style unnamed wallet and the migration failed, the cleanup code accidentally deleted the entire /wallets/ directory, wiping out all wallets and the backup file. The fix changes the cleanup to only remove specific database files created during migration, and only remove newly created empty directories. It also adjusts wallet restore to allow restoring into an existing directory as long as no database file would be overwritten.

This commit only adds new automated tests for the wallet restore feature in Bitcoin Core. It does not change any production wallet code. The tests verify that restoring a wallet backup behaves correctly in edge cases: restoring into an empty directory, a directory with unrelated files, a directory that already contains a wallet database file, the default unnamed wallet file, and a pruned node where the backup is too old. Because no actual wallet logic is modified, this commit does not introduce or fix a live security issue on its own.

This change fixes a cleanup bug in Bitcoin Core's wallet restore feature. Previously, if restoring a wallet failed part-way through, the code would delete the entire wallet directory using a broad 'remove everything' command. The patch makes the function remember exactly which files and folders it created, and only delete those specific items on failure. Right now this doesn't cause data loss, but it is needed to safely support a follow-up change where restore may reuse an existing directory that could contain other important files.

This is a change to a Bitcoin Core fuzz test, not to the live Bitcoin network code. It fixes a test-only simulator so that it no longer pretends that spent coins still exist in the underlying database. This makes the fuzz test behave more like the real code, but it does not fix a vulnerability in production Bitcoin Core.

This is a test-only cleanup. It fixes a fake test helper so it no longer returns already-spent coins, matching how the real Bitcoin Core coin database works. It does not change production code, so it cannot directly affect live Bitcoin nodes or user funds.

This change adds a safety check inside Bitcoin Core's database lookup for coins (unspent transaction outputs). It ensures that if the database somehow returns a spent coin, the program will stop immediately rather than continue with bad data. It is a defensive hardening patch, not a fix for a known active attack.

This commit only changes which Linux distribution version Bitcoin Core's automated testing system uses for a handful of test jobs. It switches from Ubuntu 24.04 to Debian Trixie so the tests can run with a newer compiler (GCC 14). There is no change to the Bitcoin software itself, no user-facing change, and no security fix or vulnerability.

This commit applies a patch to the GCC compiler used by Bitcoin Core's Guix build system. The patch fixes a compiler bug where the order of internal numbering could differ depending on the build machine's processor architecture (x86_64 vs aarch64). This caused the same source code to produce slightly different binary outputs when cross-compiled on different host machines. The fix ensures the numbering happens in a fixed, predictable order, restoring 'deterministic builds'—the property that the same source always produces the exact same binary. This is not a vulnerability in Bitcoin Core itself and does not create a way to attack users directly.

This commit updates the Bitcoin Core build system to use a newer version of the GCC compiler (14.3.0 instead of 13.3.0) for its reproducible Guix builds. There is no security-relevant code change here; it is a routine toolchain version bump.

This commit hardens the Bitcoin Core Guix build by compiling GCC itself with a security flag called --enable-host-bind-now. That flag tells the linker to mark the resulting GCC programs so they resolve all dynamic-library addresses immediately at load time, rather than lazily when first used. This is a defensive hardening measure that makes certain memory-corruption attacks harder, but it is not a fix for a known exploitable bug in Bitcoin Core.

This commit changes the build recipe used by Guix (a reproducible-build system) to compile GCC with gprofng disabled. gprofng is a newer profiling tool bundled with some GCC versions. The change is a hardening/packaging tweak: it removes an unneeded component from the compiler used to build Bitcoin Core releases, reducing the attack surface and build-time dependencies. There is no direct evidence in the commit or supplied references that this fixes a known exploitable vulnerability.