SegWit + 2mb & the Wrong Way to Go About It.

There is a thing that has happened lately in the Bitcoin community. Something to stir the waters in the scaling debate.
A group of very prominent figures in the Bitcoin community met up, in an invite only meeting at Consensus 2017 to discuss the scaling debate.

The idea behind this meeting was to find a compromise in the Bitcoin scaling debate. The result: Bitcoin Scaling Agreement at Consensus 2017.
The agreement is to signal for SegWit, which would activate at an 80% threshold followed by a 2mb hard fork, also activated at an 80% threshold.

It is based on the a proposal by Sergio Demian Lerner.

I think it’s great that people are trying to get to consensus on this matter but I also believe that this is the wrong way of doing it. To hold closed door meetings to discuss the way forward for a community driven project, is not in the spirit of OSS. Another problem, is the severe lack of code. There is a short medium blog post about this, showing that there are some CEO’s who want this scaling debate to go into a certain direction, but we have not seen them provide any code. They claim they will provide the “resources” to do so, but that’s left to be seen.

In the OSS community, your proposals hold as much water as the underlying code. If there is no code, the proposal is dust, nothing more than a forum post. Without the code, people cannot do much and you cannot force a group of developers, unless you can incentivise them (them being on your payroll is a good incentive for them, for instance) to do so.

For instance, Linux has always had some very sketchy GPU driver support, because the vendors haven’t cared that much. Because of this, there are quite a few bugs in the GPU drivers today. If I would like to solve one of the problems found in the GPU drivers, I’d need to propose a fix to the community. I could do this in two ways.

  1. Write a lengthy blog post on how it should be fixed and expect somebody else to write the code, review it, submit it and get it into the next GPU driver release
  2. I could write the code myself and submit that as my proposal to fix it, allowing other developers to comment on it, fix/improve it and expand on it.

I don’t suppose anybody would pick the first option as the better between the two. What you’d most likely see, is that the first option becomes nothing more than vaporware; people read it, agree and move on with their lives. Somebody may take it upon themselves to fix the issue based on option 1, but they inadvertently place themselves into the second option and the original blog post served as nothing more than confirmation that the problem exists.

Which is why this agreement is total nonsense until the members of the above signed agreement can provide actual, peer reviewed code, which can be dissected and implemented into Bitcoin. Relying on others to do this for them, is a waste of time.

The other problem with this, is that they seem to think they represent the Bitcoin community. Which they do not. They represent their companies and the interests of their companies. This does not translate into “The Bitcoin Community”. The Bitcoin community is made up of the economic nodes currently running (as well as all of the Bitcoin users). Those people who actively participate in the network by growing it, validating transactions and strengthening the network by providing more decentralisation. There are roughly 6500 nodes currently running in the world. Even if these companies control 100 or 500 of those nodes, they would not even represent 10% of the Bitcoin community that run these nodes. In other words, they cannot speak on behalf of the 6500 nodes in the world.

The only way they could claim that they speak on behalf of the community is if they could independently prove that they have buy in from nearly (let’s call it 80% of their users to fall in line with what they expect from the community) all of their users. Which I don’t think they can. So they’re taking a decentralised system and deciding that CEO’s of companies within the space, should steer Bitcoin’s direction.

This is a matter of principles and I am not attacking the companies, nor their CEO’s, nor the actual agreement. I think they are doing what they know best to solve the situation that we find ourselves in. Which is great, we need to find agreements and move forward. But how they are going about it, is short sighted and only makes sense if Bitcoin was a company. i.e. Board of directors get together, discuss and decide on a direction. Which is not OSS. Thank goodness otherwise we’d all be running Windows these days.

We need activity in the scaling debate to move it somewhere. But we need the right activity.

Furthermore, they refused to allow Blockstream, which funds two of the Bitcoin core developers, to be a part of the meeting. Which is interesting, considering the fact that it would have been really useful to include some Bitcoin developers in this discussion, who have some real in depth knowledge of the Bitcoin protocol and could highlight potential ways of rolling out their plans. Instead they uninvited them and decided that they did not need them. However, they will probably expect core developers to code this for them. At the very least, audit it. I have to take the time to point out that Blockstream != all core developers. They represent a minority of the core developers and haven’t really submitted that much code. How much they influence the code, is another story. The point here, is that they probably should’ve had some Bitcoin developers present.

Some other noteworthy facts:

Roger Ver’s undertaking (Bitcoin.com) signed the agreement — Yet he claims he wasn’t there?
Jihan Wu’s company (Bitmain) signed the agreement — Yet there seems to be a disconnect between what the agreement says and what he says should happen

If Bitcoin wants to move forward with this proposal, we need the code for it.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.