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.
Add "mempool" P2P command #1470
pull jgarzik wants to merge 2 commits into bitcoin:master from jgarzik:mempool changing 2 files +24 −0-
jgarzik commented at 2:53 PM on June 15, 2012: contributor
-
Add "mempool" P2P command 15cf34f852
-
CTxMemPool::fillInv() minor cleanup: do not ref global 'mempool' 3650496cfb
-
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.
gavinandresen commented at 5:58 PM on June 15, 2012: contributorHow should this be tested?
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...
luke-jr commented at 12:38 AM on June 19, 2012: memberShouldn'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.
mikehearn commented at 8:53 AM on June 21, 2012: contributorYeah, 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.
jgarzik commented at 9:45 PM on July 31, 2012: contributorFoo Dog
jgarzik closed this on Jul 31, 2012lateminer referenced this in commit 73a3dda28d on Jan 22, 2019lateminer referenced this in commit 02ede334f2 on May 6, 2020DrahtBot locked this on Sep 8, 2021Contributors
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
More mirrored repositories can be found on mirror.b10c.me