Quote from: DooMAD on February 23, 2015, 05:08:48 PM

Quote from: NewLiberty on February 23, 2015, 04:45:47 PM

Quote from: DooMAD on February 23, 2015, 12:29:34 PM

Quote from: sardokan on February 23, 2015, 12:20:10 PM

Quote from: DooMAD on February 23, 2015, 11:58:01 AM

People have discussed sidechains and pruning and other suggestions, but the fact is, they will take time to implement to make sure they actually work. A 20MB blocksize is a far more simple solution that will work right now and until I hear something better, that's the one I'll be supporting.

Ok, but, see, we can go for 2-5-8 MB limit (wihtout exponential growth) before we hit the limit, and use the time gained by shooting the can to invent something better

It's not so urgent that our only choice is to implement exponential size growth

What you are saying now is, let's go exponential, maybe we can sustain it.

This is the worst anti-fork argument, since it means you'd want have to have another hard fork each time you need to increase it. If exponential adoption happens, either we find a way to cope with it, or another coin will. Again, there are only two outcomes. Increase the limit, or jump ship when Bitcoin can't cope and grinds to a halt.

Wow.
Take some time and consider what you are suggesting.
If you only do what is easy, rather than what is right, you will always be wrong.

Secondly, all of your premises here are incorrect. There is no grinding to a halt. The worse case scenario of not resolving this in a strategic way is that Bitcoin will continue to do what it already does better than anything else. It does not "grind to a halt". If your transaction is urgent, you pay a fee.

Important things are worth doing right. Even if they are hard.

Thirdly... So what if there are more hard forks later? The current proposal from Gavin also guarantees that there will be more hard forks. The proposal is a guess at what might be needed, it does not measure the block chain in any way to determine how to set the right block size. It is a good guess, but it is just a guess, same as the 1MB limit was. We don't finish with hard forks by going with the current proposal either. So none of your argument here makes any sense at all.

You want us to be afraid of some other crypto currency taking over, and that is why we need to fork? Sell your fear elsewhere.

This isn't "selling fear", this is common sense. This isn't about sending transactions without a fee, this is your transaction my not make it in even with a fee. Full means full. As in wait for the next one. And if that one is full, wait for the one after that. How long do you think people will wait before complaining that Bitcoin is slow and useless? Bearing in mind this is the internet and people complain about the slightest little inconvenience like it's the end of the world. I don't want to see the outcome of that fallout.

My argument is keep the number of forks to an absolute minimum, which is hardly controversial. You can clearly see in the quote above, Sardokan said "see, we can go for 2-5-8 MB limit", which sounded like he wanted to have this discussion a few more times in future. But now that he's clarified his position, you'll find I've already agreed with him that this fork is needed because we may not have a permanent solution ready before we hit the 1MB limit and the next fork should be the permanent fix to solve the problem of scalability once and for all. Again, if someone comes up with a permanent fix before we start coming close to that limit, I'll happily listen to that argument. Until then, we need to raise the limit. Stop over-reacting to things.

Yes, I caught your later post afterward. Thank you for clarifying that.
We will very likely have this discussion again in the future with the proposed fork also.
As you recognize here, there is not yet any proposal that will prevent that. We do not have a mechanism yet for a right-sizing max block size.

The 2-5-8 is not any less reasonable. A road-map of how to get to that right-sizing mechanism should be the 1st goal. We should have that before any significant fork anyhow. Without it, a small increase would be just fine with me. Once that road map is articulated, then comes picking an appropriate size to get Bitcoin that mechanism. Without it, it doesn't make a lot of sense to guess how long or how many transactions per second there will be by the time we get to it.

Beyond that, ending the max block size limit with free-market economic incentives is a far more distant goal.

In the short term...to high a limit and we get increased risk and spam attack risks, too low and we get transactions queued. Both are very bad. Whether you think one is worse than another is a matter of perspective.