Segwit2X Discussion Emails

In response to a selectively leaked email thread on Twitter today, which takes my views out of context, I have decided to publish a series of emails written to a large group of people working on Bitcoin. The group comprises a number of Bitcoin industry folk and usually has healthy discussions.

These are excerpts from emails sent regarding Segwit2X, unmodified (with comments for context). I have not published any comments from others on the list, due to confidentiality and out of respect to them. This means that some references to previous comments may seem to be out of context or not read well.

Each post in this series follows a previous post, but with gaps for responses made by other people on the list.

— — —

August 9, 2017

How about another perspective on why not to abandon S2X, largely drawn from arguments I’ve seen against S2X:

If the legacy Bitcoin chain truly is anti-fragile, then it will survive Segwit2x.

If hashpower doesn’t dictate power (1 CPU, 1 Vote), then who cares if it moves to Segwit2x.

If a bunch of suits can subvert Bitcoin, then it wasn’t worth fighting for.

If users don’t want S2X, and the economic majority ultimately decides otherwise, this will be a non-event. Why fight it?

Sure there will be some disruption, but the real Bitcoin will survive, right?

— -

I have an unpublished blog post written months ago (which I showed to some core developers who hated it, so I decided not to publish it, I’ve had enough trolling). I wrote why we are in this predicament and why I’ve been opposed to any hard forks like BCH and S2X from the beginning but because it’s seemingly all black and white, 1’s and 0’s and game theory from the engineering perspective, that the way we shape the narrative and disregard the human element, means it really doesn’t matter (/sarcasm).

My view is that in pushing for the UASF, which was the trigger point for the current situation with S2X, we now have this situation and I warned against it. We have spent so much time focusing on minimizing code level and system level technical risks, that we didn’t appreciate that nascent systems need to balance technical with systemic and existential risks and trading off something, like a block size increase with a planned hard fork (Spoonnet or similar, say we months from now) would have been less risky than pushing for the UASF and alienating the mining community which rallied them around S2X in response to UASF. Again, I’m talking about non-technical risks which have come to the fore — ideologies which cause people to do irrational things, cannot easily be factored into game theory.

We need less mathematicians and more psychologists in our midsts…this is a people problem, not a technical one but given how things have played out to date, I don’t see us solving it, ala Einstein’s quote. If we didn’t have the mindset to appreciate how we got into this mess, we certainly don’t have wherewithal to get ourselves out of it…

“We cannot solve our problems with the same thinking we used when we created them.” — Einstein

August 9, 2017

Segwit2X has now really become about showing “Core” that if there is an unwillingness to trade off technical risks against systemic risks, and consider the people element of how Bitcoin evolves, then those who oppose that type of mindset will take a corresponding course of action to oppose them. This is not about logic or reason — it’s ideological. The same reason why people commit crimes in a fit of rage, even if it means consequences that are not in their self interest. Again, if you want logic and reason, stick to code and don’t try understanding people.

To me, it makes no sense in operating so conservatively by reducing technical risks to a point where over-optimizing for the technical risks create systemic risks which are, on balance, larger than the risk percentage being preserved on the technical side. That’s what has happened here and now that higher risk percentage is now looking scarier than what reasonable compromise should have been (Segwit + 2mb blocksize increase in 2018 through a well planned hard fork) — which would have (IMHO, prevented BCH & S2X). The UASF was the wrong approach — it was a forced measure, not a consensus driven one. The consensus was only obtained because of S2X. Reneging on that would have dire consequences now.

I’m reasonably neutral in all this. After investigating all the facts, I wanted status quo until there was consensus on Segwit with a well planned hard fork, but the UASF crowd triggered this divide, whether or not they are willing to accept it or now.

BIP148 was a potential disaster — we should be thankful to James for averting this, but in reality we just kicked the can down the road.

August 10, 2017

Segwit2x was not a compromise. It was a rebuke to the core developers in the face of their support for UASF. Not sure why anyone calls it a compromise?

The (truncated ) chain events was something like this:

HKA — Attendees agreed to a 2MB HF (not everyone was present or in a sound state of mind), but it is what it is. Clearly no quorum was present for this agreement.

BIP 9 — Core — “We want consensus to activate Segwit and other BIPs safely”

BIP 141 — Core — “We want 95% consensus from miners to ensure this is not contentious”

BIP 141 — Miners — “We won’t agree to this on the basis that there is no block size increase as promised at HKA. Let’s discuss and compromise”. (At this point there was an unwillingness to compromise on a 2mb increase).

BIP 148 — UASF crowd — “F*&^ the miners and 95% consensus, we didn’t need you anyways, “users” are in control and they can activate without you. Take your ASICBoost technology and stick it!”

Segwit2x — Miners — “Well, if you think we’re just dumb miners, we’ll work with the business community to move our hashpower that secures Bitcoin to a chain that Core has no control over and can implement a reasonable block size increase.”

BIP 91 — James H (sensibly) : “Look, it’s we going to diverge on beliefs, let’s do this safely right now and agree to prevent a chain split on Aug 1, at the very least, and kick this can down the road.” | Segwit2x Crowd — “OK, let’s agree on this point and activate Segwit safely”.

Post Segwit — Core/UASF crowd : “Thanks for the activation of Segwit, now WTF are we still doing Segwit2x?!”

Not saying that I agree with all the above in terms of approach, but I’m just pointing out that at a high level, that’s essentially what has happened (open to major corrections, but this jist seems directionally correct).

Now, many are arguing against the merits of increasing the block size — not looking at how we wound up here in the first place.

Frankly, I think it’s probably too late because Segwit was only activated under the pretext that the miners would get Segwit2x. I concur that we don’t need a blocksize increase in the current environment and a 2mb hard fork makes no sense and is risky, that’s if you look at it technically, BUT as I have stressed, considering the social aspects of what has transpired, I don’t think there will be a choice — we passed the point of no return on Aug 1 when the UASF crowd effectively forced Segwit under duress.

If Segwit2x is reneged upon, then essentially all trust between miners & the rest of the community with be in tatters — good luck fixing the mess that will ensue.

There may be other solutions (skeptical, but possible), and I’m happy to try and brainstorm them if anyone is interested, but we have to accept that this is a very detailed and complex issue and if we were just dealing with robots, we probably would not have had this issues.

Again, I am the guy who has been arguing for no hard forks and no UASF — and a peaceful resolution. I’m just trying to explain how we got into this mess, from my perspective. Please correct me where I am wrong.

Vinny Lingham
13 min
10 cards

Read “Segwit2X Discussion Emails” on a larger screen, or in the Medium app!