Quote from: iCEBREAKER on July 10, 2015, 10:00:53 AM

I suspect we agree that should 1MB blocks become an undeniably urgent concern (EG, if we see actual congestion resulting in appropriate fees no longer prioritizing their tx) the controversy will rapidly dissipate and be replaced by emergent rough consensus.

Quote from: Odalv on July 10, 2015, 11:00:55 PM

I do not understand why do we need to increase block size if we want to "employ minfee".
Let's try to "employ minfee" and if they raise too high then we will increase block size to reduce them.

It is clear that the people here are not so far apart after all. In reality it is differences of opinion on how to reach similar goals.

What is highlighted above would be fine if we were talking about a traditional centralized system, where a few people have control of all the software instances. Of course it would be possible to wait until there is actual tx congestion or fees tracking too high, unwise maybe, but very do-able, because it would be relatively quick to upgrade and continue as before.

With a decentralized system this is a luxury which does not exist, because the many instances within it are controlled by different people with different priorities, situations, political constraints, and speak different languages. A change that affects all of them needs to be given as much time as possible to be implemented.

Ideally, Satoshi should have listened to Jeff Garzik and caveden and implemented a flexible cap with his 1MB change in 2010. Done 5 years ago, the hard-fork would be a big fat nothing event as close to 100% of the full nodes in Bitcoin's network would be upgraded before the first >1MB block. If the change was done early in 2013, when the matter was heavily discussed, it would have given a 2-year delay before activation, so perhaps 95% of the full nodes would be upgraded. This is what BIP 100 assumes is still possible, but the 1Mb has become politicized so 95% is unlikely to be achievable and a rogue miner with 6% of the hash-rate could cripple Bitcoin long-term. So Gavin's BIP 101 assumes a 75% threshold, plus a grace period to help boost numbers. This is much more realistic but a rough hard-fork is now inevitable. The worst option is to wait until the change is obviously needed and try to do what Greg thinks is easy: a 2-week hard-fork. This might be easy for Core Dev gurus, but for thousands of full nodes this will come as a major shock, maybe leaving 50% of the nodes on each fork for a while. A "battle of the forks" might be an interesting and amusing real-world scenario test for cryptogeeks, but for 99% of Bitcoiners this would be a nightmare, they would be scared about the fate of their BTC, it would cause a serious loss of faith in this paradigm of new money.

Being preemptive about the 1MB reminds me of the Y2K situation. I spent a large chunk of 1998 on this as our company had 600 programs to change (requiring individual review) in just one sub-system, which also had 20 million abbreviated dates in the db and datafiles (requiring synchronized conversion with the programs), many of which existed from the 1980s when storage of all types was at a premium. The amount of testing required was laborious. Without this work the sub-system would have failed on Jan 1st 2000 costing the company tens of millions and making the name of the IT division "useless scum" in the minds of all the users. This was a centralized instance of software under the control of a handful of people. Even then the change was done over 1 year in advance of the Y2K date, and worked beautifully on the day.

TL:DR
If a software change needs 6 months or a year to happen then get it in progress 6 months or a year before it is needed by the user-base.