Bitcoin's lead developer Wladimir van der Laan offered new insights into the block size debate when speaking with MiningPool, clarifying his position as the scaling dispute continues to fracture the
Bitcoin's lead developer Wladimir van der Laan offered new insights into the block size debate when speaking with MiningPool, clarifying his position as the scaling dispute continues to fracture the community.
The controversy splits developers into competing camps, each backing different technical proposals. Ancillary conflicts over censorship and governance have emerged alongside the central technical disagreement. Few in the community have bothered asking what the official lead developer actually thinks.
Observers tend to group him with the skeptics. His most visible public comment came in May on the development mailing list, where his position was "weakly against" raising the block size immediately. Since May, he's offered almost no public comments—only a few remarks in June—so the question arose whether his thinking had shifted. His response to MiningPool, quoted 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."
The statement echoes his earlier comments. He opposes hasty responses to the block size problem but hasn't ruled out increases down the road. His actual grievance targets the proposals now circulating, particularly their compressed timelines. He sees two main issues with BitcoinXT and potentially BIP100: they ignore bandwidth constraints, and the hardfork mechanisms both camps are pursuing carry substantial risks.
BIP100, by contrast, pursues a more conventional route. Miners vote on both proposals, though BitcoinXT extends beyond BIP101 and would seize "the valid" bitcoin from Wladimir's authority—unless, as Gavin Andresen suggested on Epicenter Bitcoin, it spawns multiple competing implementations of Bitcoin Core. Last month, Wladimir became the first of thirty signatories on an open letter to the bitcoin community published by CoinDesk. The letter urged caution: "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."
Mike Hearn, speaking on Epicenter Bitcoin, stressed that open-source projects require strong central authority—a "benevolent dictator," as he called it. Gavin Andresen made the same point when he appeared on the podcast days later, implying that Hearn would fill that role for Bitcoin XT. Neither Hearn nor Andresen signed the letter.
In email correspondence, Hearn voiced frustration with Wladimir's apparent insistence on waiting for full consensus among Core developers. He suggested that even as a benevolent dictator, Wladimir would need to step aside if he refused to implement any block size increase:
"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 don't read Wladimir's stance that way. He has stated that a block size increase will happen eventually, but he wants to postpone it as long as possible and move with extreme caution. The XT camp and many BIP100 backers feel time is running out. Wladimir's precise objections to BIP100 remain unclear. His limited public communication has fueled confusion and resentment among other Core developers.
One potential concern—and this is speculation—involves giving miners direct control over block size limits. Large mining pools could vote to raise it continuously, which would squeeze smaller pools out of competitiveness. BIP100 includes safeguards: miners must reach a supermajority to increase size. Full nodes serve another check, validating transactions and monitoring miners. Larger blocks raise the cost of running a full node, which could shift power toward miners and away from those running full nodes.
This wouldn't pose much risk if the community reached genuine consensus on block sizes, allowing node operators to adapt. But if the group with the most to gain from fewer full nodes controls the vote, the power imbalance becomes problematic.
