SegWit2x was proposed as a solution to Bitcoin's network problems - but some people in the anti-2x movement claimed that it is nothing less than a cyber-attack: a 51% attack on Bitcoin, to be precise. This is getting ugly.

Hosted By

Ran Levi

Born in Israel in 1975, Ran studied Electrical Engineering at the Technion Institute of Technology, and worked as an electronics engineer and programmer for several High Tech companies in Israel.
In 2007, created the popular Israeli podcast, Making History, with over 14 million downloads as of Oct. 2019.
Author of 3 books (all in Hebrew): Perpetuum Mobile: About the history of Perpetual Motion Machines; The Little University of Science: A book about all of Science (well, the important bits, anyway) in bite-sized chunks; Battle of Minds: About the history of computer malware.

SegWit2x, Part 2

Hi, I’m Ran Levi, welcome back to Malcious Life, in collaboration with Cybereason. This is Part 2 of our three-part series on SegWit2x, the Bitcoin network upgrade proposal which changed the history of cryptocurrencies back in 2017.

Roger Ver vs. Tone Vays

There is, perhaps, no better encapsulation of why Bitcoin struggles as a payment system than what occurred when two famous Bitcoin proselytizers got on stage together for a debate last year.

We’re at the AIBC Summit in Malta. On stage are three people: a moderator, Tone Vays–a well-known speaker and proponent for Bitcoin in its original form–and Roger Ver.

Now, we need to take a minute to talk about Roger Ver. He’s not the type of guy whose name you mention quickly, then move on.

Dedicated listeners to this show have actually heard of Roger before. He featured once, briefly, in our episode on Mt. Gox. As the Mt. Gox Bitcoin exchange went dark, realizing they’d lost millions upon millions in other people’s money, Roger got in front of a camera and said, in 50 seconds, that the rumors about Mt. Gox being bankrupt were not true–that their CEO, Mark Karpeles, showed him bank statements that proved the financial issue at hand had nothing to do with the company’s liquidity. He said it while reading from a script, slightly off-camera, with all the conviction of a terrorist hostage.

Of course, Mt. Gox was dead broke. So why did Roger even do the video? He didn’t have to put his reputation on the line.

Honestly I don’t know–he’s an odd guy. It’s certainly clear why Mt. Gox would’ve wanted him to do a testimonial, though. Roger may be the world’s most well-known missionary for Bitcoin. After investing in early 2011, he began spreading the word all around the world–on YouTube, in news articles, wherever. For his work promoting Bitcoin to the world, he’s even earned the nickname “Bitcoin Jesus.”

He’s kind of the perfect guy for the job: super enthusiastic, always smiling. He’s good-looking, too–dark brown hair, a jawline I’d pay at least a couple Bitcoin to get for myself. And honestly, listeners, let’s face it: if you need somebody for a video, or a header image for an article, do you really want Pieter Wuille? Jeff Garzik? Bitcoin guys–they usually look, well, kind of like me. They’ve got messy hair, messy beards, a little overweight, you know the type. If you’re CNBC, and you need someone for a piece on Bitcoin, you want Roger up there.

But he’s a wildcard. In 2005, Roger moved to Japan after serving 10 months in prison for selling large quantities of firecrackers on eBay without a license. He’s the kind of aggressive libertarian who–and this is real–renounces his U.S. citizenship and becomes a citizen in the tax haven of St. Kitts and Nevis. For a period of time after he did that, he was barred from returning to the country.

So this is who we’re dealing with here. At the AIBC Summit in Malta, he gets on stage for what will be the third of a set of three popular debates with Tone Vays. Roger, by this time, has completely ditched Bitcoin in favor of an altcoin called “Bitcoin Cash,” or BCH, with a much larger block size. He’s arguing that Bitcoin, BTC, with its block size limitations, is not workable as a payment system.

Tone Vays, blockchain consultant and former Wall Street analyst, provides the rebuttal.

Keep in mind, folks: we’re only two minutes into the debate at this point.

In front of hundreds of onlookers, Tone takes out his phone.

Roger and Tone are both smiling, but it’s obvious that they’re different kinds of smiles. As Tone initiates a small Bitcoin transaction to Roger’s account, he’s rocking, slightly, in his chair. His foot begins tapping. He’s looking down at his phone. Roger’s leaned over, looking over his sparring partner like prey. With the kind of confidence that made him into Roger Ver, the Bitcoin Jesus.

Roger leans in…

It’s clear that the energy in the room has shifted. The audience members supporting Bitcoin are tensing up. The Bitcoin Cash people are loving it.

The two men continue arguing like children. But it’s great entertainment.

It may not have been so obvious to the audience at the time, but watching back on video, you can see Roger’s face change when Tone says nobody uses Bitcoin Cash. He was smiling, playing around before. But that sly comment, and the laughter it received from the audience, changed something in him. His demeanor shifts. You can sense he’s geared up. He looks Tone Vays straight in the eyes, like nobody else is in the room.

Tone averts his gaze. The conversation moves on as the two men go back and forth and the moderator, mostly forgotten already, leans in his chair, legs crossed, with an air of “well I guess I’m not needed here.” He’s not, really.

After five minutes, the bet comes back around. Roger’s teed it up. It’s at the exact right moment in the argument when he smiles, wryly, like a supervillain, raising an eyebrow, and excitedly reaches for his phone. As soon as Tone sees the shift in Roger’s body language, that nervous smile creeps back onto his face.

Tone looks down at his phone.

The moderator throws up his hands.

Early Upgrade Proposals

It didn’t have to get to this point.

In the early days, almost as soon as the one megabyte block size limit was conceived, so were discussions on how to raise it. Gavin Anderesen, arguably the second most powerful developer in Bitcoin’s history, and Mike Hearn, another early developer who worked alongside the founder of the platform, Satoshi Nakamoto, each proposed ideas for how to upgrade that limit in the future. Jeff Garzik, the most famous developer behind SegWit2x, proposed all the way back in October, 2010–just one month after the limit was implemented in the first place–that it be raised to 7 megabytes. Satoshi himself addressed how such a change might be enacted in the future, writing, quote:

It can be phased in [. . .] It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete. When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

End quote. So, in other words: we’ll jump off that bridge when we get there. I’ll handle it.

And he would have handled it, probably very well. Whenever the limit needed to be adjusted, he would’ve joined up with his Core team, come up with a solution that worked, and signaled that all the users adopt their new patch. Done and dusted.

But then fate turned. The following year, Satoshi was gone. The last we heard from the famous, mysterious inventor of Bitcoin came in response to an email from Mike Hearn. They were discussing some technical matters, when Mike changed the subject. “I had a few other things on my mind (as always),” he writes, “One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?”

Satoshi replies, April 23rd, 2011. Quote: “I’ve moved on to other things. It’s in good hands with Gavin and everyone.”

The creator of the network, the one and only person everybody listened to, was gone. He gave us Bitcoin, now it was up to the rest of us to get along on our own.

Pro 2x: Throughput Hurts All

To understand where the argument for SegWit2x begins, you need not go much farther than that debate between Roger Ver and Tone Vays. Roger wasn’t arguing for 2x, but the principle is the same: Bitcoin, in its modern state, is problematic as a payment system. Throughput with a one megabyte limit has left a large pool of unconfirmed transactions in a state of limbo, and getting out of that limbo is unnecessarily expensive.

It honestly can be confusing for 2x supporters to conceive of why users wouldn’t be the first to get behind a block size increase. They are the ones, after all, who have to pay transaction fees. Miners won’t complain if you have to throw them an extra five bucks every time you pay Steve.

The fact is that low throughput hurts everyone. Economies thrive when people are out spending money. The more money moving around the system, the more valuable each bit of it becomes, making everyone richer.

Lots of startups formed around Bitcoin during the mid-decade, with the prospect that one day this system might become a popular, worldwide currency. If the network can’t scale to accommodate even those using it now, it’s light years from being workable on the scale of ordinary, fiat currencies. And even SegWit, with all its innovativeness, only creates a few megabytes of actual transaction storage per block, at best. To this way of thinking, SegWit is a tasty whipped cream topping atop a turd sandwich.

No 2x: Lightning Network

There are, however, ways to increase Bitcoin’s transaction capacity–significantly–without doing anything to the block size.

In our Part I episode, we discussed how SegWit, in addition to effectively increasing the block size, fixes signature malleability. Before SegWit, the cryptographic signatures associated with transactions were vulnerable to tampering. This never became such a problem for the blockchain itself, but it was prohibitive for second layer protocols–programs built on top of the blockchain, to add to its functionality. The reason is simple: you can’t build a second layer on top of a vulnerable first layer.

With SegWit, however, all the best ideas for second layer protocols were finally freed. One, in particular, was seen by many as the thing to finally make Bitcoin scalable. It’s called The Lightning Network.

The Lightning Network, like BitCoin, is a decentralized network. It uses what’s called Smart Contracts – basically software scripts – to enable instant payments. The key insight of the Lightning Network is that it uses the Bitcoin ledger not as the means of making transactions, but, rather, as the means of settling transactions.

Say you want to pay for your morning coffees with Bitcoin. You’ll have difficulty if there’s a five dollar fee every time, and the payment takes ten minutes to confirm. The Lightning Network allows you to avoid these issues by taking your payments off the blockchain.

You begin by funding a secure payment channel between yourself and the coffee shop, using, for example, 2 centiBits – or 0.02 Bitcoin. Over the next month, you use your 2 CentiBits to buy coffee every day. Those 30 coffees together cost 1 centiBit –half of the total you had available. After that much coffee, you get sick of the place, so you close the contract with a final transaction which states that you now own only 1 centiBit of the Bitcoin you put in, and the coffee shop owns the other 1 centibit.

See what just happened? You made 30 payments over a month, but the ledger only recorded two events: your initial contribution of 2 centibit, and the final allotments of 1 centibit to each party. In other words, the public Bitcoin ledger was used only to settle your transactions, not carry them out. Lightning Network is much better at carrying them out, after all, since it allows transfers to occur instantly and without fees.

The Lightning Network has a number of other features that make it highly scalable, like severe fraud protection, and an advanced routing mechanism which allows users to pay other users without having to open a direct channel, simply by routing payments through other users in the network. In the end, it’s simple: Lightning allows for thousands of payments, instantly, with no fees, backed by the security of the Bitcoin blockchain, while taking up very little of its storage capacity.

You can see the appeal. Users, Core developers and businesses alike were excited at the prospect of SegWit, if for no other reason than that it would finally let loose The Lightning Network.

Pro 2x: Lightning’s Flaws

But not everybody was equally thrilled about Lightning. Miners didn’t love the idea, for reasons you don’t have to rack your brain to guess. More transactions occurring off-chain means less work for them.

But they also had better reasons to worry. The overwhelming majority of mining power comes from China–a country which doesn’t particularly get along with the notion of an extra-governmental currency network. China can’t really do anything about Bitcoin – but Lighting, due to it’s less transparent nature, is more vulnerable to malicious manipulations. There’s also the fact that Lightning was still an unproven solution. Some believed there were technical scenarios which could lead it to becoming centralized, or even unworkable on the whole.

No 2x: Vulnerable Code

But any argument about the viability of Lightning Network must also take into account that SegWit2x, itself, relied on an update to Bitcoin’s core software that was itself unproven. ‘BTC1’ was the name of the software implementation which, when activated by a node on the network, would run Bitcoin according to the SegWit2x rules.

The author of BTC1 was quite a capable developer whom we met in our last episode: Jeff Garzik. The problem was that, without support from the Core development team, the BTC1 client was not being subjected to the same rigorous code review that occurs for typical Bitcoin network upgrades. This made it much more likely to not work as intended, or contain serious security vulnerabilities. And for many in the Bitcoin community, this was not just a theoretical possibility.

‘Bitcoin Unlimited’ was one of the earlier scaling solutions to make it onto the network. In December, 2015 it was released with a simple idea: to allow miners and users to dictate their own block size preferences. With the Unlimited client, users can signal what block size preferences they prefer, and miners can configure the size of blocks they want to mine. The market decides from there.

Whether you like the concept of it or not, in March of 2017, it became clear why alternative Bitcoin clients can pose risk to users. It began with a Reddit post describing a remote crash vulnerability in Unlimited software. Nearly all nodes running Unlimited were exposed. Quote:

To be explicitly clear, just by making a request on the peer-to-peer network, this could be used to crash any [. . .] node with this bug. Any business could have been shut down mid-transaction, an exchange in the middle of a high volume trading period, a miner in the course of operating could be attacked in this manner. The network could have in total been brought down. Major businesses could have been brought grinding to a halt.

End quote. The author used a lot of “could” and “could haves” in the post, but it took only hours for a potential to become a reality. With simple and explicit directions, a hacker took down around two-thirds of all Bitcoin Unlimited nodes that day. A quick patch was released later in the day, and by the following day most of the downed nodes were back up.

Whoever hacked Bitcoin Unlimited may have been trying to prove a point, or maybe they were just bored. Either way, Unlimited users got off easy. The vulnerability had been sitting there for over a year. The day it was exploited it was patched, and everything returned to normal.

You just don’t hear stories like this about Bitcoin. I mean, there are Bitcoin-related hacks–for example, the bankrupting of Mt. Gox. But the Core software itself has tended to avoid any significant exploits. That’s in large part because the Core development team methodically, rigorously tests all code deployed to the network. Just because some of the world’s most talented developers are picking apart every update doesn’t mean you’re guaranteed impenetrable software, but it does ensure a level of difficulty that most hackers can’t touch.

The BTC1 client was not subject to such scrutiny. It was not an option to begin with, since none of the Core devs wanted in. The program would have to stand on its own merit. But who wanted to roll the dice on an alternative software client just two months after the Unlimited hack?

Hard Fork

The single biggest issue with the SegWit2x idea, though, was that it would initiate a contentious hard fork.

Broadly speaking, a blockchain protocol can be changed in one of two ways: via a soft fork, or a hard fork. The difference is simple but the consequences are drastic. Soft forks are backwards-compatible, meaning that non-upgraded nodes can still participate in the network, so long as they don’t break the new protocol rules. Think about it like an operating system update–any program which worked on, say, Windows 10.1 should still work on Windows 10.2.

Hard forks are backwards-incompatible, meaning that non-upgraded nodes will not be able to participate. Blocks which were previously valid will no longer be. Think about it like changing operating systems–a program designed for Windows will not work on macOS.

So there are reasons for initiating a soft fork, and reasons to initiate a hard fork, but doing the latter is far more serious and, hopefully, rare. When a Bitcoin user in 2011 initiated two transactions worth 92 billion Bitcoin each, the network had to hard fork. Two, incompatible versions of the blockchain were created: one with the value overflow transaction, and one without it. Everyone on the network upgraded to the version of the blockchain which made that transaction, and all transactions like it, invalid.

But that was easy, because everybody was in agreement about what to do. Nobody had an incentive to keep the hacked version of the blockchain alive. A contentious hard fork is one where parties to the network don’t agree with one another. In such a case, you still get two versions of the blockchain, but now there are coalitions which support either side. A race begins, with each blockchain vying to outpace the other by having a longer chain and more mining power behind it. From here, one of two scenarios can occur: either one version of the blockchain–the old or the new one–will clearly prevail over the other because it is more popular, or both will be popular enough to survive, and two, independent blockchains will have been formed.

Contentious hard forks tend to be bad for everyone. There’s competition rather than cooperation, and the uncertainty puts everyone’s assets at risk.

SegWit was created as a kind of compromise, in order to avoid a contentious hard fork. All this time we’ve been talking about raising or not raising the block size–SegWit actually does increase the block from 1 megabyte to 4, it just does it in such a way that doesn’t require the network to hard fork. The transaction data–who’s sending to whom and how much–remains in the 1 megabyte base block, while the signature data which verifies the sender’s eligibility to make such a transaction is appended to an extended block. Crucially, miners who haven’t upgraded to SegWit can continue mining under the old paradigm if they wish. It’s an upgrade for those who want it.

Really, then, SegWit wasn’t a rejection of a block size increase, it was a rejection of hard forking as a means of getting that done. A workaround, accomplishing what both sides were after: raising the effective capacity of the block, without actually raising its one megabyte limit.

Power Grab

Why wasn’t this enough for the SegWit2x supporters? Transaction throughput was about to quadruple. Now it needed to double again, three months later? Via a hard fork that would fracture the community in half? Questions like these made some in the No 2x community question the motives of SegWit2x supporters. If they were really trying to help, they would have collaborated with the user community, rather than alienating them. They wouldn’t stake Bitcoin’s future on a contentious hard fork. Maybe SegWit2x wasn’t meant to be an “agreement” at all. Maybe it was a blatant, open-faced power grab.

Hard forks can be good for that, after all. They’re a way of imposing will over a blockchain, whether you like it or not. In a hard fork there is no compromise–there are two blockchains, and they have to fight it out to survive.

Maybe the signatories of the New York Agreement would have preferred the user community to get behind their proposal. But it wasn’t actually necessary to accomplish their goals. With 80% of the mining power behind them, they could initiate the hard fork without user or developer support. When the two chains split, with the overwhelming majority of hashing power on their side, it’s likely that the SegWit2x chain would win out over the legacy chain. Then users would have no choice but to accept that SegWit2x was the new normal.

And it gets worse. There was ample evidence to suggest that SegWit2x wasn’t about upgrading Bitcoin at all, but transferring ownership from the many to the few. An exercise in determining who actually has the power to control Bitcoin, and who does not.

Replay Protection

Some of you might remember our Malicious Life episode about the DAO hack–when an investment pool running on the Ethereum blockchain got hacked, and the community had to decide whether to hard fork the blockchain in order to get millions and millions of dollars back from the hacker. In the end, the blockchain forked in two: Ethereum, with the funds returned to their original owners, and Ethereum Classic, without the change.

When hard forks cause splits like this, users actually get two copies of their coins–one for each chain. Why? Because the two chains only split off at a specific point in the blockchain. They each share the entire history of the chain up until that point, so however much you owned to that point exists, for you, under both paradigms.

One unintended consequence of the Ethereum hard fork was that it failed to implement one, key feature that protects users during hard forks. It’s what’s called “replay protection.”

Let’s say I owned one Ether before the split, and now I have one Ether in both Ethereum and Ethereum Classic. I decide to send Nate Nelson 0.5 Ether from my account on the old chain, as a bonus for being such a great producer. But it turns out he’s actually a very bad producer! He takes advantage of the hard fork by copying the transaction data associated with my payment on the old chain, and uploading it to the new ledger. Now I’ve paid him twice, the little runt!

How’d he pull it off? Well, he took advantage of what’s the same on both blockchains, and what’s different. What’s the same? One: my private key is the same on both chains. Two: all my transactions (before the DAO hack block) are part of both ledgers. Because of one and two: a transaction of 0.5 Ether sent from my key to Nate’s key would generate the exact same transaction data, whether it’s on one chain or the other. What’s different about the two chains? Only one thing: their transaction histories. The new chain can’t see what’s happening in the old one, and vice versa. So Nate is able to generate a transaction which checks out on the new chain, even though he simply copy-pasted it from the old one.

This is the kind of double spending that blockchain, as a concept, was designed to prevent. Like, the number one rule in blockchain is that you can’t double spend. But without replay protections in a hard fork, you can.

SegWit2x was a hard fork proposal without replay protection. That is – any users who will stick with the original BitCoin will be vulnerable to replay attacks, unless the BitCoin developers will modify the BitCoin Core software to defend against it. This can be viewed as a kind of a threat: it’s as if I bring a tiger to your house, and say – “If you’re so worried about getting eaten, you chain her. Or you can just leave your house, you know…” Actually, perhaps more accurately, it was a bet. A bet by the SegWit2x supporters on themselves: that they would be the ones dictating the future of Bitcoin, and their opponents would be the ones seceding to their will.


Theories abound that SegWit2x was nothing less than an attack meant to destroy Bitcoin Core. It was a power grab. It was a mass transfer of wealth to those with the means to affect change, from those without. It was a cyber attack.

A cyber attack? Indeed. Some community members were suggesting that SegWit2x was, in effect, the first major instance of the worst kind of scenario any cryptocurrency holder could fear: a 51% attack.

As you know by now, Bitcoin’s power lies in its decentralization. If a hacker wanted to forge a transaction to make themselves rich, the rest of the community would note the forgery and agree not to accept it onto the blockchain. The community has more power than the individual, so it’s easy to prevent the hack. Think of it like a group of friends splitting a pizza: nobody’s able to take more than their fair share, because everyone else has an interest in preventing that from happening.

A 51% attack can occur when one entity or coalition of entities owns enough of the mining power on a network to dictate its reality. If a hacker wants to forge a transaction, and they own over 50% of the network’s hash power, they’re going to be able to do so. It’s a group of friends sharing pizza, except one friend is Arnold Schwarzenegger. Even the rest of Arnold’s friends, together, won’t be able to stop him if he’s hungry after one slice.

Now think about what SegWit2x is: a proposal to change the network, backed by 80% of the mining power on the network.

In an op-ed for CoinDesk, Edan Yago, CEO of the Bitcoin startup Epiphyte, put it succinctly. Quote: “The 51% attack has remained a hypothetical bogeyman. Until now.” End quote.

Others, even its opponents, disagreed that SegWit2x constituted a 51% attack. Because the proposal involved a hard fork, they argued, the 2x miners would not actually be attacking the legacy chain–they would simply be abandoning it to create their own. Live and let live.

But what about if they went further than that? Miners, knowing they had an overwhelming majority as compared with the legacy chain, could easily attack the opposing chain by, counter-intuitively, dedicating their mining power to that chain, instead of the 2x one they actually preferred. With more than 50% of the power on the old chain, they could manipulate it to their will–changing transaction data, or even halting the chain altogether until it came to a still death.

In an op-ed for CoinTelegraph, David Dinkins (not the mayor) outlined what appeared to be a “probable outcome.” Quote:

If there are indeed two Bitcoins, one backed by the developers and the other backed by the miners, mass confusion and chaos are likely to ensue, as would-be investors won’t know which Bitcoin is the “real” Bitcoin. In order to solve this potentially devastating problem, it’s likely that the majority chain will attack and destroy the minority chain. The way that would work is simple: since 2x will have 85 percent of the miners, a small portion of miners can begin mining the legacy chain. At some point, they will launch a 51 percent attack against the minority chain, causing double-spends, Blockchain reorgs, and generally making the legacy network unusable.

End quote. Nobody knew what the miners would do. But, frankly, if they could destroy the old blockchain, forcing everybody who owned Bitcoin to adopt their solution, why wouldn’t they?

Purposeful Slowdowns?

This isn’t to say miners are all bad or exclusively self-interested–they’re not. But investors had reason to worry about how they might exert their power. In a Medium article, Sam Wouters–a blockchain public speaker–laid out a pretty good reason why.

Remember when we talked about how Bitcoin’s growing popularity was causing the scaling issues, which had been debated for years prior, to flare up in a way they never had before? More people were buying Bitcoin, so the price went up, so more people bought, and over time the transactions over the network caused major backlogs and slowdowns.

When a backlog occurs, transactions get stuck in what’s called the “mempool”–a purgatory where those transactions must live until a miner finally includes them in a block. Using the website, Wouters posted a graph of the size of the mempool from May, 2016 to July, 2017.

An interesting pattern emerged. Spikes in the size of the mempool started to occur in late 2016, but really, these were only temporary. The real, sustained spike only really began in May, 2017. Throughout the month of April, unconfirmed transactions fluctuated between 75,000 and nearly zero. By mid-May, the numbers began to shoot up: 100,000, 150,000. On May 20th, the peak there were nearly 200,000. A week later, after a month of sustained chaos, the number dropped like a stone. By June, it was back to 75,000. By July, nearly zero.

So what caused that spike? Well, I don’t want to say it. I’ll use the author’s own words. Quote:

A group of people desperately wanted to push their ideas to increase scalability. The moment a scaling solution [SegWit2x] was agreed upon behind closed doors towards the end of May, the attacks suddenly ended.

While some people were hopeful or deceptive about these spikes in unconfirmed transactions being organic growth, further analysis clearly shows it was spam.

To push people into increasing the blocksize, the attackers made it expensive to send bitcoin transactions for weeks in a row, by using up as much transaction space as possible through all kinds of constructions.

End quote. What does this mean? Well, what you’ve heard thus far is that Bitcoin’s popularity is what caused the giant backlog and high fees. That story made sense, so you believed it.

But if Wouters is right–which, we should mention, is hotly disputed– then maybe the narrative around Bitcoin’s scaling problems is flawed. Maybe the network in 2017 was, in large part, fine. Maybe the scaling problem became a scaling crisis through deliberate subversion of the network, by those with financial incentives, intended to trick the community into believing that a solution like the one they favored–SegWit2x–was necessary to solve the very problem they exacerbated.

This is getting ugly.