how do you explain away early adopters who genuinely feel just as threatened by over reaching devs who refuse to get out of the way of removing the limit once and for all while insisting that they know best the existing limits of the system?
First of all, I'm not wanting to explain anything away.
I have a "simple" solution for those early investors who feel they want to get rid of the limit altogether in a different way than the "let the user configure it" that BU, ABC, SV have currently implemented:
- specify your requirements, e.g. "remove the blocksize limit altogether from some client s/w". I would include something like "document when/how the software might actually break down"
- find a blockchain developer of your own choice to implement what you want
- make sure you properly validate / audit their submitted solution to ensure you get what you paid for
Bingo - your problem is solved (if you do those steps correctly).
There are great crowdfunding tools in case the funding is an issue.
I'm serious. Of course there are other ways that might lead to success, like making your case to projects like BU in another BUIP.
You could try to persuade some BU developers to start such a project in a long-lived development branch or fork of BU.
The considerations necessary for "remove the limit(s)" and for "make sure the software scales to X capacity" are completely different ones, and a project to just remove limits could yield interesting results in itself, while others like GTI focus on the technical scaling aspects.
the stress test was a wonderful example of the network achieving heights we'd never seen before and certainly were NOT predicted by devs.
I agree and I was one of those in favor of the public stress test.
But I'll say that the reasons devs didn't predict the bottlenecks found is that private stress testing conducted right now must be too unrealistic or simply lacking, otherwise they'd have found all those limits *in their software* ahead of any public testing.
The real benefit is to get a feel for how ready the rest of the system - which may be using entirely different software platforms - is, compared to what one would expect from often-mentioned parameters like EB32.
it revealed holes in the system the devs completely missed altogether, such as the atmp limit and Greg's bug
Specifically these things should've been known before the test. The conclusion is that private performance / stress testing is still very inadequate.
given such failures, how can anyone be confident they can reliably pick a default limit especially when they don't have the financial resources at risk at the level of miners nor the financial tools to adequately test maximum limit levels?
Those failures wouldn't have required exceedingly great financial resources to uncover, although some of the projects did say they're rather strapped for funding.
I'll gladly take occasional public stress testing, and as a user I'm happy to pitch in to generate load.
[social attack] certainly is but would pale in comparison to a bloat block, continuous 32mb block attack, or 51% attack.
Hmm, I think I would agree with that. Then perhaps
@imaginary_username 's explanation that majority hashrate on BTC is perceived as BCH-friendly might be more accurate. I think that assumption is fading though - I personally wouldn't rely on it.
I submit they aren't doing it today because they can't and won't because of the Satoshi incentives built into Bitcoin
If the attack really doesn't work because it can be easily blocked on the network, then trying it would still be extremely cheap and I couldn't give a reason why it hasn't been tried other than that I presume no-one's is currently willing to burn a million dollars to split the BCH network once or twice.
My overly optimistic side would be hoping for > 51% support of BTC hashpower for Bitcoin Cash's continued survival. But like I said it's not an assumption I can really justify any longer.
I think these considerations are all incomplete without putting dollars to retaliatory measures on the BTC network. And the dynamics of the market could be very complex (would BCH pick up users and hashrate if if BTC starts repeatedly experiencing December-like conditions?)
Can you tell me why early investors aren't saturating the BTC chain to prove that BCH is the better scaling option? (imo this is the other side of the question as to why bloat attacks aren't being made to happen on BCH)
the BCH hard fork that will cause a Nakamoto Concensus reorg given enough time.
I see you must be using a very large definition of NC re-org - including across coins that have split. Just observing. There will be those that disagree with the scope of NC. I'm undecided, but I think the "any needed rules can be enforced" does mean that if you are a miner and have the hashrate, you can enforce your vision of Bitcoin's rules, subject to the free market.