Bitcoin Core

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 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 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 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 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.

This commit simply restores a copyright and explanatory comment block at the top of a source file. It is a documentation-only fix with no effect on program behavior, security, or network safety.

This commit only updates copyright header wording in two test files, changing '2024-Present' and '2022-' to '2022-present' for consistency. It does not change any executable code, network behavior, or security logic.

This commit updates the version of the Cap'n Proto library used in Bitcoin Core's build system from 1.2.0 to 1.3.0, along with its corresponding checksum. It is a routine dependency bump with no direct code changes to Bitcoin Core itself. There is no explicit security claim in the commit, and no verified references were provided to indicate this fixes a known vulnerability.

This commit only adds a new automated test file to Bitcoin Core. It checks that a node correctly tells its peers about its own external IP address after connecting and again later. There is no change to the actual Bitcoin network code, only new test code.

This commit is a documentation-only change for the Bitcoin Core RPC command `listtransactions`. The author noticed an unexpected behavior while testing another change and updated the help text so users can see it. No code behavior was changed, and there is no security fix or vulnerability here.

This commit only adds new test cases to a JSON test data file for Bitcoin Core's script validation tests. It does not change any production code, cryptographic checks, or network rules. The new tests verify that invalid public key formats are correctly rejected, which improves code coverage but introduces no security change by itself.

This change fixes a logic bug in Bitcoin Core's peer-to-peer block downloading. After a node finishes validating an 'assumeutxo' snapshot, it was still refusing to download blocks from peers whose best chain did not include the snapshot block—until the node was restarted. The fix removes that unnecessary restriction once validation is complete, allowing normal block downloads to resume. It is a network-efficiency and robustness fix rather than a direct theft-of-funds vulnerability.

This commit simply bumps the GitHub Actions 'checkout' step from version 5 to version 6 in the project's continuous integration (CI) workflow file. It does not change any Bitcoin Core source code, consensus rules, wallet logic, or network behavior. There is no indication of a security fix or vulnerability.

This commit is a routine tooling change for Bitcoin Core. It adds the clang-format package to a CI environment, runs clang-format after an automated include-sorting tool, and changes a formatting configuration option so that #include statements are regrouped and sorted. There is no change to the actual Bitcoin software logic, network behavior, or wallet handling, so it does not affect users' funds or node security.

This commit adds a new automated CI (Continuous Integration) job that runs a tool called Include What You Use (IWYU) to check that source files include only the headers they actually need. It also makes minor supporting changes: adding a CI configuration, installing the IWYU tool, adjusting build scripts, adding a mapping file for IWYU, and removing an unused <tuple> header from one source file. There is no change to Bitcoin Core's runtime behavior, consensus rules, networking, wallet logic, or any user-facing functionality. It is purely a code-quality and tooling improvement.

This is a one-character CMake build-system fix. The developer corrected the name of an internal test target from 'mptests' to 'mptest' so that automated testing (ctest) can find and run it. It has no effect on the Bitcoin network, wallets, consensus rules, or user-facing security.

This is a tiny CMake build-system change. It removes the EXCLUDE_FROM_ALL flag from a static library so that a code-generation target is built when needed. There is no indication this affects runtime security, wallet funds, network consensus, or user data.