Post
Topic
Board Development & Technical Discussion
Re: Proposal: We should vote on the blocksize limit with proof-of-stake voting
by
Peter Todd
on 28/06/2013, 17:18:57 UTC
Bitcoin is hopeless if majority of miners are evil.

The design of Bitcoin only requires a majority of miners to be economically rational for Bitcoin to work correctly; good or evil has nothing to do with it. It's easy to see how if a majority of miners think that it is economically advantageous for them to mine large blocks they have every reason to do so and every reason to do "evil" things like block votes against a blocksize increase. (after all, they're just "protecting" Bitcoin from those who want to "hold it back")


One more comment, on lifting the max block size, which I myself was bitching about.
Today I am tending to say that I was wrong - it won't matter.
I see it now that most miming pools keep the limit at 250KB and even if you remove the hardcoded 1MB from the client, they will still keep their soft limits at whatever level they want - and it will be rather lower than higher.
Anyone who decides to mine bigger blocks is betting against himself, because bigger blocks need more time to propagate over the net, thus naturally having a bigger chance to get orphaned. Measure a difference between propagating 250KB vs 25MB block and you will not think twice of which one your mining pool prefers.

This is a brilliantly designed "ecosystem" that is regulating itself - therefore, seeing it at work, I am against any additional regulations.

Unfortunately you are quite wrong there. Pools can easily peer with each other with dedicated connections on fast servers to ensure that blocks propagate quickly to other pools and we can expect more of this in the future; the incentives to produce small blocks due to propagation delays and orphans are greatly diminished by peering because your block will reliably get to the majority of hashing power fast, the "little-guys" with the most decentralized hashing power be damned.

FWIW the real reason why pools have mostly switched to a 250KB limit seems to be just a change in the block creation code that makes the 250KB default limit a hard limit, rather than the previous behavior where the hard limit was 500KB and it took transactions with increasingly higher fees to fill up that space. If anything it just shows how little pool operators care about transaction fees right now in favor of the still very high inflation subsidy.

Interestingly the recent DoS attack against Bitcoin - caused by how Bitcoin was allowing messages up to 32MiB in size with no anti-DoS limits - gave me a unique opportunity to observe the speed at which extremely large messages propagated across the network, not unlike extremely large blocks. While successive waves of the attack hit my Amazon EC2 hosted nodes very quickly - seconds - due to their high bandwidth it took multiple minutes for those same messages to even begin to appear at less well connected nodes, such as at my apartment, and especially any node connected via Tor. It would have been nice to actually run some experiments, but unfortunately I was too busy trying to stop the attack and the patch that I wrote which fixed the issue had the useful side-effect of "innoculating" even unpatched nodes to the attack. Oh well.