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.
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.
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.
Are you trying to be reasonable? You realize this is bitcointalk, and Frap.doc's goldbug trolling thread to boot, right?
Seriously though, I think we are seeing divergence in not only methods but also goals between the RetailCoffeeCoiners and SettlementBackboneCoiners (with Frap.doc's AllThingsToAllPeopleAtAllTimesCoiners being the worst of all).
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.
I disagree with your application and the propriety of 20/20 hindsight. We did have a "flexible cap" but it was soft, not hard.
Without that, it's less likely the devs could have (so relatively smoothly) scaled and optimized Bitcoin all the way up to coping with full 1MB blocks, which was a very challenging albeit under-appreciated task. Even so and as mostly notably reported by gmax, Bitcoin's decentralization/trustlessness has by some important metrics suffered along the way.