Greg has a good rebuttal-
“I’m so tired of responding to the same untruthful points over and over again.
E.g. the first thing it argues that that segwit doesn’t provide a know capacity increase because people need to choose to use it.
Well no duh, people need to choose to use more capacity for it to be used. That is what capacity is… And this very morning miners were producing <1MB blocks because their just isn’t enough demand to fill that (much less 4x more!) Moreover, the fact that SW adoption is gated by the normal slow software upgrade is not a downgrade over his hardforks: with his HF you also have to upgrade to use it, and the process means that there can be a gradual increase rather than a system shock of going straight back to ~0 fees and then a system shock again as fees come back into effect. — — reducing these shocks was a specific and intentional design goal in SW, one which his HF efforts have simply ignored.
have zero direct sensitivity to block size.
In fact they do not — they can directly observe the size of blocks by the size of the resulting hash trees they have it. I previously asked if any of them had been tested (and to see the test plans) and only got answers of “there is no effect!”. I agree they’re likely to do okay, but that doesn’t replace testing. This is symptomatic of the general recklessness around these proposals: Effectively “we’re going to change things, against people’s will, and if they don’t like the results well I guess they’ll get to fix it later.”
At large enterprises, there is literally a legally mandated de-risk’ing process
Yes, and the development methods and timeframe of segwit2x make it physically impossible to meet best practice deployment. They don’t even have a correct written specification for their irreversible consensus rule changes — even though they claim that they are so simple; don’t even have a release of the software (only a release candidate), and yet they expect to have 100% of Bitcoin users upgraded to these rules within 90 days or be subject to exposure for funds loss.
For critical networking infrastructure it’s common for operators to do months of their own testing on a vendors release before taking it into production; prudence which is physically impossible for Jeff’s segwit2x even if all companies dropped all other projects and immediately began working on just this. The timeframe alone demands we collectively reject it.
By comparison, segwit underwent 6+ months of public discussion and review and operation on a test system before being placed in any release, then had months post release before any possible activation to allow further testing, and this is for a change which is opt-in unlike Jeff’s hardfork.
Jeff continues on with a deceptive unequal comparison — basically comparing a plain Bitcoin Core user without custom software upgrading but he calls that the ‘hardfork’ upgrade, then he seperately describes a situation with someone unfortunate enough to use BLOQ’s library software that in spite over a year of opportunity does not yet have segwit support (and doesn’t appear to have started on it — BLOQ has apparently been too busy working of mandatory AML/KYC wallets to bother keeping up with the Bitcoin industry) and basically describes all the complexity created by BLOQ’s unmaintained software as segwit complexity.
His second case should have had an example for a user running their wallet infrastructure with Bitcoin Core or another maintained offering (like BitGo). It would be “test a new version, deploy a new version” like the above; but unlike the hardfork they can do it on their own timeframe, and use standard risk mitigation techniques like partial roll outs.
But what you’re really missing by reading that isn’t all the point it said but got wrong, but all the things it didn’t mention:
It doesn’t mention that frankensegwit ignores many attack vectors and performance issues and makes some worse, leaving them still debating kludging on additional consensus rule restrictions to protect it. Another highlight pointed out by that that is that “segwit2x” isn’t even a done deal — the consensus rules for it are still changing and not clear, so how can it expect useful review?
It doesn’t mention the process — that segwit2x is the product of a closed door backroom agreement between a VC and several of its investment; which has actively sheidled itself and rejected community review and commentary — which it continues to do even against the very people who wrote the consensus rules they copied; that it’s success would bring serious doubt to the long term security and viability of Bitcoin as an autonomous system free of central control.
It doesn’t mention that it has been uniformly rejected by the public and open development community, and that most of us will not go along with it both as a matter of engineering integrity but also out of the principle of public involvement and transparency. The same people who have been tirelessly growing, protecting, and maintaining the Bitcoin system since 2010/2011.
And so on….”
