Bitcoin Core

This is a fix to a broken test in Bitcoin Core's own test suite. The test was supposed to check the heights of two chainstates after a simulated node restart, but an `if` condition was always false, so the check never actually ran. The commit also corrects the expected height value. It does not change any production code that runs on real Bitcoin nodes, so it cannot directly affect live network security.

This commit only changes comments and documentation in the Bitcoin Core source code. It renames terminology from 'background chainstate' to 'validated chainstate' in comments and updates the class description for ChainstateManager. No executable code was modified, so it cannot introduce a security vulnerability or fix one.

This commit is a straightforward internal code cleanup. It moves the logic that decides where the UTXO database files live from several scattered places into a single new Chainstate::StoragePath() method. There are no user-facing behavior changes, no bug fixes, and no security-related changes.

This is a code cleanup (refactor) in Bitcoin Core that changes how the program tracks whether a chainstate is based on an unvalidated snapshot (assumeutxo). It replaces a simple disabled flag with explicit state tracking. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a maintainability and correctness improvement.

This commit is a straightforward internal code cleanup in Bitcoin Core. It removes a helper method called GetAll() and replaces its uses with direct access to an internal list of chainstates. The change also adds a small safety check to ignore chainstates based on invalid snapshots when considering new block candidates. There is no indication this fixes an active security bug or introduces a vulnerability.

This commit is a code cleanup (refactor) in Bitcoin Core's assumeutxo snapshot feature. It renames functions and changes how the snapshot validation code receives its inputs, so it no longer relies on hardcoded internal chainstate names. The change does not alter the actual snapshot validation logic or security checks; it is preparation for future work to reduce how long a global lock is held during snapshot validation. There is no direct security vulnerability in this patch.

This is a code cleanup (refactor) change in Bitcoin Core. It replaces a three-value enum called ChainstateRole with a small struct carrying two yes/no flags: whether a chainstate is fully validated and whether it is historical (used for assumeutxo background validation). The logic that decides how wallets, indexes, and network processing react to block notifications is preserved; only the internal data type and comparisons are changed. There is no security fix or behavior change intended here.

This commit only adds documentation to a Guix installation guide. It explains that a specific Git setting called 'zdiff3' can cause Guix builds to fail, and tells users how to switch to a compatible setting. There is no code change and no security issue.

This commit is a documentation-only change in the Bitcoin Core repository. It updates the Guix installation guide to suggest using the official uninstall flag when removing Guix. There is no change to any code that runs the Bitcoin network, wallet, or node software, and no security vulnerability is introduced or fixed.

This commit removes a spelling-check tool (codespell) from Bitcoin Core's automated linting setup. It deletes the lint-spelling.py script, its word-ignore list, and the codespell dependency from CI install scripts. There is no change to the actual Bitcoin node software, wallet logic, networking, or consensus code. It is purely a cleanup of developer tooling.

This commit adds a new menu item in the Bitcoin Core desktop program that lets a user pick an old wallet backup file and restore it, then automatically convert ('migrate') it to the newer wallet format. It is a user-facing feature addition, not a fix for a security bug. There is no indication in the commit that it addresses a vulnerability.

This commit adds a new GUI feature that lets a user restore a wallet backup file and then automatically convert it from the older 'legacy' wallet format to the newer 'descriptor' wallet format. It shows confirmation and progress dialogs, copies the backup into the normal wallets folder without changing the original file, and then runs the existing migration logic. There is no obvious security bug in the change itself; it is a user-facing convenience feature built on top of existing wallet restore and migration code.

This commit is a small, non-security code cleanup. It exposes an existing internal option called load_after_restore through the wallet interface so that callers can choose whether a restored wallet should be loaded automatically. The GUI code is updated to pass true, preserving the previous behavior. There is no indication this fixes a vulnerability or introduces a security risk.

This commit is a simple code cleanup in the Bitcoin Core graphical wallet. It takes the actual wallet-migration steps out of the user-facing 'migrate' function and puts them into a new internal helper function called 'do_migrate'. The user confirmation dialog and the migration logic itself are unchanged; the code is just reorganized so the same migration steps can be reused later. There is no security issue visible here.

This commit fixes a Bitcoin Core bug where the database cache (dbcache) was not being periodically saved to disk during the 'reindex-chainstate' operation. The intended behavior was to flush the cache roughly every hour to avoid losing progress if the system crashed. Because the flush only happened after reaching the tip, users running reindex-chainstate with a large dbcache could lose many hours of work on a crash. The patch moves the periodic flush inside the main loop so it actually occurs during reindexing, initial block download, and normal operation. It is a reliability/durability fix, not a remote-exploitable security vulnerability.

This commit adds a new read-only REST API endpoint that lets users fetch a specific slice of bytes from a stored Bitcoin block, similar to reading a portion of a file. It does not change how blocks are written or validated, and it does not expose any private wallet data. The main security consideration is that it adds another network-facing path that reads raw block files, so any bug in parsing the request or reading the file could affect node availability or leak block data. The code appears to validate the offset and size parameters and returns errors for invalid or out-of-range requests.

This commit refactors how Bitcoin Core reads raw block files from disk. Previously, the ReadRawBlock() function returned true/false and filled a caller-provided buffer. Now it returns a structured result that distinguishes I/O errors from success. The main observable security-relevant change is in the REST API: when a block cannot be read from disk due to an I/O problem, it now returns HTTP 500 (Internal Server Error) instead of HTTP 404 (Not Found). This is a correctness improvement that reduces the chance an attacker can trick the node into revealing whether a pruned block existed, but it is not a fix for an active vulnerability.

This commit adds a new feature to Bitcoin Core that lets the node read only a slice of a stored block (a specific byte range) instead of the whole block. It is meant to support future REST API improvements for fetching specific transactions. The commit includes careful range checks and avoids logging invalid requests to prevent log spam. There is no direct evidence in the commit that this fixes an active security bug, but it does touch untrusted REST input handling, so defensive care is warranted.

This commit only changes test code. It updates two unit tests for the merkle-root calculation helper: one fuzz test now moves its input vector instead of copying it, and another test now uses an odd number of transactions and witness hashes to better match real production behavior. There are no changes to the actual Bitcoin Core consensus or networking code, so this cannot directly affect live node security.

This is a one-line change to a fuzz test file. It expands test coverage so that the fuzzer sometimes passes a null pointer to a function that computes Merkle roots, exercising a code path that previously wasn't tested. It does not change any production code, consensus rules, or network behavior.

This is a small, clean code-quality change that adds a standard-style accessor method to a utility class. It does not fix a bug, close a security hole, or change any behavior that external users can reach. There is no security relevance.

This commit only changes test code to use a different style of comparison check. It does not alter any production code, network behavior, or wallet logic, and has no security relevance.

This commit is a code-style and static-analysis configuration change. It tells the clang-tidy linter to allow discarding function return values when the call is explicitly cast to void, and updates a few places in benchmark, test, and HTTP server code to use that style instead of a temporary variable marked 'maybe unused'. There is no security-relevant behavior change.

This commit updates the Boost dependency used by Bitcoin Core's build system from version 1.88.0 to 1.90.0. It also removes a custom patch that was previously needed to skip compiling certain Boost.Test libraries, because the newer Boost version now includes that functionality directly. There is no indication in the commit that this fixes a security vulnerability.

This commit fixes a test-support script that downloads old Bitcoin Core releases. Previously, if a download was cut short (for example by a network error), the script would silently keep the incomplete file. Now it checks whether the downloaded bytes match the expected size and throws an error if they don't. This is a reliability fix in a developer/test tool, not a direct security fix in the Bitcoin software users run.