Bitcoin Core

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 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 only updates a README file in the test/lint directory. It adds a sentence pointing readers to another file for dependency installation instructions. There is no code change and no security relevance.

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 changes how the Bitcoin Core project runs its Python code style checker. It switches from installing the 'ruff' tool via a Python package manager inside the CI script to copying a pre-built 'ruff' binary directly into the Docker lint image. It also moves the list of lint rules from the Rust test-runner source code into a dedicated configuration file called ruff.toml. There is no change to the actual Bitcoin node software, consensus rules, wallet handling, or network behavior. This is purely a tooling and configuration cleanup.

This change is a routine maintenance update to Bitcoin Core's internal linting (code style-checking) setup. It replaces one Python installation tool (pyenv) with another (uv) inside the CI lint container. There is no user-facing behavior change, no wallet or consensus code is touched, and no security vulnerability is present in the diff.

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 only updates developer documentation and adds a clarifying comment next to an existing code annotation. It does not change any executable code, network behavior, or security-sensitive logic.

This is a one-line documentation update inside a CI (continuous integration) helper patch. It changes a comment that points to a different version of an external tool's source file. There is no code change, no change to how Bitcoin Core runs, and no security relevance.

This commit changes the Bitcoin Core continuous integration (CI) test setup script. It adds a second Docker network with a fixed IPv4 address (1.1.1.5) and assigns a fixed IPv6 address (1111:1111::5) to the test container. The purpose is to enable two specific network-related functional tests that require predictable routable IP addresses. There is no user-facing software change and no security vulnerability is introduced or fixed.

This commit only changes Bitcoin Core's internal functional test scripts. It removes a manual command-line flag that testers had to pass to skip certain network-binding tests, and instead makes the tests automatically detect whether the required network addresses are available. It also adds a cleanup helper for test nodes that fail to start. There is no change to the Bitcoin node software that users run, no change to consensus rules, networking protocol, wallet handling, or any security-critical code path. It is purely a developer-facing testing improvement.

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 (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 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 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 change is a small internal cleanup in how Bitcoin Core prepares database writes. It reuses temporary memory buffers instead of repeatedly reserving and clearing them, and adds a helper to make sure those buffers are empty before and after each use. There is no direct evidence this fixes an active security bug; it is best described as defensive hardening or code-quality improvement.

This commit only adds new test cases for the database wrapper code. It checks that a database batch can be reused after being cleared, and that a database iterator can be seeked multiple times and recover from a failed value decode. There are no changes to production code, so this commit does not introduce or fix a security vulnerability by itself.

This commit adds a small helper class that wraps a temporary data buffer used internally by Bitcoin Core's database code. It makes sure the buffer is empty when use starts and clears it when use ends, and in debug builds it will crash the program if a buffer is accidentally reused while still in use. It is a defensive hardening change, not a fix for a known exploitable bug.

This commit fixes a bug where Bitcoin Core could crash on startup with a failed internal consistency check. The crash happened when a node had 'pruned' old block data while also having some header-only blocks, causing the program to incorrectly re-add pruned blocks to an internal list that is supposed to contain only blocks still stored on disk. The fix adds a check to skip pruned blocks when rebuilding that list during startup.

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.