Who Asked Wlad? What Does Bitcoin’s Lead Developer Say About The Scaling Debate? (Exclusive)

[Original Photo by oreEphoto, Uwe Aranas / CC-BY-SA-3.0]

[Note: This article has been edited to further clarify the differences in the implementations of BIP100 and BitcoinXT.]

Speaking to CoinJournal, Bitcoin lead developer Wladimir van der Laan has reiterated and updated his stance on the Bitcoin scaling debate.

The debate over Bitcoin scaling, also known as the block size debate, the XT debate and a variety of other names, continues. It has broken off into several different proposals and factions and have spawned other debates over censorship in the community and governance of the technology.

Very little talk has been made what the official lead developer thinks about the situation. He has been regularly listed as being on the “against” side, and one easily accessible public statement on the matter, coming in the Bitcoin development mailing list, does have him coming out as “weakly against” raising the block size immediately.

But, that was in May, things have changed significantly since then. He has made very few public statements since, outside of a few comments on the mailing list in June, so I figured it was time to see if his opinion had evolved at all.

His email, sent to CoinJournal, reads in full:

“Yes. [my previous opinion remains]

I mostly have a problem with proposals that bake in expected exponential bandwidth growth. I don’t think it’s realistic. If we’ve learned anything from the 2008 subprime bubble crisis it should be that nothing ever keeps growing exponentially, and assuming so can be hazardous.
It reduces a complex geographical issue, the distribution of internet connectivity over the planet for a long time to come, to a simple function.

On the other hand a hardfork is extremely hard to coordinate. Even one that just involves changing one parameter. Everyone with a full node has to upgrade. This is not something that can be done regularly. Certainly not with such a near time horizon.

Changing the rules in a decentralized consensus system is a very difficult problem and I don’t think we’ll resolve it any time soon.”

Those comments seem to fall in line with his previous ones in May and June, that he is against a headlong rush into solving the bitcoin block size problem. That doesn’t mean he is against a block size increase at some point, simply that he is against the proposals made currently with strict deadlines.

The issue Wladimir seems to have with BitcoinXT and potentially BIP100 seem to be twofold. One, that he doesn’t feel it accounts for bandwidth issues and two, he feels that the hardfork both proponents are attempting are very dangerous. BIP100, it could be argued, is being attempting its hardfork through more traditional routes. Both are voted on by miners, but BitcoinXT, which is more than just BIP101, would also take control of “the valid” bitcoin from Wladimire (unless, as Gavin argued on Epicenter Bitcoin, it creates many different valid implementations of Bitcoin Core).

He was recently the first of 30 signatories on an open letter to the bitcoin community, published by CoinDesk, that seemed to issue caution and patience with the issue.

“To mitigate potential existential risks, it behooves us all to take the time to evaluate proposals that have been put forward and agree on the best solutions via the consensus building process.”

In his talk on Epicenter Bitcoin a few months back, one of XT’s strongest proponents Mike Hearn, talked about the need for open-source projects to have a strong leader, a benevolent dictator, as he called it. This sentiment was echoed when Gavin Andresen appeared on the same podcast a few days ago. In that, he seemed to imply that Hearn would take on that role for Bitcoin XT. Hearn and Andresen were not among the signatories on the open letter.

In an email conversation with Hearn, he expressed frustration with Wladimir’s apparent insistence on waiting until there is full consensus among the Core developers, but stated that even if Wladimir took the role of benevolent dictator, he would need to be removed from that role if he didn’t implement something that increases the block size.

“If [Wladimir] isn’t going to merge any block size increase[,] then he needs to make that much clearer to everyone. For instance, Jeff [Garzik] is currently implementing BIP 100 right now, perhaps on the assumption it will get merged. Pieter proposed BIP 101 after June.

And if that’s his position then indeed, he needs to go.”

I do not think that is Wladimir’s position, in fact, he has called a block size increase inevitable at some point, but it is something that he would like to hold off on for as long as possible and it is clearly something he wants to approach with abundant caution.

Proponents of the XT fork and many of the BIP100 proponents feel that there is no time to waste.

How Wladimir feels about the dynamic block size limit designed by Jeff Garzik, dubbed BIP100, is less clear. The lack of communication from Wladimir seems to be increasing the confusion and animosity from some of the other core developers.

One possible concern Wladimir could have with having miners voting on block size limits, and this is pure speculation, is that large mining pools could raise the limit continuously, which would make mining more difficult for smaller pools.

The BIP100 proposal has some safeguards in place, including the requirement that a super majority must be reached in order to raise the block size. Full nodes also play a big role in keeping miners honest and validating their transactions. Larger blocks would make it harder to run a full node and would potentially upset the balance of power in bitcoin by handing more power to the miners at the expense of people who would like to run full nodes. That likely wouldn’t be a huge issue if block size is determined through some sort of community consensus and full nodes can adjust their expectations and deal with it, but it could potentially be a larger problem if the group who has the most to gain from lessening the number of full nodes are the only people voting on the block size.

We will keep you up to date with the ongoing debate over block sizes