The Bitcoin community is not taking kindly to BitPay this week. Influential developers are accusing the major payment processor of fraud, Bitcoin users on social media are calling for boycots, bitcoin.org is removing recommendations of the company’s products, and NBitcoin developer Nicolas Dorier has launched an initiative to fork some of BitPay’s projects altogether.
Here’s why.
Bitcore
The controversial issue has to do with Bitcore.
Bitcore is a type of Bitcoin node developed by BitPay. It is specifically designed to offer a development platform, on top of which it is easy to build all kinds of Bitcoin applications. Anyone can use this open-source tool; some of the better-known applications that utilize it include video-streaming service Streamium, Trezor’s web interface and BitPay’s own Copay wallet.
Within the next a couple of days, most likely on August 23, the long-awaited Bitcoin protocol upgrade Segregated Witness (SegWit) will activate. Seemingly in response to this upgrade, BitPay published a blog post titled What Bitcore Users Need to Know to Be Ready for SegWit Activation
But not everyone is happy with the contents of this blog post…
The “Major Risk” That Is (or Isn’t) SegWit
The first problem is not the most important problem, but it is worth mentioning, regardless. It concerns the topic of the blog post itself: Segregated Witness.
In the blog post, BitPay states:
Nodes which fail to upgrade to support SegWit will face major security risks, including the risk of double-spend transaction fraud.
This appears to be a bit of an exaggeration.
Segregated Witness is specifically designed to be backwards compatible. Regular nodes that do not upgrade remain part of the Bitcoin network. And importantly, since SegWit was activated by a unanimous hash-power majority, all miners should be enforcing the new rules. As such, transactions that are invalid according the new rules should never be accepted in any Bitcoin blocks at all. Even non-upgraded nodes should never see these invalid transactions confirm.
It is true that — like every other soft fork before SegWit — there are some increased risks for non-upgraded nodes. And in an additional blog post, BitPay does provide more details and nuance regarding the situation.
But the somewhat alarmist tone of the first blog post seems a bit unnecessary. Therefore, to many it appears to have had the specific goal of pushing users toward a software upgrade for very different reasons.
Which brings us to the next point…
The “Upgrade” That Is (or Isn’t) Bitcoin
While BitPay’s alarmist tone seemed like an unnecessary means, it’s the end that really ticked so many people off.
As per the “New York Agreement,” a significant group of Bitcoin companies, mining pools and individuals plans to adopt an incompatible set of protocol rules by November. Dubbed “SegWit2x,” and implemented in the BTC1 software developed by former Bitcoin Core contributor Jeff Garzik, this project would “hard fork” an increase of Bitcoin’s block weight limit, allowing for blocks of up to eight megabytes. (Whether this should technically be called a hard fork or an altcoin is debatable, but never mind that for now.)
The problem is that, while a significant group of Bitcoin companies — including, indeed, BitPay — signed on to the New York Agreement, this agreement currently does not have industry-wide consensus. Most notably, Bitcoin’s development community has almost unanimously rejected the proposal. There is also a long list of companies that never signed onto the initiative in the first place; in fact, some of them are actively opposed to it. And more informal metrics, like social media sentiment, opinion polls and network node count generally also show limited support for SegWit2x.
As such, it is likely that SegWit2x would split off to create a new blockchain and currency, not unlike what Bitcoin Cash (Bcash) did. Unlike Bcash, however, SegWit2x currently has no intention of picking a new name, nor does it plan to implement safety precautions like replay protection. (Replay protection would prevent the “same” coin from accidentally being spent on both chains.) For all intents and purposes, the companies behind SegWit2x appear to be set to claim this coin is the “real” Bitcoin, while the coin that follows the current Bitcoin protocol won’t be.
This approach is controversial. Many Bitcoin users that do not support the hard fork may prefer to keep using Bitcoin as is, without worrying about added (replay) risks or other inconveniences caused by SegWit2x. And if two different coins claim the name “Bitcoin,” it could lead to much confusion, for obvious reasons.
Regardless, in BitPay’s blog post, which speaks of an “upgrade” for Bitcore users in preparation for SegWit, the payment processor actually directs readers to download the BTC1 software; that is, the software that embeds the SegWit2x protocol, rather than the current Bitcoin protocol. It therefore appeared that the company was really trying to get Bitcore users to switch to a whole new coin, which BitPay will consider “Bitcoin.” And the payment processor initially did so without so much as warning Bitcore users that following these instructions would make them incompatible with the current Bitcoin protocol by November.
Herein lies the concern: BitPay must have known that this advice is controversial. Failing to mention the risks or consequences made the blog post seem deceptive.
The Hash Power That Supports (or Doesn’t Support) SegWit2x
Finally, after BitPay faced initial blowback for its blog post for reasons described, it included an addendum. In it, the payment processor writes:
[O]ur instructions follow this version of Bitcoin because over 95% of Bitcoin miners have adopted Segwit2x.
While this addendum provides a little bit more clarity, it is once again a bit of a questionable statement.
Perhaps most importantly: If BTC1 indeed hard forks in November, BitPay right now has no way of knowing how much hash power will really be mining on the SegWit2x chain.
While it is true that mining pools currently representing a supermajority of hash power signed on to the New York Agreement, mining pools usually don’t have full control over the hash power that is pointed toward their pools. Much of this hash power actually belongs to individual miners (“hashers”), who could switch to a new pool with the click of a few buttons. (For example, when another mining pool, Ghash.io, reached over 50 percent of total hash power on the network a couple of years ago, hashers were also urged to move to different pools.)
Furthermore, even if a specific mining pool does control its hash power, nothing in the New York Agreement says these pools should mine on the SegWit2x chain exclusively. Since miners typically dedicate their hash power to maximize profit, it is very possible that this hash power will be attributed to different chains according to the value of the coins on these chains. (This is what usually happens between altcoins. Similarly, just over the past couple of weeks, some signatories to the New York Agreement have already begun directing some hash power to the Bcash chain.)
In its addendum, BitPay appears to be ignoring these dynamics. Once again, this has an air of deceptiveness.
In BitPay’s Defense…
All that said, it should be noted that the risks are still limited, even if users follow BitPay’s instructions.
This is because BitPay is not (currently) suggesting that users run BTC1 software to send and receive transactions. Rather, BitPay is advising users to connect their Bitcore nodes to a BTC1 node as a “border node.” This means that the BTC1 node will essentially act as a network filter to reject all transactions invalid under the new SegWit rules.
Until the hard fork in November, using BTC1 as a border node shouldn’t do any harm whatsoever. BTC1 is compatible with the Bitcoin network until that point in time, and indeed enforces the new SegWit rules.
If no further action is taken, the BTC1 border node would switch to the SegWit2x blockchain by November. But even then, the current Bitcore nodes that are used to send and receive transactions will not make that switch. As such, BTC1 nodes would only let SegWit2x transactions through, which would then, in turn, be rejected by Bitcore nodes. This incompatibility between the two nodes actually means that no blocks would come through at all.
As such, no one would send or accept (confirmed) payments in a different coin than they mean to. In a worst case scenario, the whole setup essentially shuts down.
While the blog post appears deceptive in some ways, BitPay’s advice shouldn't, in itself, cause a of loss funds.
Shortly before publication of this article, BitPay CEO Stephen Pair said in statement to Bitcoin Magazine:
This was unfortunately not the way I had intended this conversation to begin. I will have more to say on this topic in the near future, and feel I owe it to the community to say something. Unfortunately, it may take a little while for that communication to happen as I have other matters demanding my attention at the moment.