BTCC’s Sampson Mow on Block Size: The Bitcoin Community Must See Through Manipulation, Keep Calm and Write Code

Samson Mow is the Chief Operating Officer of Chinese Bitcoin exchange, wallet service and mining pool BTCC. A successful executive in the video game industry, Mow joined the Bitcoin company run by his friend and CEO Bobby Lee as an adviser last year, and has gotten further involved with the company ever since.

Mow has actively engaged himself in the block size dispute over the past months. He played a key role in realizing both the Bitcoin Roundtable letter, as well as the Hong Kong Roundtable Consensus.

But his real claim to fame in the Bitcoin space might actually have been a seriesoftweetstorms – lauded by some, dismissed as unprofessional by others. Bitcoin Magazine interviewed Mow on, among other things, his newly heightened media profile and his perspective on the block size dispute.

Samson, until recently you were a somewhat calm executive not many people in Bitcoin had heard of. If nothing else, your Twitter escapades have hurled you into the center of attention. What’s gotten into you?

On Twitter I’m mostly satirizing the situation. It’s become too ridiculous. Everything gets turned into a conspiracy theory and people are quick to dismiss anything that doesn’t align with their views. Between all of the misinformation and claims without any factual basis, we have passive aggressive attacks on the Bitcoin Core development team as well. There’s not much else you can do aside from laughing at the situation.

You used to be quite critical of the Bitcoin Core development team yourself. Last time we spokeyou even said that stakeholders might implement a block size limit increase if Bitcoin Core reached no consensus.

The key message was that something needed to happen. The community was frustrated, and I was frustrated as well.

That interview actually lead to a three-hour call with Blockstream president Adam Back, where I gave Adam a lot of criticism about Core in general, but mainly about how they were not communicating well enough. He was receptive to my feedback, as were Core developers, and they have indeed improved their communication significantly since.

I also managed to get a better understanding of how the Core developers actually work together, and came to the conclusion that a lot of the frustration was misplaced. I learned that I couldn’t actually complain to just Adam and expect things to be magically resolved. Core is a very diverse group of individual volunteers as well as companies that donate the time from their employees. There are also a lot of differing opinions within the group. They can’t simply react to people’s feedback – there’s no mechanism. It’s just a bunch of guys that want to write code and solve problems pertaining to Bitcoin. There’s no one in charge.

Wladimir van der Laan is in charge.

Wladimir merges code, as he is the maintainer, but he doesn’t make decisions on anything without the group’s rough consensus. That’s actually something people have criticized him on – that he is too cautious, and things are not getting anywhere because he doesn’t take a decision on matters.

Well, he is the one who decides when rough consensus is reached.

I don’t think he is the judge. He is a facilitator. If he would merge code without consensus, there wouldn’t be many developers left in the project.

Now we’re stuck at an artificial 1-megabyte block size limit. But in December weren’t you in favor of a short-term bump yourself?

Satoshi Nakamoto set the block size limit at 1 megabyte to prevent spam. But the block size limit has another function; it maintains a low bar for anyone to run a full node, which serves to promote decentralization. Last time I checked, an important property of Bitcoin is that it is decentralized.

My initial preference was to do a hard fork first, but since then I’ve learned a lot more about Segregated Witness and why it needs to come first: to prevent certain attacks. If we don’t focus on these weaknesses, we may end up seeing more problems, like manufactured transactions that destabilize the network.

The Core developers want to both maintain network security as well as decentralization, so naturally they are cautious to increase the block size set by Satoshi. They are also actually increasing the effective block size with Segregated Witness. And as part of the Hong Kong Roundtable Consensus, some have already committed to a hard fork for another increase. I’m not sure how you can call that artificially restraining the block size.

Some say the limit is being kept in place by a small group of developers.

Well, if you define “small group” as the Core development team, which is about 80 contributors, then technically you could say they are keeping the block size limit in place.

However, they can only keep it in place as long as there is consensus to do so – and there is, because it benefits the entire Bitcoin ecosystem. If the Core developers just decided to raise the block size limit to 8 megabytes today, miners would block that unanimously because it would be a massive detriment to mining.

Now, if you changed your question slightly, you could state “the 21 million coin limit is being kept in place by a small group of developers.” If you look at the question from that perspective, then you’ll see that the Core team is not keeping anything in place. It’s ridiculous to think they alone could enforce the 21 million coin limit – it’s the ecosystem enforcing the limit.

You were referring to the Hong Kong Roundtable Agreement. How did that come about?

It started with the Bitcoin Roundtable that BitFury organized at the North-American Bitcoin Conference, followed with a series of calls discussing the issues amongst many stakeholders, and after that, the publication of the “A Call for Consensus” letter. We then heard from Pindar Wong – a Scaling Bitcoin Workshop organizer – who offered us some space for meetings. Kang Xie, an active member from the Bitcoin community, played a very important role in setting the stage.

The meeting itself was very ad hoc. Many people, including myself, only confirmed that we would attend a few days prior – or on even shorter notice. We just decided to meet and discuss the issues, with the hope that we could avoid a contentious hard fork. The fact that we were able to come to an agreement and produce a letter, well, that’s actually really amazing.

No one from the Bitcoin Classic team attended. Was that your intention?

Our goal was to keep this a very small meeting with a razor sharp focus: figure out what it would take to have a hard fork from the Core team and avoid a network split. We wanted to cap it at 20 people but ended up with around 24.

We didn’t want to bring non-developers or people who would not contribute to the discussion in a meaningful way. After some discussion we did extend invitations to Bitcoin Classic developers Gavin Andresen, Jeff Garzik and Jonathan Toomim.

But only on very short notice ….

Sure, but this was not a conference. As I said, it was an ad hoc meeting. A lot of people decided at the last minute to attend. The Bitcoin Classic developers did not. I believe some of them attended the Financial Crypto conference in Barbados instead.

It must not have been easy to come to consensus in Hong Kong?

It wasn’t easy at all. The single biggest issue that kept popping up was the actual increase of the block size limit. That’s why we settled on “around 2 MB” for the purpose of finishing the letter. If we settled on a base block size of 2 megabytes, the effective size with Segregated Witness would be 3.6, and possibly 8 under adversarial conditions. But we won’t really know the exact size without more discussions between developers and the mining community. If miners and pools are OK with 2 megabytes, that will be fine, but it could end up being slightly smaller.

People with a simplistic understanding of Bitcoin want a block size that’s easy to understand, like 2. But it’s just not that simple. We’ve long passed the point where the block size can just be [an] arbitrary number – that was during the time of Satoshi. We’re now at the point where block size should be determined by technical and network constraints.

Moreover, people need to stop focusing on the actual block size and start concerning themselves with the number of transactions per block, which is what really matters.

Not everyone seems very happy about the outcome, though. At least two pool operators – F2Pool’s Wang Chun and AntPool’s Jihan Wu – indicated they want their hashers to vote?

Everyone is a bit frustrated, but there is no problem with them offering their users a chance to vote. F2Pool is technically not running Bitcoin Classic. Maybe there was a bit of misunderstanding there … or a bit of a loophole in the agreement. We agreed to give Core more time. I have faith that everyone will keep their word and stick to the commitments made in the letter.

The Bitcoin Core developers present at the Roundtable signed on their own behalf, not on behalf of Bitcoin Core. What if there’s no consensus among Core developers by the time the hard fork should roll out?

Yes, they committed as individuals. As mentioned before, Bitcoin Core is not a monolith – it’s not a company. The Core contributors present could not speak on behalf of other contributors any more than we could speak on behalf of KnCMiner, who did not attend.

It was actually Bitcoin Core developer Peter Todd who led the charge on committing as individuals. He made a bold move and said he would commit to the dates as part of the agreement. He and AntPool’s Jihan Wu both made a huge effort to bring people together toward the end of the meeting.

As for consensus among the Core development team … we’re giving them time to decide amongst themselves. Ultimately, it is really up to them as to what happens next. We have high hopes they will agree with the opinions of the contributors that signed, and some – like Wladimir – signaled that they do support the agreement. What’s ultimately going to end the debate is code being written.

While an important achievement, the Hong Kong Roundtable was only among a relatively small group of people. What about the rest of the community? What about other companies and miners, not to mention users?

The Roundtable group is doing everything we can to bring together more of the industry players, but it’s an uphill battle.

For users, we need a method to signal what they actually want. This was discussed as part of a hard fork plan – maybe some way to let users vote with their bitcoins. There’s nothing concrete yet. 

Ultimately, it’s not a given that the rest of the community will support the Hong Kong agreement. If it were a given, then Bitcoin would be easy to change, and no longer unique or special. 

At least a part of the community is already disagreeing. They think Segregated Witness won’t be ready in time, and the hard fork will be too little, too late.

It’s never too late. The important thing is that the community needs to understand it’s being manipulated.

By whom?

The Bitcoin Classic team and their supporters. It’s a play for control and influence. Potentially over Bitcoin itself.

They’ve turned a seemingly innocuous issue, the block size debate, into a vehicle to compromise consensus rules. That’s a very slippery slope and dangerous precedent.

They’ve listed supporters on their website who had no idea they were listed, or companies who said they supported a 2 megabyte increase, not that they supported a hard fork by Classic.

We’ve also been seeing a huge spam attack on the network at the same time these people were screaming that we are hitting the current block size limit. Either they were in on the attack, or they are oblivious to the fact that there was an attack – both of which don’t reflect well on them.

They then direct blame to the Core developers, and present themselves as the saviors of Bitcoin. Bitcoin is not easy to fully understand – even some executives of major Bitcoin companies have absolutely no idea how Bitcoin really works. So, if you have these people oversimplifying scaling issues to be just an increase from 1 to 2 megabytes, most of the community will not know any better and just follow along. It’s easier to be outraged than logical.

Blocks were indeed filling up for a couple of days. But who gets to say if something is spam, or legitimate use of the Blockchain?

It’s an attack if some person or group is intentionally disrupting normal operations for most people on the network. We’re seeing wallets sending coins to themselves over and over, spending unconfirmed transactions repeatedly, sending a high volume of low fee transactions, and constantly requesting large blocks to max out bandwidth.

Sure, you can say that these are not attacks and we should allow everyone to use Bitcoin as they see fit, but let’s try a simpler example. If someone loots all the toilet paper from the public toilet, is that a bad thing? Is the solution to double the amount of toilet paper stocked each day?

Putting the attack aside, block space is a limited resource. Increasing the block size to 2 megabytes doesn’t solve anything. There will always be ways to spam transactions as long as the attacker is willing to pay. We need smarter ways to filter out non-standard transactions and wallets that are smarter at estimating fees, but fees will always and must be a factor in getting transactions into blocks.

Are you saying it’s OK to price people out of transacting on-chain?

If Satoshi intended that everything should be done on-chain forever, there would be no block reward halvings. A better term for the block rewards is “block subsidy.” Everyone pays low fees now because their transactions are subsidized by the block rewards. Since block space is a limited resource, you have to be willing to pay for it – this is the fundamental concept of economics: supply and demand.

If people insist that everything must be on-chain and free, they are welcome to provide that service – they can invest a few million dollars to build a data center, buy mining equipment, and then mine low fee transactions as a public service.

Your company introduced a service called BlockPriority, which guarantees that transactions to and from BTCC are included in the first block BTCC mines. Bitcoin Classic developer Gavin Andresenpointed outthat is a symptom of an unhealthy network that is becoming increasingly unreliable and vulnerable to attacks.

BlockPriority does not offer any indications whatsoever about the health of the Bitcoin network.

BlockPriority is, however, indicative of vectors for spam attacks on the network that have yet to be patched, the need for better methods for estimation of fees, and the need for Bitcoin businesses to adopt Segregated Witness which will increase block size.

Ideally we wouldn’t try to make everything about block size. But I guess if all you have is a hammer, everything looks like a nail.

Well, obviously some people do believe that an increased block size limit is the solution Bitcoin needs right now. Bitcoin Classic is offering a concrete alternative. What’s wrong with that?

Classic has been marketing their hard fork as consensus, when consensus just wants a hard fork, not their hard fork.

Classic’s hard fork is an assault on the network, and it is contentious. There are people that say it doesn’t fix the attack vectors that Segregated Witness addresses. There are people who don’t have confidence in the team behind the project, as it’s been constantly changing in just the few weeks they have been together. There are people who think there’s no real solution in Classic and that their roadmap lacks substance. There are people, like myself, who think the 75 percent mining threshold is too low for activation, and that the 28-day grace period is an irresponsibly short time for people to upgrade. And there are Core developers who say they will cease working on Bitcoin if a small vocal minority can co-opt the project by changing consensus rules.

Bitcoin Classic represents a small minority?

Yes. We have the Hong Kong Consensus to show there is broad support for a hard fork done together with the Core team.

Bitcoin Classic has gathered a lot of support as well, though. And Gavin Andresen even led the Bitcoin project for several years… surely you’re not questioning his expertise?

I actually do question his expertise post BIP 101 and Bitcoin XT. It would have been a disaster if that was adopted. The proposed exponential growth for block sizes would have probably destroyed the network. In fact, even the initial bump to 8-megabyte blocks would have been too big for the network to handle, but it was marketed to everyone as being a safe solution for scaling.

Gavin played a very important role in Bitcoin’s formative years. However, he stepped away from being the maintainer, and largely has not contributed much since then. There are a lot of new people who are actively working on Bitcoin to address security issues and even more who are coming up with ways to extend it past layer 1.

The way I see it, Gavin took care of Bitcoin while it was an infant, and I think we are all appreciative of that. However, now we have people who are teaching that child physics and chemistry. The codebase has been largely re-written. We’re doing a lot more advanced features and will need to do far more to ensure its growth – we cannot only look to past contributors for guidance.

So where do we look for guidance within the mess that this block size dispute has become?

We need to look to the people who are actively contributing, either through writing code, donating time or funding development. We need to look to the people who are focused on solving difficult technical problems. We need to look to the people developing new technologies like the Lightning Network. Most important, we need to look to those who are trying to be collaborative and productive.

I believe cooler heads will prevail. What we have is a very loud, and very vocal minority trying to cause a commotion. As long as the community can see through the manipulation, keep calm and write code, we can move forward.

The post BTCC’s Sampson Mow on Block Size: The Bitcoin Community Must See Through Manipulation, Keep Calm and Write Code appeared first on Bitcoin Magazine.