Bitcoin Core

This commit only adds new automated tests for an internal signal/slot library called btcsignals. It does not change any production code, fix a bug, or alter behavior visible to users or attackers. The tests are described by the author as preparation for a future replacement implementation.

This commit fixes a subtle startup bug in Bitcoin Core's RPC help system. Some help text for commands like 'decodepsbt' and 'getblock' was being built before all global constants were ready, which could cause crashes or garbled output when the program starts. The fix delays building that help text until it is actually needed. It is a reliability fix, not a remote attack vector.

This commit removes a compatibility workaround in Bitcoin Core's build system for older versions of GNU Make (before 4.2.90). It simplifies how the build scripts find compiler and toolchain programs. There is no security issue here; it is a routine cleanup that assumes users building for macOS, FreeBSD, or Windows are now on a newer version of Make.

This is a minor fix to a Bitcoin Core functional test script. It changes how test batch RPC requests are built so they work correctly when tests are run with the --usecli option. There is no change to production code, no security vulnerability, and no risk to real Bitcoin nodes or wallets.

This commit only adds a new automated test for the dumptxoutset RPC command. It checks that when the blockchain has a temporary fork, the snapshot is created at the requested rollback height rather than accidentally using the forked chain tip. There is no change to production code, no bug fix, and no security patch.

This commit adds a new optional 'in_memory' flag to the Bitcoin Core 'dumptxoutset' RPC command. When enabled, the temporary database used during rollback snapshot creation is kept in RAM instead of written to disk. This is a performance feature, not a security fix. There is no direct evidence in the commit that it addresses a vulnerability, and the change does not appear to introduce an obvious security flaw. The main risk is operational: a user could run out of memory if they enable this on mainnet without sufficient RAM.

This is a routine test-only change for a developer tool. It extends an existing functional test so that the utxo-to-sqlite helper tool is exercised with a 'rollback' snapshot instead of a 'latest' snapshot, and compares the result against the coinstats index. There is no change to production code, no wallet or node behavior change, and no security issue.

This commit changes how the Bitcoin Core 'dumptxoutset' RPC command creates snapshots of older UTXO sets. Previously, it temporarily invalidated a block to roll back the chain, which suspended network activity and could leave the node in a bad state if something went wrong. The new approach copies the UTXO set to a temporary database and rolls it back there, leaving the main chain untouched. It also uses a prune lock to prevent needed blocks from being deleted during the operation. This is a robustness and operational-safety improvement rather than a fix for a remote exploit.

This commit adds a new housekeeping function, DeletePruneLock, that lets Bitcoin Core remove a previously created 'prune lock' by name. Prune locks are internal bookkeeping markers that prevent certain block data from being pruned too early. The change also adds unit tests for the new function. There is no indication this fixes a bug or addresses a security issue; it appears to be a normal feature/refactoring addition.

This commit is a small internal code cleanup in Bitcoin Core's wallet database code. It removes a special 'mock' flag used only for testing and replaces it with a more general way to pass extra SQLite database options. The change only affects test helper code and how mock (in-memory) wallets are created during tests. There is no indication it fixes a security bug or introduces a security risk.

This commit changes only a benchmark test file used to measure wallet coin-selection performance. It swaps a manually created test chain for the standard TestingSetup helper and wraps the code in a wallet namespace. There is no change to production wallet code, consensus rules, networking, or any code that handles real user funds. It is a test-code cleanup with no security relevance.

This change fixes a bug in a benchmark test program, not in the main Bitcoin wallet that users run. The benchmark creates a fake wallet to measure how long migration takes, and the fake wallet's database helper object was not being closed before the migration step tried to close the database. That could make the benchmark crash or fail, but it does not affect real wallets or network security.

This commit is a test-only refactoring change. It replaces a custom in-memory fake database used in Bitcoin Core's automated tests with a real SQLite database running in memory. There is no change to how actual user wallets work, no bug fix for live code, and no security issue introduced or fixed.

This is a test-only code change. It refactors how a fake in-memory wallet database is copied during unit tests so that the copy uses the same cursor-and-batch interface a real database would use. There is no change to production wallet code, no user-facing behavior change, and no security fix or vulnerability.

This commit only changes documentation style guidance and moves or converts code comments. It does not alter any program logic, data handling, or network behavior, so it has no security impact.

This commit only removes a two-line comment (a TODO note) from the source code. No actual code behavior changes. The TODO had suggested a future improvement for handling rare compact-block short-ID collisions, but the developers decided the current behavior—failing early on collisions—is intentional and preferable. It is purely a documentation cleanup.

This commit removes a duplicate documentation marker (///@}) from a header file. It is purely a cosmetic documentation cleanup with no effect on program behavior or security.

This commit removes one line from a fuzz test file. Fuzz tests are automated tools that feed random inputs to functions to find crashes or bugs. The change simply stops calling the GetDescriptorChecksum function in this particular test, because other fuzz tests already exercise it more thoroughly. There is no change to any production code, no bug fix, and no security-relevant behavior change in the Bitcoin Core software itself.

This commit removes a compiler hint telling the destroy function it must never receive a null pointer. The change makes the function behave more like standard free(), which safely accepts null. It is a defensive API-consistency fix, not a fix for an active crash or exploit.

This commit only rewords two lint error messages and fixes a minor code-formatting import line. It does not change any runtime behavior, security checks, or executable code paths in Bitcoin Core. There is no security issue here.

This is a build-compatibility fix, not a security vulnerability in normal Bitcoin operation. It stops a specific compiler sanitizer (GCC's AddressSanitizer, used only in debug/test builds) from crashing when running SHA-256 self-tests on older CPUs that lack SHA-NI hardware support. The change does not affect production releases or how Bitcoin validates transactions.

This is a tiny quality-of-life change to a test helper. It only makes an error message clearer when a test fails, so developers can see exactly what text was produced. It does not touch Bitcoin's network code, wallet, consensus rules, or any code that runs in production.

This commit only changes the wording of error messages shown when bitcoin-cli fails to log in to the RPC server. It does not fix or introduce any security vulnerability; it is a user-experience improvement that tells users more precisely why authentication failed (missing cookie file, cookie disabled, bad cookie contents, or wrong password).

This commit is a simple code cleanup: it renames an internal status type from GenerateAuthCookieResult to AuthCookieResult and changes its value names to CamelCase. It also fixes a typo in a code comment where 'ERROR' was written as 'ERR'. No behavior of the Bitcoin RPC authentication cookie is changed.

This is a code cleanup change in Bitcoin Core. It changes how the program stores timestamps for the last time data was sent or received with a network peer, switching from raw second counts to proper clock time points. The commit message explicitly says this should not change behavior, and the diff shows equivalent conversions where the values are used. There is no indication of a security fix or vulnerability.