Send 'mempool' P2P command at the start of each P2P session #1833

to query remote node mempool contents.

NOTE: It is expected behavior that this will pump up the orphan pool initially, before dependencies resolve themselves.

Good idea. I'd disable such behavior during IBD.

Updated to avoid sending "mempool" while in IBD.

Each seems a little excessive. Perhaps only do it on outbound ones and/or only if the node's uptime is low? It's potentially a lot of extra data when you've got a hundred peers, and most of the data is redundant.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1fa4c04b1db831283157c54ef4e100f3420a219a for binaries and test log.

I had approx. 3200 transactions in pool when I updated my bitcoind to the new git version. I decided to include this in the build... got back up to ~3100 transactions in pool immediately. The only ones I lost were the ones with the large orphans (I'll probably modify that and make it 20k or 30k). A tad more load at the very start, but it only takes a few minutes to get up to 600 or 700 peers.. after that, I haven't noticed any difference (except more errors about how Tx is already used at x)

Restricting "mempool" queries to outbound connections seems like a reasonable compromise ... change updated.

I imagine hardcore miners would want to remove this condition, to guarantee they do not miss anything.

But it seems like outbound-only should get 99%, while saving bandwidth.

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/2533a62f6dc69d26b1e17b1240d17f3a26382106 for test log.

This pull does not merge cleanly onto current master

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/e3183085f33877e06cc04ff310ab6db3c59c8464 for binaries and test log.

ACK

Cool. Restricting to outbound connections also means you won't send this command to SPV clients that don't track the entire mempool. It may be worth a comment that makes this explicit rather than a side-effect of checking for outbound-ness.

Hm. How do we prevent this from violating the (probably soon to be implemented) expectation that transactions will live in the mempools of the network for a particular amount of time? Esp once peer rotation is implemented?

Two more added conditions:

1. Should have checked NODE_NETWORK (pfrom->fClient), which the BIP states, and @mikehearn unintentionally hinted at.
2. Only do this for the first two hours after node startup.

Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/22f9b069035c9ba0416a62714db167eea5ba762f for binaries and test log.

This could happen for one of several reasons:

1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
3. The test suite fails on either Linux i386 or Win32
4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)

I'm guessing this might be related, Not sure what else it could be, as outside of testing this I haven't modified the transaction code at all (I was planning on it, but...).. I've changed the misbehaving threshold to 102 to avoid situations like this, which is why I didn't disconnect those two peers.... but, seems like nobody else has, as I was left with about 50 peers (though it gradually started increasing, up to 150'ish, but I decided to restart bitcoind anyway). After that it only took about 10 minutes to get back up to ~800 (after restarting bitcoind), although about 80% of my addnodes were instantly disconnecting me.

http://5.9.24.81/lollercopter.txt

As the only reason I initially started running bitcoind on the server was for p2pool and I no longer use p2pool, I guess now is as good a time as any to shut it down. I'd rather use that server for video encoding & torrenting anyway (gbit connection and all). Maybe mess around on my kimsufi pos.

But, yeah... (oh, and I just included that first second... there were about 50 disconnects a second for another 10 seconds or so)

@jgarzik PullTester gives a compile error; can you look into that?