BitPay has been very much focused on the issues around transaction capacity on the Bitcoin network lately, which eventually led them to support the New York Agreement (also known as SegWit2x). In comments shared with Bitcoin Magazine, BitPay CEO Stephen Pair clarified the company’s view on the SegWit2x proposal and hard forks more generally.
While Pair has indicated that BitPay is working on off-chain payment solutions unrelated to the often-touted lightning network, BitPay would also like to see on-chain capacity increase by way of a hard fork during this “critical stage” of the technology’s adoption by more users.
In the interview, Pair noted that BitPay understands the concerns around implementing a hard-forking increase to the block size limit, but he also added that SegWit2x is the best option for scaling available right now.
You can read all of Pair’s responses to questions from Bitcoin Magazine below.
Bitcoin Magazine: When you were on Let’s Talk Bitcoin a few months ago, you said you didn’t think a hard fork would be a good idea at the time and Bitcoin would still be fine if it never forked, but now you are pushing SegWit2x. So, what changed?
Stephen Pair: Actually, I said that I didn’t think a contentious hard fork to Bitcoin Unlimited was the best way of increasing on-chain capacity.
Our view is that you need balance between the cost of putting a transaction in the blockchain and the cost of running a full node. Both will get increasingly expensive as Bitcoin adoption grows, but the system doesn’t make any sense to us if either one is substantially more expensive than the other.
At the moment we are in favor of SegWit2x because it is the least contentious option for activating SegWit (which will enable layer 2 payments innovation) while simultaneously alleviating congestion in the short term. Our view might be different if Bitcoin wasn’t at a critical stage of adoption (it is), or 2 MB blocks were a risk to the system (it isn’t), or layer 2 payments were production ready (they aren’t). At some point even layer 2 payments are going to put an immense amount of capacity pressure on layer 1.
The debate in the community is no longer primarily big block vs. small block; it is extremists on either side vs. moderates. SegWit2x allows most of the community to remain on the same chain for at least a little while longer. If SegWit2x fails, then we will likely have a chain split sooner rather than later, which, by the way, isn’t necessarily all bad. It would allow more freedom for people to pursue their vision of scaling. In many ways a split would make Bitcoin twice as likely to succeed.
BM: In a perfect world, would you prefer to activate SegWit now and then take a wait-and-see approach on a hard-forking increase to the block size limit?
SP: No, we believe a modest on-chain capacity increase is important as well. The concerns that many people have about doing so are related to increasing the cost of running a full node, the governance precedent it might set, and that increasing on-chain capacity becomes the path of least resistance and will reduce the incentive for layer 2 innovations. We fully understand and share these concerns, as I believe most supporters of SegWit2x do, but we still believe it’s the best of the available options.
BM: What are your thoughts on implementing a big block sidechain (federated or Drivechain) as a way to increase capacity while not affecting system requirements for running a main chain full node? Or would you prefer an extension block?
SP: There are many fans of Drivechain at BitPay and we are very optimistic about it. In fact, as we were working with the bcoin team on extension blocks, the topic of Drivechain came up quite a bit. I really wanted to figure out if there was an opportunity to enhance the extension block work into Drivechain (and there may yet be). The extension block implementation was simply a way of achieving a block size increase without requiring a hard fork, but we don’t view it as a long-term capacity solution.
I also want to mention UASF. While we like the idea of miners making informed decisions related to consensus rules based on the needs of their users (like us), we think an activist-led deployment of a soft fork is extremely dangerous. The plan for deploying extension blocks would likely have taken a very similar approach. We believe that the only appropriate and peaceful response to a failure to gain the support of the hashrate majority would be to create a safe hard fork with re-org and replay protection. In order to protect itself, we think the community should unambiguously reject the notion of an activist-led soft fork deployment.
Lastly, BitPay is going to follow the hashrate majority in the immediate and foreseeable future. That means that whatever consensus changes the hashrate majority adopts, we will as well. That is really the only option for us and our customers. In the longer term, if a fork of Bitcoin emerges that we think might better serve our needs and the needs of our customers, we may evaluate a transition to that fork. But at the present time, we believe the consensus changes embodied in SegWit2x are acceptable.