mirror of
https://github.com/bitcoin/bitcoin.git
synced 2026-03-18 19:40:40 +01:00
87ab69155d
1632fc104btxgraph: Track multiple potential would-be clusters in Trim (improvement) (Pieter Wuille)4608df37e0txgraph: add Trim benchmark (benchmark) (Pieter Wuille)9c436ff01ctxgraph: add fuzz test scenario that avoids cycles inside Trim() (tests) (Pieter Wuille)938e86f8fetxgraph: add unit test for TxGraph::Trim (tests) (glozow)a04e205ab0txgraph: Add ability to trim oversized clusters (feature) (Pieter Wuille)eabcd0eb6ftxgraph: remove unnecessary m_group_oversized (simplification) (Greg Sanders)19b14e61eatxgraph: Permit transactions that exceed cluster size limit (feature) (Pieter Wuille)c4287b9b71txgraph: Add ability to configure maximum cluster size/weight (feature) (Pieter Wuille) Pull request description: Part of cluster mempool (#30289). During reorganisations, it is possible that dependencies get added which would result in clusters that violate policy limits (cluster count, cluster weight), when linking the new from-block transactions to the old from-mempool transactions. Unlike RBF scenarios, we cannot simply reject the changes when they are due to received blocks. To accommodate this, add a `TxGraph::Trim()`, which removes some subset of transactions (including descendants) in order to make all resulting clusters satisfy the limits. Conceptually, the way this is done is by defining a rudimentary linearization for the entire would-be too-large cluster, iterating it from beginning to end, and reasoning about the counts and weights of the clusters that would be reached using transactions up to that point. If a transaction is encountered whose addition would violate the limit, it is removed, together with all its descendants. This rudimentary linearization is like a merge sort of the chunks of the clusters being combined, but respecting topology. More specifically, it is continuously picking the highest-chunk-feerate remaining transaction among those which have no unmet dependencies left. For efficiency, this rudimentary linearization is computed lazily, by putting all viable transactions in a heap, sorted by chunk feerate, and adding new transactions to it as they become viable. The `Trim()` function is rather unusual compared to the `TxGraph` functionality added in previous PRs, in that `Trim()` makes it own decisions about what the resulting graph contents will be, without good specification of how it makes that decision - it is just a best-effort attempt (which is improved in the last commit). All other `TxGraph` mutators are simply to inform the graph about changes the calling mempool code decided on; this one lets the decision be made by txgraph. As part of this, the "oversized" property is expanded to also encompass a configurable cluster weight limit (in addition to cluster count limit). ACKs for top commit: instagibbs: reACK1632fc104bglozow: reACK1632fc104bvia range-diff ismaelsadeeq: reACK1632fc104b🛰️ Tree-SHA512: ccacb54be8ad622bd2717905fc9b7e42aea4b07f824de1924da9237027a97a9a2f1b862bc6a791cbd2e1a01897ad2c7c73c398a2d5ccbce90bfbeac0bcebc9ce