Bitcoin Core

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.

This commit is a straightforward code cleanup: it moves the list of HTTP request methods (GET, POST, HEAD, PUT, UNKNOWN) out of a class and into a shared module-level type so two different parts of the codebase can use the same definitions. There is no security-relevant behavior change.

This is a pure code cleanup change. A single function that handles incoming HTTP requests was split into two functions: one that prepares the raw libevent request and wraps it, and another that performs the existing allow-checks and hands the request to worker threads. No behavior, security checks, or request handling logic was changed.

This commit adds support for HTTP 'chunked' transfer encoding to Bitcoin Core's built-in HTTP server. Before this change, the server only understood requests with a plain Content-Length body. The patch implements chunk-size parsing, chunk-extension handling, trailer skipping, and size limits. It also includes tests for valid, oversized, malformed, and delayed chunked requests. There is no direct evidence in the commit that this fixes a known security vulnerability, but adding chunked parsing is a sensitive network-facing change that could affect availability or request handling if implemented incorrectly.

This commit adds the ability for Bitcoin Core's built-in HTTP server to actually compose and send response messages back to connected clients. Previously, the server could read requests but had a placeholder 'TODO: send data' where replies should go. The change implements HTTP response formatting, buffering, and non-blocking socket sending, plus tests that verify a mock client receives a correct HTTP/1.1 reply. It is a normal feature-completion patch in an unfinished HTTP server refactor; there is no direct evidence it fixes a security bug, but any new network-facing code carries defensive-review interest.

This commit adds the ability for Bitcoin Core's new HTTP server to actually read incoming request data from connected clients. Previously, the server could accept connections but did not read what clients sent. The change is a normal feature addition with no security fix or vulnerability indicator visible in the code or commit message.

This commit only adds a new C++ class definition to a header file. It does not change any existing behavior, fix a bug, or alter how the program handles data. There is nothing here that would allow an attacker to exploit the software.

This commit is a routine internal refactor of Bitcoin Core's HTTP server. It moves connection-accepting logic into a dedicated background I/O thread, mirroring how the peer-to-peer network layer already handles sockets. There is no indication this fixes a security bug or introduces a known vulnerability; it is incremental feature work.

This commit adds a simple internal counter so each incoming HTTP connection can be assigned a unique sequential ID. It does not change any externally visible behavior, fix a bug, or close a security hole. It is a routine code-structure change.

This is a routine code-quality refactor. It changes an internal string-line reader to return lightweight string views instead of making full string copies. There is no security fix or behavior change visible in the commit.

This commit only moves existing HTTP server code into a new namespace called http_libevent. It does not change any behavior, fix any bug, or alter how the software handles network input. It is a pure code-organization change to make future replacements easier to review.

This commit introduces a new internal helper class for parsing and building HTTP headers in Bitcoin Core. It does not change any existing behavior or fix a known bug; it is purely new infrastructure code with tests. There is no indication this commit itself creates or fixes a security issue.