Set to offer an effective block size limit increase, a transaction malleability fix and more, SegregatedWitness (SegWit) could soon go live on the Bitcoin network. Starting tonight, miners can signal support for the proposed centerpiece of Bitcoin Core’s scalability roadmap. The soft fork will activate if 95 percent of hash power agrees.
But Chinese mining pool ViaBTC, currently representing some 8 percent of hash power on the Bitcoin network, has indicated it will not support SegWit activation. Instead, the mining pool favors a hard fork to remove the one megabyte block size limit, as proposed by Bitcoin Core fork Bitcoin Unlimited.
To learn more about ViaBTC’s motivation, Bitcoin Magazine reached out to CEO Haipo Yang.
Haipo, you’ve made it clear you want a hard fork to increase the block size limit. Why do you consider this necessary?
The past seven-year history of Bitcoin has proven that on-chain transactions are successful and needed by users. I think a hard fork to increase the block size limit is the only way for Bitcoin to develop moving forward, and the only way to preserve the bitcoin mining business model. I support a hard fork to stop Bitcoin from marching towards extinction.
Since blocks first started filling up about a year ago, the bitcoin price has doubled. How does this indicate “a march towards extinction”?
What influences short-term fluctuations in the bitcoin price comes from speculators rather than from fundamentals like transaction throughput. Bitcoin was valued over $1000 at one point. A rebound to $700 doesn’t seem all that unusual.
Academic analysis suggeststhat Bitcoin needs a block size limit to guarantee miner income in the long-term. Wouldn’t you rather find out how much users will pay for transactions before worrying about Bitcoin failing?
I think by the time we find out, it will be too late. Bitcoin offers no benefits over most altcoins other than a first-mover advantage and security. And Bitcoin can lose both these advantages. If there’s not enough capacity, people will use Litecoin instead — or Ethereum or Zcash, or another altcoin, and Bitcoin will be done for.
Do you see increased transaction throughput in the short-term as the only road to success? For example, consider the “digital gold” value proposition, which doesn’t require as many cheap, on-chain transactions.
Is Bitcoin a currency or a commodity? In my view, this is a bit like the relationship between water and a boat. If bitcoin does not have widespread acceptance as a currency, then its value as a commodity is an illusion. Limiting Bitcoin’s capacity is therefore a ridiculous strategy. It’s as if Facebook would have continued to only let users with a .edu email address register. If they had done that, there wouldn’t be a Facebook today.
In your analogy, Facebook could just rent another server in order to meet capacity. Increasing the block size presents a burden to each Bitcoin node. If you want to keep Bitcoin decentralized, it’s not as easy to scale.
The large majority of Bitcoin users have no need to run their own nodes. By design, Bitcoin allows users to make choices when it comes to speed, convenience and trust. They can use a light wallet. The trade off for that convenience is that they give up a very small amount of trust.
They give up this trust to miners. Don’t you think that having to trust third parties — in this case, miners — is against a principal goal of Bitcoin?
Based on the current quality of hardware, I don’t think increasing the block size up to four megabytes will be a problem for the foreseeable future. Users would still be able to run full nodes if they want to.
But surely you don’t think that four megabytes will be enough to meet any and all eventual demand?
We don’t know how many potential Bitcoin use cases there are, and what scenarios they will be applied to. Perhaps we’ll find that four — or maybe eight — megabytes actually is enough. What we do know is that one megabyte blocks can’t meet present users’ demand — and Bitcoin must scale.
Many use cases can also be realized through added layers. Some of these layers already exist, like ChangeTip or Coinbase’s off-chain transactions. And trustless layers like the lightning network are in production as well.
I don’t deny that the lightning network and other second layer technologies have benefits. And plenty of off-chain transactions are indeed already happening, for example in exchanges. But many Bitcoin transactions also need to be made on-chain, where they can be traced. This is what second tier technologies cannot achieve.
Additionally, opening a lightning payment channel requires users to lock-up funds, which is an extra barrier to entry. If that’s the only affordable option, some users will choose to leave Bitcoin and go elsewhere. On-chain transactions are a proven concept —technologies like the lightning network are not.
The lightning network can prove itself once Segregated Witness is activated. And as a bonus, Segregated Witness almost doubles the effective block size. Yet, you intend to block its activation. Why?
Segregated Witness can be implemented more simply and cleaner via a hard fork, but Bitcoin Core has opted for a more complex soft fork. This indicates they don’t want a hard fork at all, and don’t want to increase the block size limit either. If the soft fork is adopted, I think a hard fork will be off the table. My goal is not really to block Segregated Witness in and of itself, but to work towards a Bitcoin version I think is better.
In your opinion, what must this hard fork look like, exactly?
I have proposed to transition to Bitcoin Unlimited because Bitcoin Unlimited removes the hard-coded restriction on the protocol layer completely. Once the one megabyte hard limit restriction is removed, the block size can adjust dynamically in line with the needs of users and technological progress.
In this scenario, the block size limit would effectively be controlled by a handful of mining pools representing a majority of hash power which does not sound very decentralized.
You cannot say bitcoin mining is centralized just because most miners are located in China. There are more than 20 mining pools, where the biggest pool represents no more than 20 percent of hash power on the network. There are thousands of miners, and anyone is free to start mining. Besides that, Bitcoin is a proof-of-work system. Regular users can share their opinions to try to influence the miners, but ultimately the decision is made by the miners. And of course users want bigger blocks. Of course they want to be able to send more transactions, for a lower fee. Keep in mind that miners have invested millions of dollars in Bitcoin. They won’t do anything against the users’ interest.
Imagine if “Dr. Evil” invests $100 billion in mining equipment next year. Or if the Chinese government decides to regulate Bitcoin on a protocol level. If a majority of miners can increase the block size limit to the point where users can’t run full nodes, won’t this hugely centralize—and perhaps destabilize—the system?
Well yes, there is always the risk of 51% attacks. The security of Bitcoin requires that more than half of all miners are honest. The confidence people have in Bitcoin is based on this assumption. And Bitcoin will become safer when more investment is made in Bitcoin mining.
The confidence people have in Bitcoin also lies in the fact that miners cannot arbitrarily change any protocol rule. If miners hard fork to a new protocol without support from users, they would effectively fork themselves of the network.
If miners hard fork to a new protocol, why would users stay on a chain with no hash power? A network where transactions don’t confirm is useless.
Perhaps users aren’t interested in a Bitcoin where miners control the block size limit. Perhaps they don’t support a contentious hard fork, etc. Users left behind on the original network may even decide to change the proof-of-work algorithm to “fire” the existing set of miners.
I’m not at all worried about Bitcoin Core changing the proof-of-work algorithm. Such a big change in the consensus mechanism would not be accepted by the majority of the community, and as a result there would simply be one more altcoin.
Both ends of the fork will probably consider each others’ chain to be the altcoin…
In that case we’ll let the market choose which side is Bitcoin.
In that case, why not have ViaBTC hard fork right now and let the market decide straight away?
I prefer not to see a currency split, and I don’t think it will happen if we get 75 percent of all hash power on board. But Bitcoin Unlimited miners currently only control about 10 percent of hash power on the network. If we’d hard fork now, we probably wouldn’t get enough user acknowledgement and support — and meanwhile we’d undertake a tremendous opportunity loss. As a rational businessman, I won’t do that.
Let’s say your hard fork succeeds. Several Bitcoin Core developers have already indicated they have no interest in joining this new network. Who will maintain and develop this Bitcoin?
I think if Bitcoin Unlimited becomes the main chain, a rather high ratio of developers will turn to contribute. The Bitcoin code is much less complicated than that of Linux or other open source software, so in this world there are plenty of people with the ability to maintain Bitcoin.
Where are all these people, and why aren’t they maintaining Bitcoin right now?
I could do it if I wanted to.
Why don’t you?
Nobody is paying me to do it. And I can earn more by doing other things.
Couldn’t it be argued, though, that insofar as Bitcoin Core developers are paid at all, they could probably be earning more by doing other things as well?
That is wrong. They should be paid. I personally already pay two Bitcoin XT developers, and if a fork happens, I’m sure there are many more people that can fund development. Roger Ver, Jihan Wu… And there will be more mature companies in the Bitcoin ecosystem, which all have momentum to support and cultivate more Bitcoin developers too.
Do you think that the Bitcoin Core development team should be fired?
I believe that the Bitcoin Core developers currently have too much power; there’s no system of checks and balances for them. They can decide to make massive changes to Bitcoin based on their own personal preferences, and then force those changes on to the users.
Neither users nor miners are forced to run Bitcoin Core. You know that, since you are, in fact, not running Bitcoin Core. Developers make a proposal; the community decides whether or not to accept it.
There’s not enough competing implementations to take that position seriously. We already had some competition, but none of these alternative clients posed a threat to Bitcoin Core. A hard fork to Bitcoin Unlimited may change the developer environment. That is what we need. No one should be able to control Bitcoin.
Is that, perhaps, what this is really about? Control?
I do think the centralization of Bitcoin development is an even bigger issue than the block size limit or Segregated Witness. Bitcoin Core has a privileged position as the “reference client.” And only a few people have the rights to merge code in it.
Bitcoin Core is a relatively loosely-knit group of volunteer developers. They choose to cooperate because they agree that’s a more effective way of getting things done. Besides, anyone can fork their code. What alternative do you propose?
I have some thoughts about that, but haven’t worked out all of the details. I think Bitcoin Core’s code should not define Bitcoin. Like many other successful open source projects, there should be a specification document to define Bitcoin. This will help alternative implementations become compatible with Bitcoin Core, meaning they can effectively compete —rather than just follow.
I think everyone would agree a specification document would be welcome. But in the end, Bitcoin is the code people run on their computers, is it not?
I believe the consensus should not be code, it should be English. It should be understandable for most Bitcoin users and companies. This way more people can have a voice, an impact.
Speaking of control, who controls the hash power on ViaBTC? Some say it’s Bitmain.
Our pool system is highly available, stable and efficient. We have not produced a single orphan block, and we give all mining fees to miners. This is what’s attracting hundreds of miners to our pool, big and small. The idea that Bitmain controls the hash power on ViaBTC is totally ridiculous.
The post Why ViaBTC Rejects SegWit Soft Fork in Favor of Block Size Hard Fork: Interview With Haipo Yang appeared first on Bitcoin Magazine.