Add "mempool" P2P command #1470

pull jgarzik wants to merge 2 commits into bitcoin:master from jgarzik:mempool changing 2 files +24 −0
  1. jgarzik commented at 2:53 PM on June 15, 2012: contributor

    This adds the "mempool" P2P command, which returns the first 50,000 entries in the TX memory pool (CInv vectors are capped at 50,000 already). SPV clients and other nodes may use this command following a block sync-up, to ensure they have the latest snapshot of the collective network.

  2. Add "mempool" P2P command 15cf34f852
  3. CTxMemPool::fillInv() minor cleanup: do not ref global 'mempool' 3650496cfb
  4. in src/main.cpp:None in 15cf34f852 outdated
    2883 | @@ -2869,6 +2884,14 @@ bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)
    2884 |      }
    2885 |  
    2886 |  
    2887 | +    else if (strCommand == "mempool")
    2888 | +    {
    


    TheBlueMatt commented at 3:04 PM on June 15, 2012:

    Should we do an if (fClient) return;


    jgarzik commented at 3:33 PM on June 15, 2012:

    Definitely not. This is part of SPV mode (although there are other uses as well). SPV clients sync up blocks, and then look in the mempool for any transactions they may have missed.

    This is also a client-initiated command, so it is the client that is proactively selecting to receive this data.


    TheBlueMatt commented at 4:04 PM on June 15, 2012:

    if (fClient) would mean that if we are a SPV node, we should not respond to mempool requests, as other SPV clients should not be asking peers that can entirely not check transactions for transactions (really to make it more explicit and keep SPV implementors from doing stupid things)


    jgarzik commented at 4:38 PM on June 15, 2012:

    Thin clients can and will know at a higher level whether or not they should issue 'mempool' command in the first place. Behavior for thin and fat clients and thin and fat servers is adequate without an explicit fClient check.


    TheBlueMatt commented at 8:05 PM on June 15, 2012:

    From IRC: If we are redefining NODE_NETWORK (==!fClient) to be a classic-style archival node not necessarily a full node (for pruning), then Im fine with defining a SUPPORT_SPV_CLIENTS to be has full blocks and supports mempool/filters/etc then Im fine with that. As long as we dont have partial support for the final SUPPORT_SPV_CLIENTS-type flag in one version and finalize it in the next.

  5. gavinandresen commented at 5:58 PM on June 15, 2012: contributor

    How should this be tested?

  6. jgarzik commented at 9:07 PM on June 15, 2012: contributor

    @gavinandresen just a simple "it works" test using ArtForz' half-a-node satisfies me...

  7. luke-jr commented at 12:38 AM on June 19, 2012: member

    Shouldn't this do something to ensure the transactions inv'd can be fetched? bitcoind won't send just any transaction right now, only ones it thinks it's flood-relaying.

  8. mikehearn commented at 8:53 AM on June 21, 2012: contributor

    Yeah, Luke is right. The patch needs to update the getdata command as well.

    After I'm finished with LevelDB I can throw together some bitcoinj support for using this command and make sure it works.

  9. jgarzik commented at 9:45 PM on July 31, 2012: contributor

    Foo Dog

  10. jgarzik closed this on Jul 31, 2012

  11. lateminer referenced this in commit 73a3dda28d on Jan 22, 2019
  12. lateminer referenced this in commit 02ede334f2 on May 6, 2020
  13. DrahtBot locked this on Sep 8, 2021

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: 2026-04-20 00:16 UTC

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