Quote from: NewLiberty on February 23, 2015, 09:16:19 PM

There is a course of action to prepare for the future that is not based on some form of extrapolation. Many proposals have taken this form. All of them have the same failing in that they are not implementable without adding some code for metrics.

What will be there for us in 2, 5, 10, 20 years that will know how big bitcoin blocks are and need to be? The block chain will.

Heck, I'd go with this. Fixing it so the block size can be no bigger than 10x the median of the previous thousand blocks (plus some minimum to prevent the "sticky zero" of that simplistic formula, which might be relevant if the network ever has to restart) would do it for me. It would make me happier than the current proposal, in fact.

But I guess it comes down to three things, for me. First, I don't believe that the developers are clueless monkeys or lazy-asses who won't get around to doing anything, and I think characterizing them that way is kind of insulting. Seriously, have you been reading the v0.10 source code as opposed to the 0.8.x? A *lot* of work has been done. This is not a bunch of lazy-asses that will keep kicking the can down the road.

Although, if they have to deal with the likes of this argument every time a fork is needed, failure to get anything done won't require lazy-asses or clueless monkeys. It'll just require people who lose patience and quit when getting stuff done turns into an acrimonious shouting match.

Second, even though I don't believe that the 20MB + exponential growth for 20 years proposal is absolutely the best possibility, I *FEAR* this discussion getting so bogged down with "the perfect being the enemy of the good" that no block size limit change at all happens. The way I see it we've got to do something about the transaction rate, and this is, by far, the most developed proposal with the most momentum behind it and the least technological risk, even if it there are other, probably better, things that could be done.

Third, I simply don't believe in your threat model. Suppose a miner today tried to fill up 20MB blocks with bogus transactions. He couldn't do it as a mining pool operator, for a bunch of reasons to do with protocol and logistics. First of all it would increase the bandwidth costs of the miners by about 40-fold, even when not getting blocks. Second, the propagation delays that apply to all miners submitting bigger blocks apply to pool operators at least three times, not just once, meaning a *LOT* of missed blocks, not just a few. So it will make them noticeably less likely to get blocks. And third, there are other mining pools that are easy to switch to and don't have those disadvantages. So if somebody running a mining pool tried your attack, I'd expect miners to stay away in droves.

That leaves the hash farms as the only realistic candidates for supersizing blocks, and the hash farms have very limited time to make ROI on a major investment in rapidly-deprecating mining equipment. If a hash farm tries your attack, they'll have to economically justify the money lost, and I don't think the numbers work. So, even if someone is attacking, and even if for some economically insane reason they are attacking with enough power to get a whole block every day, (which NO HASH FARM can do at this time) they're only adding 20MB/day to a block chain that is currently on the order of 85MB/day. It's annoying, but it's costing them to do it, they can't sustain it for very long, and as an attack, it is not a disaster that the nodes can't handle.

The proposal on the table is not to scale the block chain at the rate of anticipated growth in Bitcoin usage as such -- which you and for that matter I would prefer. What it is doing is scaling according to the ability of exactly the same attack you're worrying about to create a more-than-just-annoying problem. It's much easier (though still unreliable) to make projections about the availability of bandwidth and what amount of bandwidth will constitute a serious problem, than it is to predict the timing of Bitcoin's adoption by the mainstream or the coming and going of Bitcoin-adoption fads. Nobody's really trying to predict the amount of Bitcoin use or the moment of its adoption by the mainstream here; they're just putting a limit on how much damage your attacker (the one I don't really believe in) can do, and the limit scales at the same rate that the resources necessary to deal with it scale.