Bitcoin Core

This commit only adds a new automated test for Bitcoin Core's Tor control feature. It checks that the program safely disconnects when a mock Tor server sends an extremely long response line. There are no changes to the actual Bitcoin Core program code, only to the test file.

This commit improves a fuzz test for Bitcoin Core's Tor control code and adds a small safety check in the real Tor control logic. The production change guards against an empty reply from Tor during the SAFECOOKIE authentication challenge, preventing a potential out-of-bounds read or crash. The rest of the change is test cleanup and expanded fuzzing coverage.

This commit is a straightforward internal code cleanup: it moves the Tor controller object from a single global variable into the per-node context structure. There is no change in user-facing behavior, no bug fix, and no security-relevant change visible in the diff.

This commit only adds a new automated test that simulates a Tor control server and checks that Bitcoin Core talks to it correctly. It does not change any production code, so it cannot introduce a security vulnerability or fix one.

This commit only adds a new automated test for Bitcoin Core's Tor control feature. It checks that the software correctly waits for a complete message before acting, rather than reacting to a partial message. There is no change to the actual Bitcoin Core program code that users run.

This commit only adds new automated tests for Bitcoin Core's Tor control feature. It checks that when creating a hidden service, the software requests a modern anti-DoS feature (proof-of-work defenses) and gracefully falls back if the Tor daemon does not support it. No production code is changed, so this cannot introduce a security vulnerability or fix one directly.

This commit rewrites how Bitcoin Core talks to the Tor control port. It replaces the libevent networking library with Bitcoin Core's own simpler socket wrapper and a dedicated control thread. The change is a refactor: it removes one external dependency and makes the code easier to test and reason about, but it also introduces new socket-handling code that must correctly manage reconnects, timeouts, partial reads, and shutdown. There is no direct evidence in the commit or supplied references that this fixes a known security bug, but any rewrite of network code carries a small risk of introducing subtle bugs.

This is a small internal code cleanup in Bitcoin Core's custom signal/slot system. It merges two separate shared pointers (one tracking whether a callback is still active, and one used as a construction tag) into a single shared pointer. There is no user-facing change, no bug fix, and no security-relevant behavior change visible in the diff.

This commit simply removes a temporary build dependency on Boost headers from two internal build targets. It is a cleanup change with no visible security relevance.

This is a routine code cleanup commit. It replaces a full header include with a simple forward declaration in two interface header files. There is no security-relevant change and no indication of a vulnerability being fixed.

This commit replaces Bitcoin Core's use of the Boost signals2 library with a new, simplified in-house implementation called btcsignals. It is a code refactoring/reimplementation intended to reduce dependency on Boost. The change itself does not fix a known bug or vulnerability, but any reimplementation of a threading/callback mechanism carries risk of introducing subtle concurrency or lifetime bugs.

This is a small cleanup of a test file. It removes version-specific workarounds for older Boost library versions, keeping only the behavior needed for the newest Boost version. There is no security issue here.

This commit simply removes an unused software component (Boost.Signals2) from two dependency lists used to build Bitcoin Core. It is a cleanup change, not a security fix.

This commit is a routine cleanup of documentation and a linting script. It updates an example in the developer notes to reference the project's own signal library (btcsignals) instead of the old Boost signals2 library, and removes three Boost signals2 header paths from the list of expected Boost includes checked by a linter. There is no code behavior change and no security relevance.

This is a routine build cleanup. A developer removed two leftover references to the Boost C++ library from the project's build instructions because those parts of the code no longer use Boost. There is no security issue here.

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.