refactor: mempool: use CTxMemPool::Limits #26103

pull stickies-v wants to merge 4 commits into bitcoin:master from stickies-v:mempool-simplify-fn-signatures changing 9 files +93 −96
  1. stickies-v commented at 7:32 pm on September 15, 2022: contributor

    Mempool currently considers 4 limits regarding ancestor and descendant count and size, which get passed around between functions quite a bit. This PR uses CTxMemPool::Limits introduced in #25290 to simplify those signatures and callsites.

    The purpose of this PR is to improve readability and maintenance, without behaviour change.

    As noted in the first commit “refactor: mempool: change MemPoolLimits members to uint”, we currently have an underflow issue where a user could pass a negative -limitancestorsize, which is eventually cast to an unsigned integer. This behaviour already exists. Because it’s orthogonal and to minimize scope, I think this should be fixed in a separate PR.

  2. fanquake added the label Refactoring on Sep 15, 2022
  3. fanquake added the label Mempool on Sep 15, 2022
  4. in src/validation.cpp:903 in c5e595250e outdated
    899@@ -899,8 +900,16 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
    900         // to be secure by simply only having two immediately-spendable
    901         // outputs - one for each counterparty. For more info on the uses for
    902         // this, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
    903+        CTxMemPool::Limits adjusted_limits{
    


    glozow commented at 9:59 am on September 16, 2022:

    Since we’re tidying, I think this could be moved into a helper in policy.h, interface something like this:

    0CTxMemPool::Limits CPFPCarveOutLimits(const CTxMemPool::Limits& normal_limits) {}
    

    stickies-v commented at 2:18 pm on September 16, 2022:
    That looks like a tidier approach indeed, added it to kernel/mempool_limits.h (w default argument) to avoid circular dependence between txmempool.h, kernel/mempool_limits.h and policy/policy.h. Thanks!
  5. in src/test/mempool_tests.cpp:212 in c5e595250e outdated
    208+        .ancestor_count = 100,
    209+        .ancestor_size_vbytes = 1'000'000,
    210+        .descendant_count = 1'000,
    211+        .descendant_size_vbytes = 1'000'000,
    212+    };
    213+    BOOST_CHECK_EQUAL(pool.CalculateMemPoolAncestors(entry.Fee(2'000'000LL).FromTx(tx7), setAncestorsCalculated, mempool_limits, dummy), true);
    


    glozow commented at 10:07 am on September 16, 2022:
    I think this can be replaced with CTxMemPool::Limits::NoLimits(), actually. These numbers seem arbitrarily high and don’t restrict anything, suggesting the intent of this test case is just to calculate the ancestors properly.

    stickies-v commented at 2:04 pm on September 16, 2022:
    Okay, wasn’t super familiar with it. Updated to use Limits::NoLimits(), thanks.
  6. in src/kernel/mempool_limits.h:35 in c5e595250e outdated
    33+     * @return MemPoolLimits with all the limits set to the maximum
    34+     */
    35+    static MemPoolLimits NoLimits() {
    36+        uint64_t no_limit{std::numeric_limits<uint64_t>::max()};
    37+        return {no_limit, no_limit, no_limit, no_limit};
    38+    }
    


    glozow commented at 10:24 am on September 16, 2022:
    I think it would make sense to delete the default ctor and require callers to set all 4 members when constructing.

    stickies-v commented at 2:03 pm on September 16, 2022:
    What would be the benefit of that approach? Asking because it’s quite a deviation from the current process, where we construct an empty MemPoolLimits (with default values as defined here) in init.cpp (as a member of CTxMemPool::Options), and then pass it to multiple ApplyArgsManOptions() functions to update it with startup parameters if provided. I think deleting the default ctor of MemPoolLimits would require changing that whole flow, and I’m not sure it’s worth it. I think having the default values here and not requiring every value to be explicitly defined makes sense?
  7. in src/kernel/mempool_limits.h:20 in c5e595250e outdated
    16@@ -17,13 +17,21 @@ namespace kernel {
    17  */
    18 struct MemPoolLimits {
    19     //! The maximum allowed number of transactions in a package including the entry and its ancestors.
    20-    int64_t ancestor_count{DEFAULT_ANCESTOR_LIMIT};
    21+    uint64_t ancestor_count{DEFAULT_ANCESTOR_LIMIT};
    


    glozow commented at 10:26 am on September 16, 2022:
    Can you explain why the change from signed to unsigned?

    stickies-v commented at 2:33 pm on September 16, 2022:

    I’ve updated the commit message. Relevant part used to be:

    0These int64_t members later
    1get cast into a size_t in CTxMemPool::CTxMemPool() anyway
    

    Is now:

    0These limits represent counts and sizes that should never be
    1negative. Currently, the int64_t members later on in the call stack
    2get cast into a size_t (without bounds checking) in 
    3CTxMemPool::CTxMemPool() anyway, so this type change does not
    4introduce any new underflow risks - it just makes them
    5unsigned earlier on in the process to minimize back-and-forth
    6type conversion.
    

    Does that resolve it?


    Riahiamirreza commented at 5:10 pm on September 17, 2022:
    I’m new to the code base so my question may look silly. Why the type of ancestor and descendant count are 64 bit? Isn’t 32 bit more than sufficient? Although, I know that’s not in the scope of this PR.

    glozow commented at 3:34 pm on September 20, 2022:

    Currently, the int64_t members later on in the call stack get cast into a size_t

    Yeah so we have virtual size implemented as size_t, unsigned ints, and signed ints in various places in the codebase, and it would be good to switch to 1 type consistently. I don’t think there’s a PR to do all of them, but #23962 is one.

    My current thinking is to use signed ints instead of size_t because we’re doing arithmetic with these limits (see CalculateAncestorsAndCheckLimits, #23962 (comment)). So I always use int64_t to hold virtual sizes. Not sure where we’re going long term :shrug:, but that’s why I don’t really agree with switching to unsigned.

    Why the type of ancestor and descendant count are 64 bit? Isn’t 32 bit more than sufficient?

    There’s never a need for more than 32 bits, but switching partially would cause integer truncation somewhere.


    stickies-v commented at 4:38 pm on September 20, 2022:

    I understand your reasoning and the one from the linked comment, but I’m not sure it makes sense here. A lot of the comparisons we do are with other size_t’s, e.g. from std::set::size(). So, we’d either have to unsafely cast them into an int64_t (probably fine, but… not ideal?) or implement a function that does it with bounds checking etc.

    I’m not sure that’s preferable? See e.g. the below diff, with some unsafe static_cast as well as implicit conversion (e.g. CheckPackageLimits() passing package.size() to CalculateAncestorsAndCheckLimits())

     0diff --git a/src/kernel/mempool_limits.h b/src/kernel/mempool_limits.h
     1index fd0979c6c..584af5679 100644
     2--- a/src/kernel/mempool_limits.h
     3+++ b/src/kernel/mempool_limits.h
     4@@ -17,20 +17,20 @@ namespace kernel {
     5  */
     6 struct MemPoolLimits {
     7     //! The maximum allowed number of transactions in a package including the entry and its ancestors.
     8-    uint64_t ancestor_count{DEFAULT_ANCESTOR_LIMIT};
     9+    int64_t ancestor_count{DEFAULT_ANCESTOR_LIMIT};
    10     //! The maximum allowed size in virtual bytes of an entry and its ancestors within a package.
    11-    uint64_t ancestor_size_vbytes{DEFAULT_ANCESTOR_SIZE_LIMIT_KVB * 1'000};
    12+    int64_t ancestor_size_vbytes{DEFAULT_ANCESTOR_SIZE_LIMIT_KVB * 1'000};
    13     //! The maximum allowed number of transactions in a package including the entry and its descendants.
    14-    uint64_t descendant_count{DEFAULT_DESCENDANT_LIMIT};
    15+    int64_t descendant_count{DEFAULT_DESCENDANT_LIMIT};
    16     //! The maximum allowed size in virtual bytes of an entry and its descendants within a package.
    17-    uint64_t descendant_size_vbytes{DEFAULT_DESCENDANT_SIZE_LIMIT_KVB * 1'000};
    18+    int64_t descendant_size_vbytes{DEFAULT_DESCENDANT_SIZE_LIMIT_KVB * 1'000};
    19 
    20     /**
    21      * [@return](/bitcoin-bitcoin/contributor/return/) MemPoolLimits with all the limits set to the maximum
    22      */
    23     static MemPoolLimits NoLimits()
    24     {
    25-        uint64_t no_limit{std::numeric_limits<uint64_t>::max()};
    26+        int64_t no_limit{std::numeric_limits<int64_t>::max()};
    27         return {no_limit, no_limit, no_limit, no_limit};
    28     }
    29 
    30diff --git a/src/txmempool.cpp b/src/txmempool.cpp
    31index 3097473ac..ee5ffff7b 100644
    32--- a/src/txmempool.cpp
    33+++ b/src/txmempool.cpp
    34@@ -183,14 +183,14 @@ void CTxMemPool::UpdateTransactionsFromBlock(const std::vector<uint256>& vHashes
    35     }
    36 }
    37 
    38-bool CTxMemPool::CalculateAncestorsAndCheckLimits(size_t entry_size,
    39-                                                  size_t entry_count,
    40+bool CTxMemPool::CalculateAncestorsAndCheckLimits(int64_t entry_size,
    41+                                                  int64_t entry_count,
    42                                                   setEntries& setAncestors,
    43                                                   CTxMemPoolEntry::Parents& staged_ancestors,
    44                                                   const Limits& limits,
    45                                                   std::string &errString) const
    46 {
    47-    size_t totalSizeWithAncestors = entry_size;
    48+    int64_t totalSizeWithAncestors = entry_size;
    49 
    50     while (!staged_ancestors.empty()) {
    51         const CTxMemPoolEntry& stage = staged_ancestors.begin()->get();
    52@@ -241,7 +241,7 @@ bool CTxMemPool::CheckPackageLimits(const Package& package,
    53             std::optional<txiter> piter = GetIter(input.prevout.hash);
    54             if (piter) {
    55                 staged_ancestors.insert(**piter);
    56-                if (staged_ancestors.size() + package.size() > limits.ancestor_count) {
    57+                if (static_cast<int64_t>(staged_ancestors.size() + package.size()) > limits.ancestor_count) {
    58                     errString = strprintf("too many unconfirmed parents [limit: %u]", limits.ancestor_count);
    59                     return false;
    60                 }
    61@@ -277,7 +277,7 @@ bool CTxMemPool::CalculateMemPoolAncestors(const CTxMemPoolEntry &entry,
    62             std::optional<txiter> piter = GetIter(tx.vin[i].prevout.hash);
    63             if (piter) {
    64                 staged_ancestors.insert(**piter);
    65-                if (staged_ancestors.size() + 1 > limits.ancestor_count) {
    66+                if (static_cast<int64_t>(staged_ancestors.size() + 1) > limits.ancestor_count) {
    67                     errString = strprintf("too many unconfirmed parents [limit: %u]", limits.ancestor_count);
    68                     return false;
    69                 }
    

    stickies-v commented at 1:58 pm on September 27, 2022:

    @glozow:

    So I always use int64_t to hold virtual sizes. Not sure where we’re going long term 🤷, but that’s why I don’t really agree with switching to unsigned.

    I went through all the places where any of the 4 members of MemPoolLimits are accessed. In all of them, except for one (see below), they are immediately cast to a uint. This happens explicitly e.g. here, or implicitly by passing it to a fn/ctor/variable that expects a uint or size_t (e.g. here or here or here).

    The only place where we actually use the signedness of any of the members is here: https://github.com/bitcoin/bitcoin/blob/9fcdb9f3a044330d3d7515fa35709102c98534d2/src/init.cpp#L1418 I don’t think the implicit conversion introduced by this PR is problematic.

    For that reason, I would argue that updating the MemPoolLimits members to be uint64_t instead of int64_t (which is necessary to avoid compiler warnings that we’re comparing uint with int in all of the places outlined the diff here) is - except for the one case - not a regression, and is the most straightforward implementation for the goal of this PR. I currently have no objection to what is being proposed in #23962, but I feel like changing these members and all subsequent call sites to signed integers is orthogonal and would unnecessarily introduce complexity and controversy for this PR. As such, my preference would be to not do it here.

    What do you think? If you agree with making MemPoolLimits members uint64_t, I will do a force push that removes the now unneccessary uint casts such as here.


    glozow commented at 2:45 pm on September 28, 2022:
    Ah I see, thank you very much for going through the usage! I agree it seems appropriate to defer to a later PR.

    hebasto commented at 9:27 am on October 4, 2022:

    3611c2bd710d147fbed815180e512f2af0061e83, approach NACK.

    I do not agree that switching to unsigned type is an improvement. Especially for variables involved in arithmetic and comparison operations.

    For example, see https://www.aristeia.com/Papers/C++ReportColumns/sep95.pdf


    stickies-v commented at 2:03 pm on October 4, 2022:

    Thanks for your feedback hebasto. Even though the MemPoolLimits members are almost always cast to an unsigned int so I think it’d be clearer to have everything be in the type in which it’s actually used, I understand your concern that you don’t want to regress the interface to avoid future PRs building on an unsigned MemPoolLimits interface.

    As such, I think the most straightforward way to move this PR forward and preserve as much review time as possible is to remove the commit that made the MemPoolLimits members unsigned and introduce static_cast<uint64_t> wherever necessary. This way the interface remains signed and behaviour remains unchanged (including arithmetic with unsigned integers) to how it was before this PR.

  8. glozow commented at 10:26 am on September 16, 2022: member
    Concept ACK to using the Limits struct instead of a list of ints. I think this is more readable, especially the static NoLimits when we just want ancestors calculated.
  9. in src/txmempool.h:694 in c5e595250e outdated
    703     bool CheckPackageLimits(const Package& package,
    704-                            uint64_t limitAncestorCount,
    705-                            uint64_t limitAncestorSize,
    706-                            uint64_t limitDescendantCount,
    707-                            uint64_t limitDescendantSize,
    708+                            Limits limits,
    


    aureleoules commented at 1:03 pm on September 16, 2022:
    0                            const Limits& limits,
    
  10. in src/txmempool.cpp:190 in c5e595250e outdated
    186@@ -187,10 +187,7 @@ bool CTxMemPool::CalculateAncestorsAndCheckLimits(size_t entry_size,
    187                                                   size_t entry_count,
    188                                                   setEntries& setAncestors,
    189                                                   CTxMemPoolEntry::Parents& staged_ancestors,
    190-                                                  uint64_t limitAncestorCount,
    191-                                                  uint64_t limitAncestorSize,
    192-                                                  uint64_t limitDescendantCount,
    193-                                                  uint64_t limitDescendantSize,
    194+                                                  CTxMemPool::Limits limits,
    


    aureleoules commented at 1:03 pm on September 16, 2022:
    0                                                  const CTxMemPool::Limits& limits,
    

    stickies-v commented at 2:05 pm on September 16, 2022:
    Oh yes, woops. Thanks for pointing it out. Updated all instances to use const ref.
  11. in src/txmempool.cpp:233 in c5e595250e outdated
    229@@ -233,10 +230,7 @@ bool CTxMemPool::CalculateAncestorsAndCheckLimits(size_t entry_size,
    230 }
    231 
    232 bool CTxMemPool::CheckPackageLimits(const Package& package,
    233-                                    uint64_t limitAncestorCount,
    234-                                    uint64_t limitAncestorSize,
    235-                                    uint64_t limitDescendantCount,
    236-                                    uint64_t limitDescendantSize,
    237+                                    CTxMemPool::Limits limits,
    


    aureleoules commented at 1:03 pm on September 16, 2022:
    0                                    const CTxMemPool::Limits& limits,
    
  12. aureleoules commented at 1:05 pm on September 16, 2022: member
    Concept ACK
  13. fanquake commented at 1:13 pm on September 16, 2022: member
    Concept ACK
  14. stickies-v force-pushed on Sep 16, 2022
  15. stickies-v commented at 3:35 pm on September 16, 2022: contributor

    Force pushed to address review feedback and remove a leftover whitespace. Thank you for the quick feedback everyone!

    Main changes:

    • Introduce CPFPCarveOutLimits() helper function in mempool_limits.h. Currently not used by anyone else, but a bit tidier.
    • pass Limits by reference instead of value
  16. aureleoules commented at 3:36 pm on September 16, 2022: member
    you commited compile_commands.json
  17. stickies-v force-pushed on Sep 16, 2022
  18. stickies-v commented at 3:45 pm on September 16, 2022: contributor

    you commited compile_commands.json

    whoops sorry, fixed and added that to global gitignore

  19. DrahtBot commented at 4:08 am on September 17, 2022: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #25038 (policy: nVersion=3 and Package RBF by glozow)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  20. Riahiamirreza commented at 5:17 pm on September 17, 2022: contributor
    As far as I could understand the PR Concept ACK. I think this PR is relatively easy to understand and putting the good-first-review label on it can make sense IMO.
  21. Riahiamirreza approved
  22. stickies-v force-pushed on Sep 20, 2022
  23. stickies-v commented at 12:35 pm on September 20, 2022: contributor
    Force pushed to fix the failing ./test/functional/mempool_package_onemore.py test. In the last refactoring (c5e5952 -> c17d468) I should have passed m_limits when calling CPFPCarveOutLimits() because it was modified earlier in PreChecks() already. Also removed the argument-less overload of CPFPCarveOutLimits() since it’s now not used anywhere anymore.
  24. in src/kernel/mempool_limits.h:38 in 55b8e6f6cb outdated
    37+        uint64_t no_limit{std::numeric_limits<uint64_t>::max()};
    38+        return {no_limit, no_limit, no_limit, no_limit};
    39+    }
    40+
    41+    /** Modify the current mempool limits to reflect what is allowed under CPFP carve out policy. */
    42+    static MemPoolLimits CPFPCarveOutLimits(const MemPoolLimits& current_limits)
    


    glozow commented at 11:03 am on September 27, 2022:

    I think maybe c6f9d0361b for a separate PR

    This is definitely policy logic and thus belongs there (sorry for the churn as I know I asked you to move it to policy before realizing there was a circular dependency), I think it’s better to stay in validation.cpp than move to mempool_limits.h.

    Perhaps a future change to put all the policy constants in policy/settings or policy/constants or something, and then we can put this in policy where it belongs?


    stickies-v commented at 3:34 pm on September 28, 2022:
    Okay that makes sense, I didn’t have a strong view either way - no problem at all. I’ve reverted it back to the previous version (calling it cpfp_carve_out_limits this time) and then it can be refactored out in a follow-up.
  25. in src/validation.cpp:437 in 55b8e6f6cb outdated
    437+        m_limits{
    438+            .ancestor_count = m_pool.m_limits.ancestor_count,
    439+            .ancestor_size_vbytes = m_pool.m_limits.ancestor_size_vbytes,
    440+            .descendant_count = m_pool.m_limits.descendant_count,
    441+            .descendant_size_vbytes = m_pool.m_limits.descendant_size_vbytes
    442+        }
    


    glozow commented at 2:55 pm on September 28, 2022:

    nit in 55b8e6f6cb:

    Why not just use default copy?

    0        m_limits{m_pool.m_limits}
    

    stickies-v commented at 3:35 pm on September 28, 2022:
    That’s definitely how a sane person would do it yes, woops. Thank you - updated!
  26. glozow commented at 2:57 pm on September 28, 2022: member
    code review ACK, just 1-2 nits
  27. stickies-v force-pushed on Sep 28, 2022
  28. stickies-v commented at 3:41 pm on September 28, 2022: contributor

    Force pushed to incorporate glozow’s feedback - thank you for the review!

    • using copy constructor instead of designated initializer
    • removed the carved-out CPFPCarveOutLimits() function (~revert to previous version)
  29. glozow commented at 9:39 am on September 29, 2022: member
    ACK ae3a5f33f9ba0037bb01d4cb2d6713c8e2abd2ed
  30. glozow requested review from aureleoules on Oct 4, 2022
  31. aureleoules approved
  32. aureleoules commented at 9:10 am on October 4, 2022: member
    ACK ae3a5f33f9ba0037bb01d4cb2d6713c8e2abd2ed
  33. hebasto commented at 9:16 am on October 4, 2022: member
    Concept ACK.
  34. stickies-v force-pushed on Oct 4, 2022
  35. stickies-v commented at 2:10 pm on October 4, 2022: contributor

    Force pushed to address hebasto’s concerns regarding making the MemPoolLimits interface unsigned, which goes counter to the direction we want to take.

    Note: this introduces potential for follow-up improvements in CTxMemPool::CalculateAncestorsAndCheckLimits() where some of the static_casts can be removed by updating the function signature to use int64_t instead of size_t when CTxMemPoolEntry::GetCountWithDescendants() and CTxMemPoolEntry::GetSizeWithDescendants() are updated to return an int64_t. I’d prefer to minimize the

  36. stickies-v force-pushed on Oct 4, 2022
  37. stickies-v commented at 3:26 pm on October 4, 2022: contributor
    Force pushed to rebase to fix failing Win64 native CI (unrelated to PR).
  38. aureleoules approved
  39. aureleoules commented at 8:39 am on October 5, 2022: member

    re-ACK d0bfe6869855dcf112a7da640e2e8ad648f82bbd. Since my last review:

    • rolled back from uint64_t to int64_t for descendant_count, descendant_size_vbytes and no_limit.
    • added static casts to compare these values against uint64_t types.

    I also verified the values being checked against are of type size_t or uint64_t.

  40. hebasto commented at 8:43 am on October 5, 2022: member
    Approach ACK d0bfe6869855dcf112a7da640e2e8ad648f82bbd.
  41. in src/txmempool.h:565 in d0bfe68698 outdated
    555@@ -554,10 +556,7 @@ class CTxMemPool
    556                                           size_t entry_count,
    557                                           setEntries& setAncestors,
    558                                           CTxMemPoolEntry::Parents &staged_ancestors,
    559-                                          uint64_t limitAncestorCount,
    560-                                          uint64_t limitAncestorSize,
    561-                                          uint64_t limitDescendantCount,
    562-                                          uint64_t limitDescendantSize,
    563+                                          const Limits& limits,
    


    hebasto commented at 8:52 am on October 5, 2022:
    nit: Add limits parameter to the function Doxygen comment? And errString as well?
  42. in src/txmempool.h:670 in d0bfe68698 outdated
    666@@ -670,36 +667,31 @@ class CTxMemPool
    667 
    668     /** Try to calculate all in-mempool ancestors of entry.
    669      *  (these are all calculated including the tx itself)
    670-     *  limitAncestorCount = max number of ancestors
    671-     *  limitAncestorSize = max size of ancestors
    672-     *  limitDescendantCount = max number of descendants any ancestor can have
    673-     *  limitDescendantSize = max size of descendants any ancestor can have
    674+     *  limits = maximum number and size of ancestors and descendants
    


    hebasto commented at 8:55 am on October 5, 2022:
    Is this comment is Doxygen compatible?
  43. in src/kernel/mempool_limits.h:31 in d0bfe68698 outdated
    23@@ -24,6 +24,15 @@ struct MemPoolLimits {
    24     int64_t descendant_count{DEFAULT_DESCENDANT_LIMIT};
    25     //! The maximum allowed size in virtual bytes of an entry and its descendants within a package.
    26     int64_t descendant_size_vbytes{DEFAULT_DESCENDANT_SIZE_LIMIT_KVB * 1'000};
    27+
    28+    /**
    29+     * @return MemPoolLimits with all the limits set to the maximum
    30+     */
    31+    static MemPoolLimits NoLimits()
    


    hebasto commented at 9:34 am on October 5, 2022:

    67a4932a2ca1131ea04a011d67b3f3c2da727b5f

    0    static constexpr MemPoolLimits NoLimits()
    

    stickies-v commented at 12:09 pm on October 5, 2022:
    No strong view. It’s currently not called at compile time so perhaps a bit premature, but simultaneously it seems unlikely we’ll ever want to not guarantee this fn to be constexpr so might as well add it already. Updated.

    stickies-v commented at 3:21 pm on October 5, 2022:
    As @hebasto kindly explained offline (comparing https://godbolt.org/z/78r3sY4TW with https://godbolt.org/z/TfvKKvdM9), using constexpr here does indeed have benefits as the compiler is able to replace the NoLimits() function calls with constants. Thank you!
  44. in src/test/mempool_tests.cpp:206 in d0bfe68698 outdated
    202@@ -203,7 +203,7 @@ BOOST_AUTO_TEST_CASE(MempoolIndexingTest)
    203 
    204     CTxMemPool::setEntries setAncestorsCalculated;
    205     std::string dummy;
    206-    BOOST_CHECK_EQUAL(pool.CalculateMemPoolAncestors(entry.Fee(2000000LL).FromTx(tx7), setAncestorsCalculated, 100, 1000000, 1000, 1000000, dummy), true);
    207+    BOOST_CHECK_EQUAL(pool.CalculateMemPoolAncestors(entry.Fee(2'000'000LL).FromTx(tx7), setAncestorsCalculated, CTxMemPool::Limits::NoLimits(), dummy), true);
    


    hebasto commented at 9:38 am on October 5, 2022:

    Why has test been modified?

    If it is required, it would be better to separate such changes into their own commit to ensure that tests pass with no changes in testable code, no?


    glozow commented at 9:46 am on October 5, 2022:

    See #26103 (review)

    separate commit would be fine


    stickies-v commented at 12:09 pm on October 5, 2022:
    I’ve split it out into separate commit with glozow’s rationale in the commit message.
  45. refactor: mempool: add MemPoolLimits::NoLimits()
    There are quite a few places in the codebase that require us to
    construct a CTxMemPool without limits on ancestors and descendants.
    This helper function allows us to get rid of all that duplication.
    b85af25f87
  46. refactor: mempool: use CTxMempool::Limits
    Simplifies function signatures by removing repetition of all the
    ancestor/descendant limits,  and increases readability by being
    more verbose by naming the limits, while still reducing the LoC.
    3a86f24a4c
  47. test: use NoLimits() in MempoolIndexingTest
    The (100, 1000000, 1000, 1000000) limits are arbitrarily high and
    don't restrict anything, they are just meant to calculate ancestors
    properly. Using NoLimits() makes this intent more clear and simplifies
    the code.
    6945853c0b
  48. docs: improve docs where MemPoolLimits is used 33b12e5df6
  49. stickies-v force-pushed on Oct 5, 2022
  50. stickies-v commented at 12:11 pm on October 5, 2022: contributor

    Force pushed to address hebasto’s review feedback - thank you!

    • Split out changes to test/mempool_tests.cpp into separate commit
    • Added commit with improvements to Doxygen comments
    • Made MemPoolLimits::NoLimits() constexpr
  51. in src/txmempool.cpp:209 in 33b12e5df6
    210+        } else if (stageit->GetCountWithDescendants() + entry_count > static_cast<uint64_t>(limits.descendant_count)) {
    211+            errString = strprintf("too many descendants for tx %s [limit: %u]", stageit->GetTx().GetHash().ToString(), limits.descendant_count);
    212             return false;
    213-        } else if (totalSizeWithAncestors > limitAncestorSize) {
    214-            errString = strprintf("exceeds ancestor size limit [limit: %u]", limitAncestorSize);
    215+        } else if (totalSizeWithAncestors > static_cast<uint64_t>(limits.ancestor_size_vbytes)) {
    


    hebasto commented at 4:55 pm on October 5, 2022:

    nit:

    0        } else if (totalSizeWithAncestors > static_cast<size_t>(limits.ancestor_size_vbytes)) {
    

    I beg a pardon for being pedantic :) Feel free to ignore this nit.


    stickies-v commented at 10:15 am on October 6, 2022:
    Since this is a refactor PR, I’ll leave this as is. limitAncestorSize was a uint64_t before, so better to change this in a future PR imo. I’ll leave this comment open for visibility.
  52. hebasto approved
  53. hebasto commented at 4:55 pm on October 5, 2022: member
    ACK 33b12e5df6aa14344dd084e0c6f2d34158fca383, I have reviewed the code and it looks OK, I agree it can be merged.
  54. glozow commented at 2:27 pm on October 9, 2022: member
    reACK 33b12e5df6aa14344dd084e0c6f2d34158fca383
  55. glozow merged this on Oct 9, 2022
  56. glozow closed this on Oct 9, 2022

  57. sidhujag referenced this in commit 830fd5380f on Oct 9, 2022
  58. bitcoin locked this on Oct 9, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-21 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me