Quote from: gmaxwell on December 02, 2015, 07:26:28 AM

Quote from: Cconvert2G36 on December 02, 2015, 04:58:31 AM

Bigger blocks (with at least some reasonable upper bound) make spam attacks more expensive, as tx's drop out of the mempool and fees can be recycled continuously.

Not so much, in that the fee required to get into the mempool in the first place goes up as transactions are dropped out; at least with the limited mempool in 0.12. To the extent that a bigger block makes spam attacks more expensive it's only really through the action of making it much cheaper to inflict additional storage-in-perpetuity on the network. So far, the non-trivially funded spam attacks that we've seen have not been successful in driving the feel levels required to bypass them above negligible cents per transaction levels (e.g. significantly cheaper than what credit card networks charge merchants per transaction).... though obviously this has limits.

Right now, measuring the differential time it takes for mining pools to switch the blocks they're working on vs block size suggests an effective transfer rate of 723kbit/sec (less shockingly slow when you consider how inefficient TCP is for bursty conditions across links with worldwide latency), This is the amount of time it took for a block to reach half the monitored public pool's stratum endpoints after reaching the first one vs blocksize: https://people.xiph.org/~greg/sp2.png (Matt more recently did a similar measurement of relay network behavior and reached a similar but somewhat lower throughput). If you take that offset (2.491s) and data rate, and drop it into formula for subsidy income loss cost for the last byte of a megabyte block, the break-even feerate is 0.00045054 BTC/KB. So that suggests that at least lower hashrate miners are accepting transactions at a price low enough to be a net-loss currently. (It may not be the case; e.g. if the low hashrate miners are all fast. and the high hashrate miners are all slow, or low hashrate doesn't process as many transactions; and the data is all over the map... etc.)

Is there more data behind the plot? It would be useful to look at the distribution and the performance for specific pools vs. the topology involved, including machines and link rates. (I can appreciate that some of this data may be proprietary or otherwise unavailable.)

As to the nexus between bandwidth and hash rate. There is no need for this. I can speak from personal experience as a small scale miner. Last summer I was solo mining with two S3s that I was still running despite the heat and managed to score a block on solo.ckpool.org. The 0.5% fee was well worth it for use of a high bandwidth connection, because the orphan risk out of my DSL based home office would have been unacceptable. (You might ask, why was I solo mining? That's a another question, but it certainly looked like some of the pools had a consistent run of bad luck indicating that something was seriously wrong.)