Page MenuHomePhabricator

[mempool] check ancestor/descendant limits for packages

Authored by PiRK on Oct 6 2022, 09:33.


Group Reviewers
Restricted Project
rABC97b9dbb0e79c: [mempool] check ancestor/descendant limits for packages

[refactor] pass size/count instead of entry to CalculateAncestorsAndCheckLimits

This does not change existing behavior.
The ancestor/descendant limits are inclusive of the entries themselves,
but CalculateAncestorsAndCheckLimits() does not need access to them.

[mempool] check ancestor/descendant limits for packages

When calculating ancestor/descendant counts for transactions in the
package, as a heuristic, count every transaction in the package as an
ancestor and descendant of every other transaction in the package.

This may overestimate, but will not underestimate, the
ancestor/descendant counts. This shortcut still produces an accurate
count for packages of 1 parent + 1 child.

[policy] ancestor/descendant limits for packages

[test] helper function to increase transaction weight

Use our existing pad_tx function.

[test] parameterizable fee for make_chain and create_child_with_parents

[test] mempool package ancestor/descendant limits


  • tx.rehash() replaced with tx.get_id()
  • used helper functions ToHex and FromHex. tx_from_hex is not available due to missing backports.
  • our limit for number of transactions in a package is 50. This leads to some minor logical differences in the tests, because where Core uses 24 transactions (an even number) we use 49 (an odd number). This leads to some asymetric chain transactions branches where the source material has symetric branches, and vice-versa.

This concludes backport of core#21800

Test Plan

ninja all check-all

Diff Detail

rABC Bitcoin ABC
Lint Not Applicable
Tests Not Applicable

Event Timeline

PiRK requested review of this revision.Oct 6 2022, 09:33
PiRK edited the summary of this revision. (Show Details)
Fabien requested changes to this revision.Oct 6 2022, 14:41
Fabien added a subscriber: Fabien.

Mostly a sum of nits

752 ↗(On Diff #35468)

update the doc with a more relevant example (50)

759 ↗(On Diff #35468)
763 ↗(On Diff #35468)
83 ↗(On Diff #35468)

nit: res["allowed"] is True

87 ↗(On Diff #35468)
99 ↗(On Diff #35468)
99 ↗(On Diff #35468)

See nits below, but generally these comments are useless as they add no value, better use named args for the same doc and a single place to maintain

101 ↗(On Diff #35468)
186 ↗(On Diff #35468)


248 ↗(On Diff #35468)


310 ↗(On Diff #35468)


367 ↗(On Diff #35468)


436 ↗(On Diff #35468)


522 ↗(On Diff #35468)


169 ↗(On Diff #35468)

why not importing only deepcopy like the source material ?

169 ↗(On Diff #35468)

The PR's assertion that the required size is >= tx size can be preserved

170 ↗(On Diff #35468)

Macro likestamp:

This revision now requires changes to proceed.Oct 6 2022, 14:41
PiRK marked 2 inline comments as done.Oct 6 2022, 16:33
PiRK added inline comments.
169 ↗(On Diff #35468)

why not importing only deepcopy like the source material ?

OK, I guess it is better to only make the needed function accessible. If had used`from copy import copy`, then I would have preferred prefer the import copy; obj2 = copy.copy(obj) solution to avoid any ambiguity and risk of shadowing a previous import of the module. That's why I'm used to importing the entire namespace for this one.

Note that in general for python it does not make a difference in terms of performance (both solutions will cause the entire module to be parsed / executed), it only affects which members of copy are accessible in the namespace.

169 ↗(On Diff #35468)

OK. Note that in the source material the comparison is backwards ( thing1 >= thing2), so I will use
assert_greater_than_or_equal(tx_heavy.size(), target_size) instead of assert_greater_than_or_equal(target_size, tx_heavy.size())

PiRK marked an inline comment as done.


PiRK marked 6 inline comments as done.Oct 6 2022, 16:39
This revision is now accepted and ready to land.Oct 7 2022, 10:25