Add 'small block' miners

[jonasnick]

Hi, I fully agree that modelling is an important tool to derive arguments pro or contra a block size increase. You write in this mail

I could not find a network topology where a big miner producing big blocks could cause a loss of profit to another miner (big or small) producing smaller blocks

Is there an option to make some miners produce blocks with lower propagation latency?

If all miners produce big blocks the latency has a significant effect on block shares. See the results of my own simulations. They contradict your claim that "0.3% [increase in block shares] is in the noise". It would be interesting to see if there really exist optimal block sizes for smaller miners that don't increase centralization pressure.

[gavinandresen]

Yes, syntax for making some miners produce blocks with a different latency is:

miner=0.1 standard 20 (10% hashrate miner that produces 20-second-latency blocks -- leave out the 20 and a miner will go along with whatever the default is passed in on command line)

RE: my "in the noise" comment: That is in the context of week-to-week fluctuations in profitability/luck. Your graphs (very nice!) show that even with ideal, constant hashrate and no "I got DoS attacked last week" real-world variations the number of blocks produced varies quite a lot.

RE: optimal size for smaller miners: smaller miners should produce blocks that propagate quickly. If they do, then they turn the tables on big miners producing big blocks (at least, according to my simulations, would be curious to see if yours agree).

[jonasnick]

RE: your "in the noise" comment: I think that whatever distribution the real world block shares follow, it would be shifted to a different mean if everybody would create 20 latency blocks. So the effect is not in the real-world noise.

I ran the simulations again and this time let small miners always create 1 latency blocks. The results confirm that big miners have a disadvantage if they produce big blocks while the rest creates small blocks.

I would have expected that there is some hashrate threshold for a big miner above which the miner can profit from 20 latency blocks because other miner's power is wasted on an older block. But I guess in order to see these effects the big miner would have to stop mining on top of his own block, as soon as the rest found a block before the big miner's block has propagated. But this appears to be just a weaker form of selfish mining you can already do today.

I would carefully conclude that 20x latency is not gameable by miners who are only allowed to vary their block's latency (as long as the rest of the network chooses a reasonable strategy and its fully connected). There are still a lot of interesting questions though. But some of those rely more and more on assumptions and therefore the usefulness in the a block size debate decreases.

For example, shouldn't the percentual disadvantage for increasing the block size be the same for all miners? This would play a role as soon as fees become relevant. Also it might be possible for a miner to produce a big block and relay it only to a couple of nodes such that there is a (relative long) time of 'partitioned' mining. There are indeed topologies where such a miner can profit from big blocks (40.13% mean block share). The topologies I found all assume that the rest of the network is only very sparsely connected. It would be interesting to find out the minimum number of connections of the fully connected network that have to be cut for the big miner to profit.