inamerrata

Ambiguous titles are tight.

I’ve always been a little puzzled by the way the segwit/uasf/uahf/segsignal drama played out back in 2017 — there was a lot of drama about the UASF for a while, and then, when push came to shove, suddenly miners switch to being 100% in favour of it, and there were no problems at all. There was even the opportunity for a bit of a last minute “screw you”: BIP91 could have been activated so that it only locked in after BIP148 activated, potentially resulting in a segwit-enforcing chain that wasn’t valid according to BIP148 — not quite “if I can’t have it, nobody can”, but at least a way to get a final punch in prior to losing the fight. But it just didn’t happen that way.

So what if “losing the fight” wasn’t really what happened — what if the fight had been fixed right from the start?

I think that was a day or two before Greg posted about ASICBoost to the bitcoin-dev list — which is interesting since, prior to the ASICBoost factor being revealed, I don’t think the UASF approach had all that much traction. For example, here’s ebliever commenting on reddit in response to the ASICBoost reveal:

I didn’t like the UASF when first proposed because it seemed radical and a bad precedent. But given the crisis if Bitmain can’t be stopped in short order, to save the rest of the mining industry I’d favor the UASF as an emergency measure ASAP.

Why reveal plans for a UAHF to defend against a UASF before the UASF even has significant support?

Well, one reason might be that you wanted to do a UAHF all along. The UAHF became BCH, and between August 2017 and November 2018, BCH had the “advantage” over regular bitcoin in that you could do covert ASICBoost mining on it. (In November 2018 BCH was changed in a way that also prevented covert ASICBoost, and wonder of wonders, a new hard fork of BCH instantly appeared, BSV)

After all, there weren’t many other outcomes on the table that would have allowed covert ASICBoost to continue — the New York Agreement was aiming to do bigger blocks and segwit which still would have blocked it, the “Bitcoin Unlimited” split had basically failed, and stalling segwit probably wouldn’t work forever

There’s a history of the BCH fork from Haipo Yang of ViaBTC. I think it’s pretty interesting in its own right, but for the purposes of this post the interesting stuff is in section 2 — with Bitcoin Unlimited failing to achieve a split occuring just prior to that section. In particular, it includes the argument:

Fortunately, small-hashrate fork can be done without others’ support, and it seemed to be the only feasible direction for the big-block supporters.

Even at this time, most of the big block advocates still placed their hope on the SegWit+2MB plan reached by the New York Consensus. I made it clear that this road was not going to work

It also gives the following timeline leading up to the BCH split:

Wu Jihan has got a Plan B. While supporting the New York Consensus, he took the small-hashrate fork as a backup. […] At that time, the core members of the Core team launched the UASF (User Activated Soft Fork) campaign, and planned to force the activation of SegWit on August 1, 2017. So we decided to activate UAHF (User Activated Hard Fork) on the same day.

So at least according to that timeline, the NYA was already written off as a failure and the BCH UAHF was already being worked on prior UASF being a thing, and picking the same day to do the UAHF was just a matter of convenience, not a desperate attempt to save Bitcoin from a UASF at all. That’s not confirmation that the UAHF was planned from the start in order to save covert ASICBoost — but it is at least in line with the argument that UAHF was the goal all along, rather than a side effect of trying to oppose the UASF.

The thing is, that leaves nobody having been opposed to the UASF: the BCH camp was just using it as a distraction while they split off for their own reasons; the NYA camp were supporting it as the first step of S2X; conservative folks thought it was risky but were happy to see segwit activated; and obviously bip148 supporters were over the moon.

And that’s relevant today to discussions of the “bip8 lot=true” approach, which proposes using the same procedure as bip148 — by some only as a response to delaying tactics, by others as the primary or sole method.

Because despite there being claims that running a UASF client has no risks, that is fundamentally not true. There are at least two pretty serious risks: the first is that you’ll go out of consensus with the network, nobody will mine blocks you consider valid, and that you’ll be unable to receive payments until you abandon your UASF client — that alone is likely enough risk for businesses and exchanges to not be willing to run a UASF client; and the second is that people split down the middle on supporting and opposing the UASF and we have an actual chainsplit, resulting in significant work as one or both sides figure out how to avoid being spammed by nodes following the other chain, add replay protection and protect their preferred system from suffering from a difficulty bomb that makes it uneconomic to continue mining blocks.

All of that’s fine if you’re confident any UASF you support will easily win the day — shades of Trump’s “trade wars are good, and easy to win” there — but if you’re relying on the experience with segwit and bip148 as your evidence that UASF’s will easily win, perhaps the above is some cause for doubt. It is for me, at any rate.

(Of course, not being easy to win, doesn’t mean unwinnable or too scary to even risk fighting; but it does mean building up your strength before picking a fight. For bitcoin, at a minimum, that means a lot more work on making p2p robust against the potential of a more-work invalid chain that your peers may consider valid)