Bitcoin Core

This is a benchmark-only change. It moves a 'mark cache dirty' step out of the timed portion of a wallet balance performance test so the benchmark measures only the balance calculation itself. There is no change to production wallet code, consensus logic, networking, or any user-facing behavior.

This is a small code-quality change to a benchmark test that measures how long it takes to create a Bitcoin wallet. It moves wallet cleanup from inside the timed loop to a setup/teardown phase so the benchmark only measures wallet creation. There is no user-facing behavior change and no security relevance.

This is a routine internal code cleanup in Bitcoin Core's wallet module. It merges several places that set up a wallet's address-generation seed/descriptors into a single helper function called SetupWalletGeneration(). There is no indication this fixes a security bug; it appears intended to make the code easier to maintain and to avoid duplicating logic when creating or encrypting wallets.

This Bitcoin Core commit refactors how descriptor wallets are loaded from disk. Instead of creating an empty wallet key manager and then gradually adding keys and cache data to it, the code now gathers all the data first and creates the key manager in one go. The change also adds a safety check that rejects wallets containing both unencrypted and encrypted keys, which previously could have coexisted during incremental loading. There is no direct evidence in the commit that this fixes an active exploit, but the stricter loading model removes a class of potential consistency bugs.

This commit adds a new automated test to Bitcoin Core. The test checks that the software correctly refuses to open a wallet that has been corrupted so that it contains both encrypted and unencrypted copies of the same key. It does not change any production wallet code; it only adds a regression test for an already-existing safety check.

This Bitcoin Core wallet patch changes how private keys are added when a user imports or migrates to a descriptor-based wallet. Previously, keys were added to the descriptor manager in a separate step after creation. The patch bundles the keys into the manager's constructor or update call so all descriptor data is provided at once. The commit message frames this as a code-quality fix, not a security fix. There is no direct evidence in the diff or commit message that this closes an exploitable vulnerability, but it does reduce a window where the wallet state could be inconsistent.

This is a small internal code cleanup in Bitcoin Core's wallet module. It changes how an external-signer wallet manager object is created so that its descriptor is passed directly through the constructor rather than being set afterward via a separate SetupDescriptor method. There is no user-facing behavior change and no security fix.

This is a small internal code cleanup in Bitcoin Core's wallet. It moves the setup of newly generated single-signature descriptors into a dedicated factory-style constructor and tightens some safety checks. There is no obvious user-facing bug or direct exploit here, but the change removes a redundant encryption step and changes when a 'decryption checked' flag is set, which could have subtle wallet-initialization implications.

This commit is a test-only change for Bitcoin Core's wallet code. It moves two internal type definitions to a more private scope and adds a unit test verifying that creating a certain kind of watch-only descriptor wallet (one using hardened derivation without private keys) throws an error because it cannot generate new addresses. There is no runtime bug fix or exploit here; it improves test coverage and code encapsulation.

This is a code cleanup (refactor) in Bitcoin Core's wallet creation logic. Previously, the software temporarily marked encrypted wallets as 'blank' to prevent keys from being generated before encryption, then removed that flag afterward. The change makes the code more explicit by passing a separate 'born_encrypted' parameter instead of reusing the blank-wallet flag. There is no security vulnerability visible in the diff.

This commit fixes a bug in Bitcoin Core's wallet migration logic where the same HD (hierarchical deterministic) wallet seed could be processed more than once if it appeared in both the active and inactive HD chain lists. The duplicate processing could cause a crash during migration, which was discovered through automated fuzz testing. The fix uses a set data structure to ensure each unique seed is only migrated once. There is no direct evidence in the commit that this is exploitable by an attacker to steal funds or compromise the network; it appears to be a reliability/correctness fix for a fuzz-discovered crash.

This is a small hardening change to a fuzz test (automated randomized testing) for Bitcoin Core's wallet descriptor handling. It adds a check that a parsed wallet descriptor can be 'expanded' (converted into actual output scripts) before the test proceeds to add it to a wallet. This prevents the fuzzer from creating wallet state with descriptors that parse but cannot actually be used, which could cause later test steps to hit unexpected failures or assertions. It is a test-only fix and does not change production wallet behavior.

This commit changes a single configuration file used by developers so it only specifies the broad Python version (3.10) instead of an exact patch release (3.10.14). The stated goal is to avoid forcing developers to keep an old, potentially insecure Python patch release installed. It is a tooling/development hygiene change, not a fix for an exploitable vulnerability in Bitcoin Core itself.

This commit is a minor build/maintenance cleanup: it moves three Python package versions from a shell script into a separate requirements.txt file and copies that file into the CI lint container. There is no change to the actual Bitcoin Core software, consensus code, wallet handling, networking, or any user-facing behavior. It only affects how internal linting tools are installed.

This commit tightens the rules for what can be used as a Bitcoin Core wallet name. Previously, a wallet name could contain relative path tricks such as "." (current directory), ".." (parent directory), or start with "./" or "../". Such names could make the wallet software create, read, or overwrite files in unexpected places, especially during the wallet migration process. The change rejects these names outright and adds tests to make sure they are blocked. It is a hardening fix rather than a fix for a known active exploit.

This commit fixes a build failure that occurs when compiling Bitcoin Core with Boost version 1.91 or newer. It changes how certain in-memory data structures (used for tracking orphan transactions, mempool entries, and transaction requests) are declared so they compile with both old and new Boost versions. There is no runtime behavior change, no vulnerability fix, and no security impact.

This commit is a straightforward code cleanup: it replaces a raw integer parameter representing the signature hash type with a small structured options object called SignOptions. All call sites are updated to pass the same value inside the new structure. There is no change to what the program actually does, no bug fix, and no security-relevant behavior change.

This is a straightforward code cleanup change. It replaces a plain integer parameter for the signature hash type with a small options structure called SignOptions. All existing callers are updated to pass the same value inside the new structure. There is no change to what the code actually does or to any security behavior.

This is a straightforward code cleanup (refactor) that bundles several PSBT signing options into a single structure. It does not change what the software does; it only changes how the options are passed around internally. There is no security vulnerability here.

This is a small internal performance cleanup in Bitcoin Core's database iterator code. It replaces repeatedly created temporary data buffers with a single reusable scratch buffer stored on the iterator object. There is no indication this fixes a security bug; it appears aimed at reducing memory allocations and object churn.

This commit only adds new fuzz testing code for Bitcoin Core's compact block (CMPCTBLOCK) handling. It does not change any production network or consensus code, so it cannot introduce a runtime security vulnerability in the software users run. It is a test-harness improvement.

This commit adds a new test case to an existing fuzzing harness for Bitcoin Core's compact block (cmpctblock) handling. It does not change production code, network behavior, or wallet logic. The new code only runs inside a fuzz test and randomly sends 'blocktxn' messages to exercise more code paths during automated testing. There is no security vulnerability here.

This commit only changes Bitcoin Core's internal fuzz testing code. It expands a fuzz harness so that the test can mine fake blocks and send headers for them, improving test coverage for compact block processing. There is no change to production network code, wallets, consensus rules, or RPC interfaces, so it does not introduce a security vulnerability in the software users run.

This commit only changes a fuzz test file (src/test/fuzz/cmpctblock.cpp). It makes the compact-block fuzzing harness create and send fake transactions during testing, and resets internal test state if the mempool changes. There is no change to production Bitcoin Core code, network rules, or wallet behavior. It does not fix or introduce a real security vulnerability.

This commit moves a constant for compact block version from one file to a shared header and updates a fuzz test to exercise the sendcmpct network message. It is a test/refactoring change with no visible security fix or behavior change in production code.