Bitcoin Core

This commit removes a function called CheckPackageLimits that, according to the commit title and message, no longer did anything useful. The function body simply returned success without performing any checks, and callers were already using other mechanisms (like CheckPolicyLimits) for the relevant limits. This is a straightforward code cleanup with no apparent security impact.

This commit only changes a test file (miniminer_tests.cpp) so that existing unit tests still pass after a new mempool 'cluster limit' rule was introduced. It does not change any production code that runs on real Bitcoin nodes, so it cannot directly affect live network security or be exploited by attackers.

This Bitcoin Core commit reorders and reworks how two new transaction-handling features—RBF (Replace-By-Fee) and TRUC (a restricted version-3 transaction policy)—are validated. The main goal is to avoid doing expensive 'ancestor' calculations on the whole mempool until cheaper cluster-size checks have already run, so a maliciously crafted transaction can't waste a node's CPU as easily. It also makes sure the same RBF checks apply whether one transaction or a whole package is being accepted, and moves a 'spends a transaction it is replacing' check to a later, safer point.

This commit is a straightforward internal code cleanup in Bitcoin Core. It moves two helper functions—one that finds child transactions and one that finds parent transactions—from being methods on individual mempool entries to being methods on the mempool itself. The behavior is essentially the same; only the code organization and the caller syntax change. There is no indication this fixes a security bug or changes network behavior.

This commit fixes how Bitcoin Core counts the descendants of a special transaction type (TRUC) in the memory pool. Previously it looked only at direct children, which could miss deeper descendants introduced by blockchain reorganizations. The change makes the limit enforcement more accurate and adds a lock to prevent race conditions while checking the pool. It is a correctness and robustness improvement rather than a clear, exploitable vulnerability.

This commit simplifies how Bitcoin Core's memory pool (mempool) calculates the descendants of a transaction. It replaces a manual tree-walking routine with a call to a dedicated transaction graph component (m_txgraph). There is no direct evidence in the commit that this fixes a security bug; it appears to be a code cleanup or refactoring change.

This commit is a routine internal refactoring in Bitcoin Core's memory pool (mempool) code. It replaces one way of calculating transaction ancestors with a newer shared component called txgraph. The visible behavior for users and network peers should stay the same. There is no indication this fixes a security bug or introduces a vulnerability.

This commit is a routine code cleanup in Bitcoin Core's memory pool (mempool) logic. It removes error-handling paths from functions that calculate transaction ancestors, because a previous design change made those errors impossible. The commit does not introduce new behavior or fix a security bug; it simplifies the code after ancestor/descendant limits were removed elsewhere.

This commit simply moves a single internal helper function, removeConflicts, from the public section of a C++ class to the private section in the header file. It does not change what the function does, how it behaves, or any executable code. It is a routine encapsulation/cleanup change with no security effect.

This is a routine code cleanup in Bitcoin Core. It removes an unused 'limits' parameter from several mempool ancestor-calculation functions and their callers. The actual mempool policy limits are still enforced elsewhere, so this change does not alter network rules or introduce a security issue.

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 removes several read-only getter methods from Bitcoin Core's memory pool (mempool) transaction entry class and deletes the corresponding consistency checks in the mempool's internal validation routine. It is a code cleanup/refactoring change: the cached ancestor and descendant statistics are no longer exposed through public accessors, and the debug-only `check()` function no longer independently recomputes those statistics to verify them. There is no change to network behavior, consensus rules, or how transactions are accepted.

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