[kernel 2e/n] miner: Make mempool optional, stop constructing temporary empty mempools #25223

pull dongcarl wants to merge 3 commits into bitcoin:master from dongcarl:2022-05-kernelargs-mempool-miner changing 9 files +56 −60
  1. dongcarl commented at 5:57 pm on May 26, 2022: member

    This is part of the libbitcoinkernel project: #24303, https://github.com/bitcoin/bitcoin/projects/18

    This is NOT dependent on, but is a “companion-PR” to #25215.

    Abstract

    This PR removes the need to construct BlockAssembler with temporary, empty mempools in cases where we don’t want to source transactions from the mempool (e.g. in TestChain100Setup::CreateBlock and generateblock). After this PR, BlockAssembler will accept a CTxMemPool pointer and handle the nullptr case instead of requiring a CTxMemPool reference.

    An overview of the changes is best seen in the changes in the header file:

     0diff --git a/src/node/miner.h b/src/node/miner.h
     1index 7cf8e3fb9e..7e9f503602 100644
     2--- a/src/node/miner.h
     3+++ b/src/node/miner.h
     4@@ -147,7 +147,7 @@ private:
     5     int64_t m_lock_time_cutoff;
     6 
     7     const CChainParams& chainparams;
     8-    const CTxMemPool& m_mempool;
     9+    const CTxMemPool* m_mempool;
    10     CChainState& m_chainstate;
    11 
    12 public:
    13@@ -157,8 +157,8 @@ public:
    14         CFeeRate blockMinFeeRate;
    15     };
    16 
    17-    explicit BlockAssembler(CChainState& chainstate, const CTxMemPool& mempool);
    18-    explicit BlockAssembler(CChainState& chainstate, const CTxMemPool& mempool, const Options& options);
    19+    explicit BlockAssembler(CChainState& chainstate, const CTxMemPool* mempool);
    20+    explicit BlockAssembler(CChainState& chainstate, const CTxMemPool* mempool, const Options& options);
    21 
    22     /** Construct a new block template with coinbase to scriptPubKeyIn */
    23     std::unique_ptr<CBlockTemplate> CreateNewBlock(const CScript& scriptPubKeyIn);
    24@@ -177,7 +177,7 @@ private:
    25     /** Add transactions based on feerate including unconfirmed ancestors
    26       * Increments nPackagesSelected / nDescendantsUpdated with corresponding
    27       * statistics from the package selection (for logging statistics). */
    28-    void addPackageTxs(int& nPackagesSelected, int& nDescendantsUpdated) EXCLUSIVE_LOCKS_REQUIRED(m_mempool.cs);
    29+    void addPackageTxs(const CTxMemPool& mempool, int& nPackagesSelected, int& nDescendantsUpdated) EXCLUSIVE_LOCKS_REQUIRED(mempool.cs);
    30 
    31     // helper functions for addPackageTxs()
    32     /** Remove confirmed (inBlock) entries from given set */
    33@@ -189,15 +189,8 @@ private:
    34       * These checks should always succeed, and they're here
    35       * only as an extra check in case of suboptimal node configuration */
    36     bool TestPackageTransactions(const CTxMemPool::setEntries& package) const;
    37-    /** Return true if given transaction from mapTx has already been evaluated,
    38-      * or if the transaction's cached data in mapTx is incorrect. */
    39-    bool SkipMapTxEntry(CTxMemPool::txiter it, indexed_modified_transaction_set& mapModifiedTx, CTxMemPool::setEntries& failedTx) EXCLUSIVE_LOCKS_REQUIRED(m_mempool.cs);
    40     /** Sort the package in an order that is valid to appear in a block */
    41     void SortForBlock(const CTxMemPool::setEntries& package, std::vector<CTxMemPool::txiter>& sortedEntries);
    42-    /** Add descendants of given transactions to mapModifiedTx with ancestor
    43-      * state updated assuming given transactions are inBlock. Returns number
    44-      * of updated descendants. */
    45-    int UpdatePackagesForAdded(const CTxMemPool::setEntries& alreadyAdded, indexed_modified_transaction_set& mapModifiedTx) EXCLUSIVE_LOCKS_REQUIRED(m_mempool.cs);
    46 };
    47 
    48 int64_t UpdateTime(CBlockHeader* pblock, const Consensus::Params& consensusParams, const CBlockIndex* pindexPrev);
    

    Alternatives

    Aside from approach in this current PR, we can also take the approach of moving the CTxMemPool* argument from the BlockAssembler constructor to BlockAssembler::CreateNewBlock, since that’s where it’s needed anyway. I did not push this approach because it requires quite a lot of call sites to be changed. However, I do have it coded up and can do that if people express a strong preference. This would look something like:

    0BlockAssembler::BlockAssembler(CChainState& chainstate, const Options& options);
    1BlockAssembler::CreateNewBlock(const CScript& scriptPubKeyIn, const CTxMemPool* maybe_mempool);
    

    Future work

    Although wholly out of scope for this PR, we could potentially refine the BlockAssembler interface further, so that we have:

    0BlockAssembler::BlockAssembler(CChainState& chainstate, const Options& options);
    1BlockAssembler::CreateNewBlock(const CScript& scriptPubKeyIn, std::vector<CTransaction>& txs);
    2BlockAssembler::CreateNewBlock(const CScript& scriptPubKeyIn, const CTxMemPool& mempool);
    

    Whereby TestChain100Setup::CreateBlock and generateblock would call the BlockAssembler::CreateNewBlock that takes in CTransactions and we can potentially remove RegenerateCommitments altogether. All other callers can use the CTxMemPool version.

  2. dongcarl added this to the "WIP PRs" column in a project

  3. dongcarl moved this from the "WIP PRs" to the "Ready for Review PRs" column in a project

  4. dongcarl renamed this:
    miner: Make `mempool` optional, stop constructing temporary empty mempools
    [kernel 2e/n] miner: Make `mempool` optional, stop constructing temporary empty mempools
    on May 26, 2022
  5. DrahtBot added the label Mining on May 26, 2022
  6. DrahtBot added the label RPC/REST/ZMQ on May 26, 2022
  7. DrahtBot commented at 0:36 am on May 27, 2022: member

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

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #25073 (test: Cleanup miner_tests by MarcoFalke)

    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.

  8. MarcoFalke commented at 8:09 am on May 27, 2022: member
    Can you explain what this change has to do with the kernel? I don’t see any modifications in the kernel folder or the kernel build target.s
  9. ryanofsky commented at 2:16 pm on May 27, 2022: member

    Can you explain what this change has to do with the kernel?

    I’m also not clear on how making BlockAssembler constructor not require an empty mempool relates to making kernel library better, or lets it drop dependencies. (This still does seem like a positive change, just connection is unclear)

    I don’t see any modifications in the kernel folder or the kernel build target.

    Maybe you already know this, but one thing that I wasn’t expecting looking at Carl’s branch is that it mostly doesn’t move source code into src/kernel/, instead it just changes build rules to build source files in other directories as part of the kernel library. I think the only source code that does moves into src/kernel/ initially is from files that have to be split up because they pull in wanted dependencies. If existing source files can be wholly moved into the kernel without being split up, they aren’t moved. Probably src/node/miner.cpp is one of these files.

  10. DrahtBot added the label Needs rebase on May 27, 2022
  11. dongcarl commented at 7:18 pm on May 27, 2022: member

    @MarcoFalke

    Can you explain what this change has to do with the kernel? I don’t see any modifications in the kernel folder or the kernel build target.s

    Ah yes, as the companion PR to #25215, this PR also “reduces the number of call sites where we explicitly construct CTxMemPool. This is done in preparation for later PRs which decouple the mempool module from ArgsManager…”

    One of the challenges I found with making the upcoming CTxMemPool+MemPoolAccept+mempool-relevant parts of CChainState <-> ArgsManager decoupling PRs easy to review was that from the view point of a reviewer, it was hard to reason that the behavior at each CTxMemPool construction call site was preserved. This is because after we decouple from ArgsMan, instead of reaching for gArgs deep in the mempool code, we now have to make sure that the options are set correctly and passed to each CTxMemPool that we construct. During development I also ran into some inadvertent bugs stemming from this.

    As an example: When we stop asking gArgs for -mempoolexpiry or -maxmempool in CTxMemPool+MemPoolAccept+mempool-relevant parts of CChainState, and instead construct CTxMemPool with an CTxMemPool::Options with these parameters as struct members, preserving existing behaviour means that every CTxMemPool construction call site would have to get the default CTxMemPool::Options and apply gArgs overrides.

    I reasoned that since these CTxMemPool constructor calls were entirely unnecessary in the first place, and the fix wasn’t that involved, we could kill two birds with one stone: remove what’s unnecessary and also make the ArgsMan decoupling PRs easier to reason about.

  12. dongcarl commented at 7:28 pm on May 27, 2022: member

    @ryanofsky

    Maybe you already know this, but one thing that I wasn’t expecting looking at Carl’s branch is that it mostly doesn’t move source code into src/kernel/, instead it just changes build rules to build source files in other directories as part of the kernel library. I think the only source code that does moves into src/kernel/ initially is from files that have to be split up because they pull in wanted dependencies. If existing source files can be wholly moved into the kernel without being split up, they aren’t moved. Probably src/node/miner.cpp is one of these files.

    Yeah I think that’s right. Mostly I just don’t think moving things around and changing namespaces for everything needs to be done right now. Looking at past reviews it also seems that people expect things in src/kernel/ to have some kind of cleanliness, even though we’re not going to be refining the API until Phase 2, so I’d like to avoid the sum of these little expectations to make it harder for the main thrust of Phase 1 to get through review.

  13. miner: Absorb SkipMapTxEntry into addPackageTxs
    SkipMapTxEntry is a short helper function that's only used in
    addPackageTxs, we can just inline it, keep the comments, and avoid the
    unnecessary interface and lock annotations.
    f024578b3a
  14. miner: Make UpdatePackagesForAdded static
    Since UpdatePackagesForAdded is a helper function that's only used in
    addPackageTxs we can make it static and avoid the unnecessary interface
    and in-header lock annotation.
    cc5739b27d
  15. dongcarl force-pushed on May 27, 2022
  16. dongcarl commented at 8:26 pm on May 27, 2022: member

    Pushed f159dbb92c88840ad44c6e0f1d8357449fd65141 -> 10827ac257689f8945166163b1ae496d792c790c

    • Rebased over master
  17. DrahtBot removed the label Needs rebase on May 27, 2022
  18. MarcoFalke commented at 3:24 pm on May 31, 2022: member
    I also wanted to ask what libbitcoinkernel has to do with mining. And if there is mining in it, why should the mempool be optional.
  19. dongcarl commented at 3:42 pm on May 31, 2022: member

    libbitcoinkernel doesn’t have anything to do with mining. However, mining does require (prior to this PR) a mempool. In many cases, these mempool are sometimes constructed on-the-fly (not as part of init). For example:

    https://github.com/bitcoin/bitcoin/blob/640eb772e55671c5dab29843cebe42ec35cb703f/src/rpc/mining.cpp#L357-L358

    Therefore, when I start making CTxMemPool options explicitly passed in to CTxMemPool’s constructor instead of just being globals inside gArgs, the on-the-fly calls to CTxMemPool’s constructor become much more involved.

    0        CTxMemPool::Options mempool_opts{};
    1        OverlayArgsManSettings(mempool_opts);
    2        CTxMemPool empty_mempool{mempool_opts};
    3        std::unique_ptr<CBlockTemplate> blocktemplate(BlockAssembler{chainman.ActiveChainstate(), empty_mempool}.CreateNewBlock(coinbase_script));
    

    Now, it would be another story if any of these empty_mempools were being useful, but it seems that they’re basically unused, so there’s no need for this charade. We can just remove BlockAssembler’s dependence on CTxMemPool by making it nullable and call it a day.

  20. MarcoFalke commented at 3:52 pm on May 31, 2022: member

    libbitcoinkernel doesn’t have anything to do with mining

    Wouldn’t it be better to move mining out of libbitcoinkernel and not motivate this pull request on [kernel 2e/n] and instead make it an orthogonal change?

    constructor become much more involved

    So an alternative would be to make CTxMemPool::Options optional to be passed to the constructor?

  21. dongcarl commented at 4:29 pm on May 31, 2022: member

    Wouldn’t it be better to move mining out of libbitcoinkernel and not motivate this pull request on [kernel 2e/n] and instead make it an orthogonal change?

    Mining is not in libbitcoinkernel right now, I put this PR as [kernel 2e/n] because there’s a lot of future work in libbitcoinkernel’s ArgsManager decoupling that depends on this. Another way I could have done it would be to publish the vision quest branch for libbitcoinkernel’s ArgsManager decoupling then split out this PR, but I didn’t think it’d matter that much which way I did it.

    So an alternative would be to make CTxMemPool::Options optional to be passed to the constructor?

    Yeah I suppose so, but it’s also fraught with danger:

    Does the CTxMemPool constructor consult gArgs when the CTxMemPool::Options is null?

    Then we’ve made CTxMemPool dependent on ArgsManager again.

    Does the CTxMemPool constructor just use the static const sane defaults when the CTxMemPool::Options is null?

    Then you’re likely introducing a behaviour change since the gArgs settings are no longer respected.

  22. MarcoFalke commented at 4:41 pm on May 31, 2022: member

    Then you’re likely introducing a behaviour change

    At least for the purposes of the miner this should not be the case. It will result in an empty block regardless of the options.

    Personally I think it is fine to fall back to the defaults. After all this is also what happens with gArgs when no options are passed to the ArgsManager.

    Though, I am also fine with your approach.

  23. in src/node/miner.cpp:124 in 10827ac257 outdated
    120@@ -121,7 +121,7 @@ std::unique_ptr<CBlockTemplate> BlockAssembler::CreateNewBlock(const CScript& sc
    121     pblocktemplate->vTxFees.push_back(-1); // updated at end
    122     pblocktemplate->vTxSigOpsCost.push_back(-1); // updated at end
    123 
    124-    LOCK2(cs_main, m_mempool.cs);
    125+    LOCK(::cs_main);
    


    MarcoFalke commented at 4:52 pm on May 31, 2022:
    In the commit message you claim that this is a behaviour change, but I don’t see an obvious user facing (or even test-facing) behaviour change. Maybe explain this a bit better or mention that this does not change behaviour?

    dongcarl commented at 7:18 pm on May 31, 2022:
    Ah yeah true… Guess I meant a “code-behaviour” change, but yes, will update!

    dongcarl commented at 7:21 pm on May 31, 2022:
    Fixed as of faddefe547cad0e4ba0f1cab635e48b42e153a11
  24. dongcarl force-pushed on May 31, 2022
  25. dongcarl commented at 7:21 pm on May 31, 2022: member

    Pushed 10827ac257689f8945166163b1ae496d792c790c -> faddefe547cad0e4ba0f1cab635e48b42e153a11

  26. in src/node/miner.h:150 in faddefe547 outdated
    146@@ -147,7 +147,7 @@ class BlockAssembler
    147     int64_t m_lock_time_cutoff;
    148 
    149     const CChainParams& chainparams;
    150-    const CTxMemPool& m_mempool;
    151+    const CTxMemPool* m_mempool;
    


    glozow commented at 9:55 pm on June 2, 2022:

    Aside from approach in this current PR, we can also take the approach of moving the CTxMemPool* argument from the BlockAssembler constructor to BlockAssembler::CreateNewBlock, since that’s where it’s needed anyway. I did not push this approach because it requires quite a lot of call sites to be changed.

    I don’t think that would be better; I think the [reference to] mempool belongs as a member of the class. Since the class also keeps track of things like nBlockWeight and nFees of the block, that suggests to me the intention is 1 BlockAssembler instance = building 1 block template. So I can’t think of why it would be safe/useful to change which mempool we’re using, and thus the mempool should remain a member and in fact

    0    const CTxMemPool* const m_mempool;
    

    ?


    dongcarl commented at 5:59 pm on June 3, 2022:
    Oh yeah that makes sense. Does it look like I need to modify the const-ness anywhere else?

    dongcarl commented at 7:40 pm on June 6, 2022:
    Fixed in 0f1a259657280afc727db97689512aef5ca928fc
  27. glozow commented at 0:29 am on June 3, 2022: member

    Concept ACK, agree with narrowing the interface for constructing mempools. In a number of ways, CTxMemPool is dependent on the caller to manage things for it; it requires somebody else to ask gArgs for maxmempool and call TrimToSize, get the active chainstate and pass in the coinsview to do consistency checks, etc. Constructing a mempool outside of the “main” path means we might forget to do something that CTxMemPool doesn’t take responsibility for; #24634 essentially stems from this.

    My initial reaction to seeing these empty mempools was “why aren’t they using node_context.mempool or chainstate.GetMempool()?” and the answer was that they need to skirt around the fact that BlockAssembler will try to fill up the block template using transactions from the mempool.

    we could potentially refine the BlockAssembler interface further…

    Also concept ACK to this - we have 2 ways of making a block template: (1) manually add the txns we want or (2) use the miner algo to maximize fees, and BlockAssembler should be responsible for creating both. The latter case (i.e. in generateblock and CreateBlock) is currently implemented by manually adding transactions to block.vtx and then calling RegenerateCommitments() - a bit of a hack, repeated across multiple tests, and potentially unsafe. It should be replaced with something like BlockAssembler::CreateNewBlock(manual_txns) which would internally handle the merkle commitments, call TestBlockValidity(), etc.

    One question though - it seems to me that we’d still want mempool in both cases? Why would we manually insert transactions that aren’t in our mempool?

    Regardless, I agree that making the mempool parameter optional is much better than creating placeholder mempools.

  28. miner: Make mempool optional for BlockAssembler
    ...also adjust callers
    
    Changes:
    
    - In BlockAssembler::CreateNewBlock, we now only lock m_mempool->cs and
      call addPackageTxs if m_mempool is not nullptr
    - BlockAssembler::addPackageTxs now takes in a mempool reference, and is
      annotated to require that mempool's lock.
    - In TestChain100Setup::CreateBlock and generateblock, don't construct
      an empty mempool, just pass in a nullptr for mempool
    0f1a259657
  29. dongcarl force-pushed on Jun 6, 2022
  30. dongcarl commented at 7:40 pm on June 6, 2022: member

    Pushed faddefe547cad0e4ba0f1cab635e48b42e153a11 -> 0f1a259657280afc727db97689512aef5ca928fc

  31. glozow removed the label RPC/REST/ZMQ on Jun 8, 2022
  32. glozow added the label Refactoring on Jun 8, 2022
  33. in src/test/fuzz/tx_pool.cpp:100 in 0f1a259657
     96@@ -97,7 +97,7 @@ void Finish(FuzzedDataProvider& fuzzed_data_provider, MockedTxPool& tx_pool, CCh
     97         BlockAssembler::Options options;
     98         options.nBlockMaxWeight = fuzzed_data_provider.ConsumeIntegralInRange(0U, MAX_BLOCK_WEIGHT);
     99         options.blockMinFeeRate = CFeeRate{ConsumeMoney(fuzzed_data_provider, /*max=*/COIN)};
    100-        auto assembler = BlockAssembler{chainstate, *static_cast<CTxMemPool*>(&tx_pool), options};
    101+        auto assembler = BlockAssembler{chainstate, &tx_pool, options};
    


    glozow commented at 9:13 am on June 8, 2022:
    Question: why’d you remove the static cast? Not suggesting you add it back, just wondering

    dongcarl commented at 3:37 pm on June 13, 2022:

    Oh, I just thought it was unnecessary. I think Marco added it in fa03d0acd6bd8bb6d3d5227512f042ff537ad993

    I don’t care either way what we do here!

  34. glozow commented at 8:48 am on June 13, 2022: member
    What do you think about adding a boolean to CreateNewBlock indicating “I don’t want any transactions other than the coinbase,” instead of making mempool optional? This can later easily be replaced with some txids/txns indicating “please manually add these to the block template.” Would it still help you detangle mempool from the argsmanager? I wrote a branch for this approach: https://github.com/glozow/bitcoin/commit/9590c8d5e844327d384795b4e3d97d8486dc8903
  35. dongcarl commented at 2:10 pm on June 13, 2022: member

    Talked with Gloria offline, I’m fine with either approach as long as we don’t create extraneous CTxMemPools. However, there are two things to consider if we take the route of “even in the case of supplying BlockAssembler with a custom list of transactions we insert them into the mempool then use the mempool logic to select txs to include in the block”:

    1. Do we want to allow for cases where we want to assemble a block with transactions which would not be selected using the mempool selection logic? For example: The mempool already has a block’s worth of high feerate txs, we want to create a block with a list of low feerate txs. This wouldn’t be possible if we take the aforementioned route of “even in the case of supplying BlockAssembler with a custom list of transactions we insert them into the mempool then use the mempool logic to select txs to include in the block”
    2. It seems from previous PRs (#19556) that we want to move towards a world where it’s possible to not have a mempool at all. In that -blocksonly world, do we still want to retain the ability to use the BlockAssembler?

    Ping @MarcoFalke @glozow

  36. glozow commented at 2:26 pm on June 13, 2022: member

    Ye thanks for summarizing @dongcarl, also asked @MarcoFalke offline

    Do we want to allow for cases where we want to assemble a block with transactions which would not be selected using the mempool selection logic?

    It seems like the answer to this is yes, and we already rely on this for things like generateblock rpc. A few tests broke when I played around with things, suggesting they rely on generateblock() only putting the manually specified transactions. In non-test-only scenarios, the option for manual block assembly also allows someone to plug in an external block solver.

    It seems from previous PRs that we want to move towards a world where it’s possible to not have a mempool at all. In that -blocksonly world, do we still want to retain the ability to use the BlockAssembler?

    At the very least, we use generateblock() for bootstrapping chains and that uses BlockAssembler to make blocks. It seems like there is a world where we want to generate empty blocks on a no-mempool node. There are multiple ways to do this, including (1) optional mempool for BlockAssembler ctor i.e. this PR, (2) a separate helper function that creates a valid but empty block.

  37. MarcoFalke commented at 2:27 pm on June 13, 2022: member

    I think:

    • if you want low-fee txs to be selected from the mempool usually you’d call prioritisetransaction on them.
    • if you want txs not in the mempool to be included, you’d pass them as raw hex, to be added directly the block, as you wouldn’t know whether they are standard enough to be added to the mempool. Consensus validity is obviously still checked by TestBlockValidity before returning the block.

    About the implementation: I think anything works. You could even go with both approaches at the same time. For example, you could make mempool a pointer to indicate whether to fill the initial block template with txs from the mempool. And you could add another option to pass a list of txs unconditionally added to the initial template.

  38. glozow commented at 2:32 pm on June 13, 2022: member

    ACK 0f1a259657280afc727db97689512aef5ca928fc

    Beyond avoiding the construction of temporary mempools, I was confused about why we’d ever use BlockAssembler() without a mempool, but that’s clarified now. As stated above there are multiple approaches, but I think this is fine and doesn’t hinder others. Reviewed the code to verify there’s no change in behavior.

  39. dongcarl commented at 2:54 pm on June 13, 2022: member

    Many thanks for the insightful comments Marco and Gloria! Lots to refer back to in future convos for sure.

    Glad that the current approach is good to move forward with!

  40. in src/node/miner.cpp:274 in f024578b3a outdated
    269-// we consider a transaction in mapModifiedTx and it fails: we can then
    270-// potentially consider it again while walking mapTx.  It's currently
    271-// guaranteed to fail again, but as a belt-and-suspenders check we put it in
    272-// failedTx and avoid re-evaluation, since the re-evaluation would be using
    273-// cached size/sigops/fee values that are not actually correct.
    274-bool BlockAssembler::SkipMapTxEntry(CTxMemPool::txiter it, indexed_modified_transaction_set& mapModifiedTx, CTxMemPool::setEntries& failedTx)
    


    MarcoFalke commented at 9:21 am on June 15, 2022:

    in the first commit:

    Any reason to not use the same approach from the second commit and make this function static? I understand that this would require passing the mempool solely to check the lock annotation, but I think this makes the diff smaller, keeps the structure of the file, and avoids making a large function even larger by inlining.

    If there are no other reasons I’d prefer to keep this as-is for now and leave restructuring to changes that actually need it?


    dongcarl commented at 3:38 pm on June 15, 2022:

    When I was looking at it, this function just seemed so intertwined with the rest of addPackageTxs. Both mapModifiedTx and failedTx are local variables to addPackageTxs and without the function abstraction we can also drop the AssertLockHeld. I agree that addPackageTxs is quite large and we could break it down into pieces where appropriate but I’m not sure that this is the right place.

    If we were to make it static we’d have to pass in the mempool and inBlock.

  41. MarcoFalke approved
  42. MarcoFalke commented at 9:21 am on June 15, 2022: member

    lgtm

    ACK 0f1a259657280afc727db97689512aef5ca928fc 🐊

    Signature:

     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA512
     2
     3ACK 0f1a259657280afc727db97689512aef5ca928fc 🐊
     4-----BEGIN PGP SIGNATURE-----
     5
     6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
     7pUhBFAv+Mu3PolWzpLYwd2nrk8Zpq6v9Jw7/TPIRCG2BgmUs0DQ5dht7aqKhiFEp
     8PiY8mbyM4A9XRHTZcJ1Up+G0tG+o3iMnE5z+9l6AnDRUHZ1N9j0OpxXMq6/ZwvuN
     9y5CNje2QIARf8oytize8w9Y/l+PxfLwSuFdOx0YHxwE3ZcosvVUUTeZO41QrI6Hu
    10Hhdsutm/qf25xsRTo/cs3ROrnTBI7wBi+VK6wggdyACSkFKQZWfA7mQiPBf3y+Ji
    11/vKXWD6P1n2tQJxDydKsHQ7r13/y5wKJQjJ5oN+0DgeWFCkbmiLY7r+jH3I1Yt8m
    12TG1vSj83awiC2SPnyOto1RYyA7AIWO+XArDuxYbFtYneM1dwj00oJmihUfguI47y
    13+CD26TsV6jCTXD1/l1TCAH6SCBR24tj1GJ/UbYPGlNAdpzS02UPGVGUttOm7wivS
    148YVc7iw/CykiNdOAaqtiTbrRxh2QcGjDWyOhORMit7Ft94RJjstbnGVspZdrChK5
    154tBjHzqC
    16=Ha/h
    17-----END PGP SIGNATURE-----
    
  43. laanwj commented at 1:17 pm on June 15, 2022: member
    Code review ACK 0f1a259657280afc727db97689512aef5ca928fc
  44. fanquake merged this on Jun 15, 2022
  45. fanquake closed this on Jun 15, 2022

  46. fanquake moved this from the "Ready for Review PRs" to the "Done or Closed or Rethinking" column in a project

  47. in src/node/miner.cpp:293 in 0f1a259657
    289@@ -300,17 +290,17 @@ void BlockAssembler::SortForBlock(const CTxMemPool::setEntries& package, std::ve
    290 // Each time through the loop, we compare the best transaction in
    291 // mapModifiedTxs with the next transaction in the mempool to decide what
    292 // transaction package to work on next.
    293-void BlockAssembler::addPackageTxs(int& nPackagesSelected, int& nDescendantsUpdated)
    294+void BlockAssembler::addPackageTxs(const CTxMemPool& mempool, int& nPackagesSelected, int& nDescendantsUpdated)
    


    ryanofsky commented at 4:02 pm on June 15, 2022:

    The BlockAssembler::addPackageTxs function now has access two different mempool variables: a mempool argument, and a this->m_mempool member variable. Right now these point to the same mempool, and the current addPackageTxs code only refers to mempool instead of m_mempool after this PR. But there is no enforcement for these things, so they can easily change and bugs could show up with no one noticing.

    IMO, either this new mempool argument should be dropped and function should go back to using m_mempool, or the m_mempool member should be dropped so it is guaranteed that function is only using mempool. But having multiple aliases for no reason is confusing and asking for bugs


    dongcarl commented at 4:29 pm on June 15, 2022:
    Added to the project issue TODO list: #24303

    MarcoFalke commented at 5:19 pm on June 15, 2022:
    I guess the function could be made static and all needed members be passed in?

    dongcarl commented at 5:35 pm on June 15, 2022:
    I mean honestly all the “helper functions for addPackageTxs()” listed in the header could be made static, also AddToBlock, and then inBlock could be a local var in addPackageTxs. That would minimize the BlockAssembler interface quite nicely. Lots of shuffling around tho.
  48. sidhujag referenced this in commit 696c9192fd on Jun 15, 2022
  49. laanwj referenced this in commit 489b587669 on Jun 16, 2022
  50. DrahtBot locked this on Jun 15, 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-07-01 13:12 UTC

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