Bitcoin Core

This small code change updates an internal Bitcoin mining-simulation tool so it calculates ancestor transaction data on the spot rather than relying on a precomputed cache. The change appears aimed at preventing the mini-miner from using stale or incorrect cached values, which could lead to wrong fee estimates when simulating which transactions to include in a block. There is no direct evidence in the commit that this fixes an active security vulnerability, but it removes a dependency that could produce inconsistent results.

This commit changes the order in which Bitcoin nodes announce pending transactions to peers. Previously, transactions were announced based on how many ancestor transactions they had, then by fee rate. Now they are announced using the same 'cluster linearization' order the mining code uses, so higher-fee transactions are relayed first while still respecting dependency order. The change also updates a test that depended on the old ordering. There is no indication this fixes a security vulnerability; it is a behavior refinement.

This is a test-only code change. It fixes a helper function used by Bitcoin Core's internal test suite so that the fake transactions it creates no longer accidentally break the simulated mempool's own rules. It does not change any production code that runs on real Bitcoin nodes, so it cannot affect real users or the live network.

This commit removes a special Bitcoin mempool rule called the 'CPFP carve-out' that previously let one small extra transaction squeeze into an otherwise-full chain of unconfirmed transactions. The change is intentional policy cleanup, not a security fix, because a newer 'cluster size limit' already blocks the same bypass path. Some payment-channel-like protocols that relied on this carve-out may need to adjust, but the commit itself does not introduce a code vulnerability.

This commit rewrites how Bitcoin Core decides whether a transaction can replace existing mempool transactions via RBF (Replace-By-Fee). It removes two old rules—'no new unconfirmed inputs' and 'replacement must pay a higher per-transaction feerate than each conflict'—and replaces them with a stricter economic test: the replacement must improve the mempool's overall feerate diagram. It also changes the limit on how many transactions can be replaced from a raw count of transactions to a count of distinct transaction clusters. The change is a deliberate policy redesign, not a bug fix, and the tests are updated to match the new behavior.

This commit refactors how Bitcoin Core's mempool sorts transactions for internal consistency checks and information reporting. It replaces an older sorting method based on 'ancestor count' with a newer topology-aware method that relies on the recently introduced mempool graph/linearization code. The change is a code cleanup and architectural simplification, not a fix for an active security bug. A new assertion is added to ensure the mempool graph is not oversized when this sorting is used for the consistency check.

This commit removes two internal sorting indexes from Bitcoin Core's memory pool (mempool) data structure. It is a code cleanup/refactoring change: the ancestor_score and descendant_score indexes are no longer needed because their jobs have been taken over by a newer transaction graph module (m_txgraph). The commit also deletes the unit tests that exercised those old indexes and adjusts a memory-usage estimate to reflect fewer indexes. There is no indication in the commit or supplied references that this fixes a security bug.

This commit adds two new command-line options, -limitclustercount and -limitclustersize, and corresponding data fields for mempool limits. However, the commit title and code make clear these new limits are currently unused: no enforcement logic consumes them. It is purely preparatory infrastructure for future mempool policy changes. There is no immediate security impact.

This commit refactors how Bitcoin Core selects transactions for new blocks. It replaces an older, more complex ancestor-feerate algorithm with a new 'chunk feerate' approach driven by a new mempool graph builder. The change is a significant rewrite of mining transaction selection logic, but the commit itself does not describe any security bug or fix. Because it is a large behavioral change in consensus-adjacent code, it carries ordinary implementation risks, but there is no direct evidence in the commit of a vulnerability.

This commit changes only a benchmark test file used to measure mempool performance. It rewrites how fake transactions are generated so the test creates many small independent groups instead of one huge interconnected cluster. There is no change to the actual Bitcoin network code that users run, so this cannot affect real funds, nodes, or network security.

This Bitcoin Core commit changes how the mempool (the waiting area for unconfirmed transactions) decides which transactions to kick out when it gets too full. Previously it used 'descendant feerate'; now it uses 'chunk feerate' so that the transactions a miner would pick last are the same ones the mempool evicts first. This is a consistency improvement in transaction selection policy, not a fix for a clear exploit. The change could affect transaction propagation, fee estimation, and mempool behavior under load, but the commit itself does not describe any security vulnerability.

This commit only changes Bitcoin Core's internal unit tests. It rewrites how the miner_tests create large transaction clusters so the tests no longer need an unusually large mempool cluster-size limit. There is no change to production code, consensus rules, network behavior, or wallet handling, so it does not affect real users or the live Bitcoin network.

This Bitcoin Core patch tightens a wallet safety check. The '-walletrejectlongchains' option is meant to stop a user's own wallet from creating long chains of unconfirmed transactions, which can be hard to get mined. The old code only checked the size of the transaction package, but did not check the newer 'cluster' limits that count related transactions more broadly. The fix adds a cluster-limit check before the package-size check, so the wallet now rejects transactions that would violate current mempool policy. This is a defensive correctness fix; it mainly protects users from creating transactions that the network would currently refuse to relay or mine.

This commit only changes Bitcoin Core's functional test suite. It reworks and deletes some Replace-By-Fee (RBF) tests that previously needed very large transaction clusters. The production mempool rules are not modified, and no security vulnerability is present in the commit.

This is a minor test-only change in Bitcoin Core's functional test suite. It adds a constant and changes one test variable from 100 to 64 in preparation for future mempool work. It does not modify any production code, consensus rules, or network behavior, and presents no security issue.

This commit is a step in a larger Bitcoin Core project to replace the mempool's internal transaction graph with a new component called TxGraph. The change starts tracking every mempool transaction inside TxGraph, but deliberately ignores parent-child dependencies between transactions, treating each one as if it were isolated. It also restructures how mempool locks are held during transaction acceptance so the new graph can be updated consistently. There is no claim in the commit that this fixes a security bug; it reads like an incremental refactor or feature-in-progress.

This commit removes a fuzz test that compared two internal Bitcoin components (MiniMiner and BlockAssembler) to ensure they built the same block. The test is being deleted because an upcoming code change ('cluster mempool') will make their outputs intentionally differ. This is a test-only cleanup, not a fix for a security bug.

This Bitcoin Core commit enforces a new mempool policy: groups of related unconfirmed transactions ('clusters') are now capped by configured size and count limits. Previously these limits existed as settings but were not fully enforced by the new in-memory transaction graph. The patch wires the limits into the graph, rejects submissions that would exceed them, and removes transactions from the mempool when a newly accepted block creates oversized clusters. It also reorders some validation checks so cluster-size rejection happens before certain standardness checks, which is why one functional test was temporarily adjusted.

This commit only adds documentation to the CI README explaining how to set up QEMU user-mode emulation for running tests on foreign CPU architectures. It is a pure documentation change with no code modifications, no security fixes, and no functional changes to Bitcoin Core.

This commit only updates a documentation file (ci/README.md) to explain more clearly why the CI system should be run inside a clean environment using the `env -i` command. It does not change any code, build scripts, or configuration that could affect Bitcoin Core's runtime security. There is no vulnerability or security fix here.

This commit changes a single formatting setting in Bitcoin Core's code style configuration file. It tells the clang-format tool to automatically add a blank newline at the end of source files when it runs. This has no effect on how the software runs, what data it processes, or its security. It only affects whitespace in source code files.

This commit is a documentation-only change for Bitcoin Core. It adds comments explaining how PSBT (Partially Signed Bitcoin Transaction) data is read from serialized bytes, with no changes to actual code behavior. The surrounding merge commit also includes a very large number of unrelated file additions (build files, templates, docs, etc.), but the titled change itself is purely explanatory comments.

This commit simply removes an unused local variable from a single function in Bitcoin Core's networking code. There is no functional change, no bug fix, and no security relevance.

This commit simply moves a chunk of Python code from inside a GitHub Actions workflow file into its own separate Python file. The code that runs is unchanged; only its location changed. There is no security issue here.

This is a test-only change. It removes unit tests that created a std::span from a null pointer with a non-zero length, which is undefined behavior and now trapped by hardened std::span implementations. The production code is not changed, and no vulnerability in live Bitcoin Core is introduced or fixed here.