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.
"
Truly understood?" The True Scotsman called and asks you return his kilt ASAP.
Fret and mewl more about being called mean names, your endless concern-meta scoldings and finger-wagging process objections (we already know you are afraid to "fight features") are really helping the credibility of your argument.
The only way to remove the 1MB cap is via a hard fork. Thus my parsing of your absurd assertion regarding "The Simple Solution
TM" is logically correct.
To quote Hearn, "don't pretend any of this stuff is obvious."
You asked "what is bloat?" Bloat is Gavincoin, with its undesirable sacrifice of security for (the feature of) MOAR TPS.
I made no generic claims about whether "systems with more data are inherently more complex than systems with less data."
That depends on the inheritances (ie data dependencies or non-dependencies) of the system in question. Usenet? No. Bitcoin? Yes. Your retreat into generalities is noted, with all due scorn.
Raising the block size, if done responsibly with a view to present entailments (100k max tx) and forward implications (Future Gavin vs 2015 Gavin), is not as obvious as 'changing a config setting.' Again, "don't pretend any of this stuff is obvious." DoS blocks are only one example of why Bitcoin is only now scaling to 1MB, and why massive order-of-magnitude jumps are hubris.
I want to enable Layer 2+ using the minimum of additional functionality in Layer 1. You want to stuff all of Layer 2+ into Layer 1. It doesn't take a PhD in linguistics to see who is proposing bloat.
Funny how you try to throw the term "eventually" in my face, when I've already said
I agree a block size will happen in exactly that timespan. Quick,
pout moar about what a horrible person I am for
agreeing with Satoshi!
Layer 1 and Layer 2 has nothing to do with software features, its an arbitrary economic division that you are using to try and confuse the issue. (Or are confused by?).
I think block size increase should be done in good time to stop all of this forced LN/sidechain/alt-coin nonsense you are pimping. If those things are good, and wanted then they will stand on there own merit. Whereas you think we should do it later, after rome is burning.
