The warnings are disabled for whitelisted peers if the whitelistrelay flag is set.
Right. Unfortunately, Bitcoinj sends unsolicited transactions. The developers of BTCD have been complaining about that for a while, and I'd like to stop supporting unsolicited txn... but while the behavior is common we didn't want to add misbehavior for it.
Do you care to share the raw data? I would like to independently verify your claim.
I have data from the confirmation test run,
RX packets 169821144 bytes 83997523200 (78.2 GiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 269163479 bytes 293982867649 (273.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
RX packets 171751847 bytes 84478658144 (78.6 GiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 271892507 bytes 296796582415 (276.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and
RX packets 175622574 bytes 85220192328 (79.3 GiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 277631356 bytes 303320529705 (282.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
RX packets 175824690 bytes 85283702303 (79.4 GiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 277920978 bytes 303653216190 (282.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
These were 6 hour runs, with the node pre-primed for an hour before the ran began.
As tiernolan points out, the results aren't surprising-- if you go look in my reddit comments you'll see I computed similar figures for this from first principles before measuring.
Nice technical post, but why the drama at the end?
[...]
Aside: I just went to search for that PR to bitcoin classic but couldn't find it. Has it been deleted?
Took me a bit to find it:
https://github.com/bitcoinclassic/bitcoinclassic/pull/16 I'm not trying to stir drama, I was earnestly surprised as jtoomim commented extensively there.
since every peer has to receive every transactions eventually, it seems that Transactions * Peers is the absolute
minimum of transaction sends you'd need. Am I missing something trivial here?
You are!
Imagine if the network were wired such that if a message was relayed along connection 0 on each peer it would form a Hamiltonian cycle and reach every node in the network. Thus, each peer would receive and send each transaction exactly once. This shows the bound cannot be transactions*peers.
Now, this is obviously pretty fragile-- and our network doesn't form a nice complete cycle. So if you want to check if your peers actually has all the transactions you have, does that reintroduce transactions*peers(*ratio of txid to tx size) traffic? No. Set reconciliation lets you communicate a set difference with size proportional to the difference, see my EL5 description of a computationally efficient set reconciliation scheme: https://www.reddit.com/r/btc/comments/43iup7/mike_hearn_implemented_a_test_version_of_thin/czirz2p
The difference is, hopefully, almost zero size-- so the communication is small even if the number of transactions are large.
As far as I understand, a peer will send every transaction to everyone he hasn't received it from. So this results in an additional multiplicative factor of something like k/2, where k is the average number of neighbours for a node.
Is it this factor that you'd like to get rid of, gmaxwell?
Yes, it is. Technically it sends an INV (a message with TXids) not the whole transaction, though this is only a constant factor improvement.