The introduction of sidechains, LN and whatever other solutions is a complicated solution. It's also a solution motivated by a desire to fix a perceived economic issue, rather than sticking to the very simple issue at hand. It is the very opposite of what you are claiming to be important, that software should be kept simple.
That is a contradiction.
The simple solution is to remove the artificial cap. A cap that was put in place to prevent DDOS.
Your reference of CVE-2013-2292 is just distraction. It is a separate issue, one that exists now and would continue to exists with a larger block size.
Bloating Layer 1 is a complicated solution; scaling at Level 2+ is an elegant one.
You still don't understand Tannenbaum's maxim. Its point isn't 'keep software simple FOREVER NO MATTER WHAT.' That is your flawed simpleton's interpretation.
"Fighting features" means ensuring a positive trade-off in terms of security and reliability, instead of carelessly and recklessly heaping on additional functionality without the benefit of an adversarial process which tests their quality and overall impact.
One does not simply "remove the artificial cap." You may have noticed some degree of controversy in regard to that proposal. Bitcoin is designed to strenuously resist (IE fight) hard forks. Perhaps you were thinking of WishGrantingUnicornCoin, which leaps into action the moment anyone has an idea and complies with their ingenious plan for whatever feature or change they desire.
Like DoS, CVE-2013-2292, as an issue that exists now, is fairly successfully mitigated by the 1MB cap. It is not a separate concern because larger blocks exacerbate the problem in a superlinear manner. You don't get to advocate 8MB blocks, but then wave your hands around eschewing responsibility when confronted with the immediate entailment of purposefully constructed 8MB tx taking 64 times longer to process than a 1MB one. The issue is intrinsic to larger blocks, which is why Gavin proposed a 100k max tx size be married to any block size increase.
Fully parsed, what you are claiming is
The simple solution is to remove the artificial cap hard fork Bitcoin.
Do you realize how naive that makes you look?
If you truly understood your own position then you would argue it instead of just railing at people who might have an opposing view. Call me some more names, it's really helping the credibility of your argument.
What *is* bloat? (apart from the intentional choice of hyperbolic word). Can you put a value on what is considered bloated? Can you confidently say that your idea of what constitute bloat is some world wide standard?
You put words in my mouth, then claim those invented words make me look stupid. In fact this only serves to make you look even more desperate. if I didn't understand the maxim, I would not be able to point out just how incoherent your thought process must be if you are attempting to equate feature-set with size-of-data. I understand the difference between feature-set and data-size, do you? I'll bet you do. So, don't even for one second pretend you think that systems with more data are inherently more complex than systems with less data.
Do you truly believe they are the same thing or are you again being disingenuous in order to try and maintain your tenuous argument that effectively 'changing a config setting' is somehow more complicated than developing a whole new platform and all the interfaces necessary to communicate.
Its about as elegant as your debating skill....
Fully parsed your argument against Gavin's fix for CVE-2013-2292 seems to be, don't do it because it increases complexity. Again disingenuous or actually not very smart?
Then finally you try to create further confusion between the feature-set of software vs its deployment. To be clear, what is being kept simple is the software. I'm interested to know though just exactly what it is that is complex about the hard fork. I can think of other words that might apply - contentious, unpredictable even undesirable - depending on your viewpoint - but not complex. You put the new release up, and those that want it deploy it. Those that don't do not.
Interestingly those words that apply to the hard fork, could quite easily be used to describe intentionally restricting transaction growth by refusing to update the max block size. So in that respect both 'solutions' are equal.
In another very important respect, they are not equal. Releasing a version of bitcoin core with an increased block size allows for true consensus from the user base. Refusing to do so, is enforcing the view of some core-devs. That's what is despicable.
Thankfully in time, once the details have been ironed out and devs eventually accept some form of block size increase schedule (and they will, however much you cling to your delusion) the hard fork can happen in core, and then the miners can have the final say in what goes forward. If everyone sticks on 1MB coin then you get your wish! I'll send you a cookie, iced with the words "Well done you!".
I think though, that is what you are terrified of. That you know there is actually no way in hell the block size will stay at 1MB, but you are so married to your position that you can't let go and will say anything to defend it. It comes across in your posts.
Poll
