Quote from: TierNolan on February 26, 2016, 04:47:10 PM

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.

Quote from: sickpig on February 26, 2016, 08:51:32 AM

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.

Quote from: belcher on February 26, 2016, 03:30:50 PM

Quote from: TooDumbForBitcoin on February 26, 2016, 02:47:53 PM

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.

Quote from: trout on February 26, 2016, 05:30:31 PM

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.

Quote

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.