Bitcoin Core

This commit only updates a copyright notice in a single test file, changing the year range from '2020-2022' to '2020-present'. There is no code change, no functional change, and no security relevance.

This commit simply deletes a helper script used to manage copyright headers in source files, along with its documentation. It does not change any part of the Bitcoin Core software that handles transactions, networking, wallets, or consensus rules. There is no security issue here.

This commit is a code cleanup in Bitcoin Core's RPC (remote procedure call) response formatting. It removes many old-style C-style casts like (int64_t) and replaces them with either no cast or a safer static_cast. The change is described by the authors as a refactor to make the code less confusing and brittle. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability.

This commit fixes a bug in Bitcoin Core's mempool RPC output where fee values were incorrectly narrowed to 32-bit integers before being displayed. For very large fee bumps (over about 86 bitcoins), this cast could corrupt the reported 'chunkfee' and 'fees.chunk' values, making them look much smaller or even negative. The fix removes the unnecessary casts and adds a test for large fee deltas. It is a correctness bug in information shown to users and miners, not a direct theft-of-funds vulnerability.

This commit simply renames a function from getCoinbaseTx() to getCoinbaseRawTx() across the codebase, including documentation, interface definitions, IPC protocol files, implementation, and tests. It is a preparatory refactoring change with no functional or security impact.

This is a one-line type change in Bitcoin Core's fee estimation data reader. It changes two local variables from 'size_t' (whose size varies by platform) to 'uint64_t' (a fixed 64-bit type) when reading the fees.dat file. The stated purpose is to make a serialization corruption check more consistent across platforms. There is no direct evidence in the commit of an exploitable vulnerability, and the change appears defensive/refactoring in nature.

This commit is a straightforward build-compatibility fix. It replaces two newer Boost library function calls (`contains`) with older, equivalent alternatives (`find == end` and `count`) so Bitcoin Core can compile against Boost versions older than 1.78.0. There is no change to program logic, behavior, or security.

This commit is a code cleanup that replaces old-style container lookups like `.count()` with the newer, clearer `.contains()` method introduced in C++20. It also turns on a linting rule to keep future code consistent. There are no functional changes and no security impact.

This commit changes how Bitcoin Core orders transactions when grouping them into blocks or processing clusters. Previously, when several transaction groups had the same fee rate and no dependencies, the order was predictable based on internal data structures. Now the order is randomized. The stated goal is to hide information about the order in which transactions were inserted into the system, improving privacy by making it harder for observers to infer internal state from the final output.

This commit swaps out Bitcoin Core's old mempool cluster linearization algorithm (LIMO) for a new one called SFL (spanning-forest linearization). The change is described as a performance improvement, not a security fix. It removes a lot of old search-based code and tests, and temporarily relaxes one test assertion because the new algorithm does not yet guarantee the smallest possible number of chunks even when it finds an optimal ordering. The production code now always runs an extra post-processing step to keep chunks connected.

This commit is a routine internal refactoring of Bitcoin Core's transaction-cluster linearization algorithm. It replaces a loop that scans all transactions with a FIFO queue of 'chunks' that might still be improvable. The change is described by the author as preparation for future randomization, a fairness improvement, and a performance optimization. There is no indication in the commit or supplied references that this fixes a security bug or is security-relevant.

This commit simply removes an unused helper function called MergeLinearizations, along with its benchmark and fuzz test. It is a routine code cleanup with no security relevance.

This commit is a routine internal code cleanup in Bitcoin Core's transaction graph (mempool) linearization logic. It removes a more complex class (LinearizationChunking) that supported incremental updates and replaces it with a simpler function (ChunkLinearizationInfo) that computes chunk information once. There is no indication of a security bug, vulnerability, or behavior change affecting users or the network.

This commit adds randomness to an internal Bitcoin Core algorithm that orders groups of related transactions (clusters) for block inclusion. The goal is to prevent someone from deliberately crafting a cluster of transactions that would always trigger the worst-case performance of the algorithm. It is a hardening/performance improvement, not a fix for a vulnerability that steals funds or breaks consensus.

This commit adds a new feature to Bitcoin Core's internal transaction-cluster linearization code. It lets the algorithm start from an existing ordering of transactions rather than building one from scratch. The change is purely an optimization/feature addition in mempool policy code and does not alter network rules, consensus, or wallet behavior. There is no indication it fixes a security bug.

This is a small internal cleanup of Bitcoin Core's fuzz testing code. It refactors how test inputs are converted into arbitrary orderings of transactions, with no change to production consensus or networking code. There is no security issue visible in the commit.

This commit adds a new internal data structure and algorithm implementation for optimizing how Bitcoin Core orders groups of related transactions (clusters) when building blocks. It is purely preparatory code: it introduces the new 'spanning-forest linearization' state class and a fuzz test to verify its correctness, but it does not yet wire it into the actual block-building path. There is no indication this change fixes or introduces a security vulnerability.

This commit simply raises the minimum required Boost library version from 1.73.0 to 1.74.0 because building with 1.73.0 is broken. It is a build-system/dependency documentation change, not a fix for a security vulnerability in Bitcoin Core itself.

This commit adds new unit tests for Bitcoin Core's transaction-cluster linearization code. It does not change any production (non-test) code, network behavior, or consensus rules. The tests verify that the linearization algorithm produces known-optimal results on a large set of real and synthetic mempool cluster examples. There is no security-relevant change here.

This commit only changes benchmark tests and adds a small helper function to count transaction dependencies. It does not alter how Bitcoin Core processes real transactions or network messages, so it has no direct security impact on running nodes.

This commit adds a command-line flag to an experimental developer/testing tool so it can use Bitcoin's local-only 'regtest' network instead of the real main network. It is a straightforward feature addition with no security relevance.

This commit adds a new automated test for the bitcoin-chainstate tool. It checks that the tool can load a data directory initialized with an assumeutxo snapshot and continue processing new blocks. There is no change to production code that handles user funds, network messages, or consensus rules, and no security fix is present.

This is a one-line fix in Bitcoin Core that prevents a program crash (assertion failure) when adding a new chainstate. The crash could occur if the previous chainstate did not have a memory pool (mempool) initialized. The change simply checks whether the mempool exists before checking its size, avoiding an invalid memory access. It is a defensive hardening fix rather than a user-triggerable exploit path under normal operation.

This commit only adds standard copyright notice comments to the top of two test-only source files. It makes no changes to program logic, data handling, or network behavior, and therefore has no security relevance.

This commit simply adds a standard copyright and license notice to the top of a generated source file. It is a legal/documentation change, not a security fix or code behavior change.