Satoshi Roundtable Thoughts

I participated in the “Satoshi Roundtable” event in Florida last weekend on my way home from the Financial Cryptography conference.

The Roundtable is an invitation-only event organized by Bruce Fenton (current Executive Director of the Bitcoin Foundation, but it is not a Foundation event), and I’m told that in past years it was mostly a relaxed networking/socializing event.

This year, discussion of the the block size limit dominated the entire weekend.

All of that discussion happened under the “Chatham House Rule” – “…participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed” – so for the rest of this blog post I will talk about what happened and what was said, but won’t mention any names or affiliations. You can see who attended at the event’s website.

There were a couple of key moments that I remember. At one point, everybody was asked if they supported the “Hong Kong compromise” from the week before (segregated witness in April, then code for a 2MB hard fork in July of 2016 with a minimum of a year before 2MB blocks are allowed).

“Everybody who support that, raise your hand” : a dozen or so people, most of whom were part of that Hong Kong meeting, raise their hands.

“Everybody who does not support that, raise your hand” : everybody else (forty? fifty people?) raises their hands.

There was a lot of talk about moving the July of 2017 date closer. In particular, a plan was presented that had a three month grace period after 95% of hashpower voted yes and 75% of coin-age-weighted-transaction-volume-in-some-time-period also indicated support.

A subset of people spent several hours talking about the details, but reached no consensus. 95% miner voting is a problem for some miners, who don’t want to have veto power over such an important change. The chances of extortion either against them (“vote the way I want or I will DDoS you off the Internet”) or by them (“If you want me to vote a certain way, pay up”) are just too great.

And while the 75% coin-age voting is an interesting idea, actually agreeing on the details (Is there a fixed time period when the vote happens? A sliding window with a deadline? Should it be 75% of total transaction volume or just 75% of the volume that bothers to express a preference? Should it be 25% can veto instead of 75% needed to approve? Is this meant to be a vote or just a signal that people have upgraded?) and then writing and reviewing the code would take months.

Over the last year of trying, and failing, to reach a reasonable compromise, it has become clear to me that some developers don’t want any on-chain scaling solution any time soon. They believe more theoretically elegant (but technically complicated) off-chain solutions like the Lightning Network are a better long-term scaling solution, and they believe that by resisting a simple limit increase we will get to that long-term solution faster.

They are wrong.

If the block size limit is not increased, we will see more off-chain solutions. But they won’t be the Lightning Network– instead, we will see highly centralized “clearing” agreements between exchanges and miners and merchants or merging of miners and transactions creators.

We can see this start to happen– BTCC is a large exchange and mining pool, and announced “BlockPriority” last year for its customers. I don’t blame BTCC at all for doing that, it makes perfect business sense.

It is, however, a symptom of an unhealthy network that is becoming increasingly unreliable and vulnerable to attacks.


Brian Armstrong and Bruce Fenton also wrote about this year’s Satoshi Roundtable.

 
906
Kudos
 
906
Kudos

Now read this

A Guided Tour of the 2mb Fork

Increasing the block size limit from 1 million bytes to 2 million bytes sounds so simple: just change the “1” to a “2” in the source code and we’re done, right? If we didn’t care about a smooth upgrade, then it could be that simple. Just... Continue →