Bitcoin Core

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 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 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 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 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 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 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 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 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 commit only renames the word 'command' to 'message type' in comments and a debug log string. It is a documentation cleanup with no functional code changes and no security impact.

This commit only updates the copyright year from 2025 to 2026 in three documentation/legal files. It does not change any executable code, build logic, or network behavior, and has no security relevance.

This commit only turns on a Python style lint rule (E713) that prefers 'not in' over 'not ... in'. It updates test scripts and helper tools to match the style, with no changes to the Bitcoin Core software that users run. There is no security issue here.

This commit is a simple code cleanup: it removes a duplicate function named IsCrypted() and replaces every use of it with an already-existing identical function named HasEncryptionKeys(). There is no change in behavior, no bug fix, and no security issue introduced or fixed.

This commit is a performance and memory-efficiency improvement, not a security fix. It changes how Bitcoin Core builds the list of transaction hashes before computing a Merkle root. Previously, when a block contained an odd number of transactions, the internal duplicate-hash step could force an extra memory reallocation, wasting memory and causing fragmentation. The patch pre-allocates exactly the needed capacity and avoids default-constructing unused objects. There is no vulnerability or exploit here.

This is a tiny type-cleanup in the wallet's 'sendall' RPC command. It changes how the transaction version number is read from a signed integer to an unsigned integer matching the field's actual type. There is no direct evidence in the commit that this fixes an exploitable bug, but using the wrong signed type could in principle allow a user to pass a negative value that gets misinterpreted as a very large positive version number, which might then be rejected or handled unexpectedly.

This is a routine code cleanup commit for the Bitcoin Core project. It removes unused or unnecessary header file includes from several source files related to the 'kernel' module and adds those files to an automated check that enforces correct include usage. There is no functional change to the program's behavior and no security issue is present.

This commit simply deletes a helper script used to manage copyright headers in source files, along with its documentation. It does not change any part of the Bitcoin Core software that handles transactions, networking, wallets, or consensus rules. There is no security issue here.

This commit is a code cleanup in Bitcoin Core's RPC (remote procedure call) response formatting. It removes many old-style C-style casts like (int64_t) and replaces them with either no cast or a safer static_cast. The change is described by the authors as a refactor to make the code less confusing and brittle. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability.

This commit fixes a bug in Bitcoin Core's mempool RPC output where fee values were incorrectly narrowed to 32-bit integers before being displayed. For very large fee bumps (over about 86 bitcoins), this cast could corrupt the reported 'chunkfee' and 'fees.chunk' values, making them look much smaller or even negative. The fix removes the unnecessary casts and adds a test for large fee deltas. It is a correctness bug in information shown to users and miners, not a direct theft-of-funds vulnerability.

This commit is a code cleanup that replaces old-style container lookups like `.count()` with the newer, clearer `.contains()` method introduced in C++20. It also turns on a linting rule to keep future code consistent. There are no functional changes and no security impact.

This is a small internal cleanup of Bitcoin Core's fuzz testing code. It refactors how test inputs are converted into arbitrary orderings of transactions, with no change to production consensus or networking code. There is no security issue visible in the commit.

This is a one-line fix in Bitcoin Core that prevents a program crash (assertion failure) when adding a new chainstate. The crash could occur if the previous chainstate did not have a memory pool (mempool) initialized. The change simply checks whether the mempool exists before checking its size, avoiding an invalid memory access. It is a defensive hardening fix rather than a user-triggerable exploit path under normal operation.

This commit updates the version of the Cap'n Proto library used in Bitcoin Core's build system from 1.2.0 to 1.3.0, along with its corresponding checksum. It is a routine dependency bump with no direct code changes to Bitcoin Core itself. There is no explicit security claim in the commit, and no verified references were provided to indicate this fixes a known vulnerability.

This commit simply bumps the GitHub Actions 'checkout' step from version 5 to version 6 in the project's continuous integration (CI) workflow file. It does not change any Bitcoin Core source code, consensus rules, wallet logic, or network behavior. There is no indication of a security fix or vulnerability.