Bitcoin Core

This commit removes old bookkeeping code in Bitcoin Core's transaction memory pool (mempool) that tracked the cumulative size, fees, and counts of related transactions (ancestors and descendants). The project is moving this responsibility to a newer component called txgraph. The removed functions are left as empty stubs, meaning they no longer do anything. On its own, this is a cleanup/refactoring change, not a direct security fix, but it alters internal accounting that other parts of the mempool rely on. Without seeing the txgraph replacement and the rest of the surrounding work, it is hard to tell whether any edge cases in fee/size accounting could be affected.

This commit removes several unused internal accounting fields from Bitcoin Core's memory pool transaction entry class. It is a straightforward code cleanup: fields that tracked descendant and ancestor transaction sizes, fees, and counts are deleted, and the methods that updated them are left empty. There is no security-relevant change visible in the diff.

This commit refactors how Bitcoin Core's mempool counts transaction ancestors and descendants. It replaces some uses of internally cached counts with freshly calculated counts from a newer transaction graph structure. The change is mostly cleanup and test adaptation, but it touches the TRUC (v3 transaction) policy rules that limit how many related transactions can be in the mempool. There is no clear security bug fixed here, but the change is in a security-sensitive area (mempool policy), so it deserves careful review.

This commit is a code cleanup in Bitcoin Core's transaction memory pool (mempool). It swaps one internal measurement—'maximum descendants'—for a newer equivalent called 'cluster count' after an older size limit was removed. The change is mostly renaming and updating tests to match; it does not appear to fix a security bug or introduce an obvious vulnerability.

This commit simply deletes a private helper function called CalculateDescendantMaximum from Bitcoin Core's memory pool code because nothing in the program was using it anymore. It is a routine cleanup change with no visible security effect.

This commit removes a special Bitcoin mempool rule that gave a small exception (a 'carve out') for single-conflict RBF replacements. The change is part of a broader redesign called 'cluster mempool' and is described by the developer as making the old carve-out obsolete, not as a security fix. It tightens policy enforcement slightly but does not appear to introduce a vulnerability.

This is a routine internal code cleanup in Bitcoin Core. It replaces one way of checking whether a transaction in the memory pool has dependent ('descendant') transactions with another, newer mechanism. There is no indication this fixes a security bug or introduces a vulnerability.

This commit changes how Bitcoin Core counts a transaction's ancestors in the memory pool (mempool). Previously it read pre-calculated cached numbers stored with each transaction; now it recalculates them on demand by walking the transaction graph. The change is described by the project as a refactoring step to remove cached ancestor data from mempool entries. There is no direct evidence in the commit that this fixes a security vulnerability.

This commit only adds a new test case to Bitcoin Core's test suite. It checks that existing mempool cluster-size and cluster-count limits also apply to TRUC (version 3) transactions. There is no code change to the actual Bitcoin Core node software, so it cannot directly introduce, fix, or exploit a security issue in running nodes.

This commit simply removes one test case from a Bitcoin Core functional test file. It does not change any production code, network rules, or wallet behavior. There is no indication this is a security fix.

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 Bitcoin Core change alters how mempool RPC calls (such as getrawmempool and getmempoolentry) report ancestor data. Previously, the node reused cached ancestor statistics stored with each transaction. Now it recalculates those numbers from scratch every time the RPC is called. The likely reason is that the cached ancestor values can become stale or inconsistent after certain mempool operations, which could cause RPC responses to show incorrect counts, sizes, or fees for a transaction's chain of unconfirmed ancestors. There is no direct evidence in the commit of an exploitable security vulnerability, but inconsistent mempool accounting can mislead wallets, fee estimators, or monitoring tools.

This commit changes how Bitcoin Core calculates and reports descendant transaction information in mempool RPC output. Previously, descendant counts, sizes, and fees were read from cached values stored on each mempool entry. Now they are computed on-the-fly by walking the descendant graph. The change is described by the project as preparation for removing cached descendant state. There is no direct evidence in the commit or supplied references that this fixes a security vulnerability; it appears to be a refactoring and consistency change.

This Bitcoin Core commit removes enforcement of two older mempool limits—how many child transactions and how much total data can descend from a single transaction—and relies instead on newer 'cluster' limits. The change is described by the project as a simplification, not a security fix. It could alter how large transaction chains are rejected, but the diff itself does not show a vulnerability or emergency patch.

This commit removes Bitcoin Core's old 'ancestor count/size' mempool limits, leaving only newer 'cluster' and 'descendant' limits. The change is intentional and part of a broader mempool policy simplification. It does not by itself create a known exploit, but it changes what transaction shapes are allowed into the mempool. A miner or node operator relying on the old ancestor limits now has different protections, which could matter if the remaining cluster limits are weaker in some edge cases.

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