Bitcoin Core

This commit only changes the continuous integration (CI) setup scripts by removing the libevent library from the list of packages installed during automated testing. It does not modify any Bitcoin Core source code, runtime behavior, or network-facing logic. There is no security issue here.

This commit removes the libevent dependency from Bitcoin Core's vcpkg package manager configuration. It is a build-system cleanup change, not a security fix. The removed override was previously pinning an older libevent version to avoid a known build issue, but that issue is no longer relevant because libevent is no longer used via vcpkg at all.

This commit removes the libevent dependency from Bitcoin Core's build system ('depends'). It deletes the build recipe, patches, and references to libevent in makefiles and documentation. There is no direct code change to Bitcoin Core's runtime behavior, and nothing in the commit indicates a security vulnerability or fix. It is a build-maintenance change.

This commit only adds new automated tests for Bitcoin Core's wallet migration feature. It checks that when a wallet is migrated with the 'load_wallet=False' option, the wallet is not automatically loaded afterward, settings are updated correctly, and auxiliary wallet names are reported. There is no change to production wallet code, so this commit does not introduce or fix a security vulnerability on its own.

This commit adds a new optional 'load_wallet' argument to the 'migratewallet' RPC command in Bitcoin Core. It lets users choose whether the wallet should be automatically loaded after migration, defaulting to true to preserve existing behavior. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a usability or workflow improvement.

This commit only adds a release note describing a previously merged feature. It does not change any code, configuration, or behavior. There is no security issue in this commit itself.

This Bitcoin Core change lets users migrate old-style wallets to the newer descriptor format without automatically loading the migrated wallet afterward. The main goal is to support pruned nodes, which previously could not migrate because loading the wallet required full block history. The patch also removes the old wallet from the startup list when migration is done without loading. There is no obvious security bug here; it is a feature/robustness improvement.

This commit adds new test code to Bitcoin Core's fuzzing harness for the network connection manager. It exercises the AddLocalServices and RemoveLocalServices functions, which control what network service flags a node advertises. The change is purely a test/fuzzing addition and does not modify production code.

This commit only adds extra consistency checks (assertions) inside an existing fuzz test for Bitcoin Core's network connection manager. It does not change production code, network behavior, or wallet logic. There is no user-facing bug fix or security patch here.

This commit only changes a fuzz test file. Fuzz tests are automated tools that throw random inputs at code to find bugs. It adds checks that verify how Bitcoin Core's connection manager handles manually added nodes. There is no change to production code, no fix for a real vulnerability, and no security risk to users.

This commit removes mutexes (thread-safety locks) from two internal Bitcoin Core fuzz-test helpers. Fuzz tests are automated test harnesses, not production code, and the commit explains that the locks were unnecessary because fuzz targets run sequentially within a single process. There is no indication this change affects real Bitcoin Core users or introduces a security vulnerability.

This commit only changes a fuzz test (an automated testing harness) for Bitcoin Core's database wrapper. It reduces how many read operations each simulated worker thread performs during the test, which makes the test run faster, and increases the maximum number of database entries back to a previous value to keep test coverage. There is no change to production code, no user-facing behavior change, and no security fix.

This small change reorders two operations in the `importdescriptors` wallet command. Previously, the wallet first waited until it was caught up to the latest block, then tried to reserve a rescan. Now it reserves the rescan first, then waits to catch up. The likely goal is to prevent a race where another process starts a rescan in between those two steps, which could cause the import to proceed without the expected rescan or with conflicting rescan state. The practical security impact is limited and situational.

This commit removes the old libevent-based HTTP server code from Bitcoin Core and switches fully to a newer custom HTTP server implementation. It is a large cleanup/refactoring change, not a security patch. There is no indication in the commit or supplied references that this fixes a known vulnerability.

This commit removes support for the 'libevent' logging category in Bitcoin Core. It is a routine cleanup: the category is marked as deprecated, attempts to enable it are ignored with a warning, and it is excluded from the special 'all' logging flag. There is no security issue here.

This commit only adds a release note document describing a previous HTTP server rewrite. It does not change any code, configuration, or behavior. There is no security issue in this commit itself.

This commit adds helper methods to Bitcoin Core's HTTP request handling so that newer internal code can mimic the older libevent-based API. The main functional change is a new, more tolerant URL query-parameter parser. It replaces a strict libevent parser that would throw a runtime error on malformed percent-encoding with a custom parser that keeps going. The commit also adds tests showing the new parser accepts invalid percent signs that the old code rejected. This is mostly a compatibility/refactoring change, but the relaxed parsing could theoretically hide malformed input that downstream code did not expect.

This commit refactors how Bitcoin Core's built-in HTTP/RPC server is started and stopped. It adds new control functions (InitHTTPServer, StartHTTPServer, InterruptHTTPServer, StopHTTPServer) and makes shutdown more orderly by rejecting new requests, waiting briefly for clients to disconnect, and force-closing any stragglers. The changes are mostly structural and defensive, but because the code is new and touches network shutdown paths, there is some risk of subtle race conditions or incomplete cleanup if the ordering assumptions are wrong.

This commit adds an idle timeout for HTTP connections to Bitcoin Core's RPC server. Previously, clients could stay connected indefinitely even when doing nothing. Now, after a configurable period of inactivity (default 30 seconds via -rpcservertimeout), idle clients are disconnected. This is a defensive hardening change that reduces resource exhaustion risks from abandoned or maliciously held-open connections.

This commit replaces Bitcoin Core's long-standing libevent-based HTTP server with a new custom-built HTTP server. The change is architectural, not a targeted bug fix. It alters how the node parses and rejects HTTP requests, which could change which malformed requests are accepted or rejected. Because the new parser is fresh code handling network input, it introduces the possibility of new parsing bugs, request smuggling, or denial-of-service issues, but the diff itself does not contain an obvious exploit.

This commit updates a fuzz test—a special automated test that feeds random data to a piece of code to find bugs. The test previously used Bitcoin Core's old libevent-based HTTP request parser and worked around a known crash in that parser. The commit switches the test to use Bitcoin Core's newer internal HTTP request parser. This is a test-only cleanup and does not change the code that real Bitcoin nodes run to handle network traffic.

This commit finishes the Bitcoin Core HTTP server's ability to actually close client connections. Before, several error paths had 'TODO: disconnect' comments, meaning misbehaving or finished clients could stay connected longer than intended. The change adds flags and a periodic cleanup routine so the server drops clients after errors, oversized requests, malformed requests, EOF, non-keep-alive responses, and during shutdown. It is best read as a robustness/cleanup improvement rather than a single critical vulnerability fix, though leaving connections hanging can waste resources and, in some designs, be abused.

This commit changes how Bitcoin Core's built-in HTTP server sends replies. Previously, worker threads always queued response data and told the main I/O loop to send it later. Now, if the send buffer is empty, the worker tries to push data straight to the client socket immediately ('optimistic send'). To allow this safely across threads, one internal flag was changed to an atomic variable. The change is described by the author as a performance optimization, not a security fix.

This change reorders how Bitcoin Core's built-in web server handles multiple HTTP requests from the same connection. Previously, incoming requests could be handed off to worker threads as soon as they arrived, so a later, fast request might finish and send its response before an earlier, slower one. The patch queues requests per client and processes them strictly one at a time, ensuring responses are sent in the same order requests were received. The commit message frames this as preventing race conditions where a caller could receive stale state.

This commit is a simple code cleanup: it takes one function that did two jobs—reading RPC bind settings and actually opening network sockets—and splits it into two smaller functions. The behavior, settings, and warnings shown to users are unchanged. There is no security fix or vulnerability here.