Bitcoin Core wants to distance itself politically from the former project leader Gavin Andresen, the payment protocol BIP070 he was involved with, and from the BCH-friendly Bitpay payment processor company. The attempts to remove software associated with Gavin Andresen are now having real-world effects on the security of bitcoin payments.
Bitpay Forced to Remove BIP070
Bitpay keeps getting criticized for implementing a payment protocol requirement for wallet apps looking to send money to a Bitpay BTC or BCH address. Bitpay quite suddenly implemented the requirement without much debate and no public negotiations with other community members.
The initial instinctual reaction among many BTC and BCH users was that “no (single) private company should be allowed to make demands about mandatory changes to all BTC and BCH wallet apps because that would mean that software change decisions would be decided in a centralized manner which would be unacceptable for a currency that’s supposed to be decentralized.” But that reasoning only works superficially and stops working if you spend some time to think more deeply about it, and here’s why:
The Payment Protocol was not created by Bitpay. It was created by the individuals (independent from Bitpay) Gavin Andresen and Mike Hearn back in July 29, 2013, long before Bitpay announced on Nov. 28, 2017 that they would start requiring wallet apps to use the Payment Protocol when sending money to Bitpay. Many major BTC wallet apps had already implemented Payment Protocol support independently from Bitpay – “If you are using the BitPay, Copay, Mycelium, Bitcoin Core, Airbitz, or Electrum wallets for your bitcoin payments, nothing will change. These true bitcoin wallets all already ‘speak’ Payment Protocol” – and before Bitpay made their announcement that they would start requiring Payment Protocol compatibility in the coming months.
The major reason why Bitpay announced they would start demanding Payment Protocol compatibility from all wallet apps that would like to send money to Bitpay was that they started getting a lot of customer support requests from their users who had accidentally sent money to them with a transaction fee so low that their transaction either got delayed for days, sometimes weeks or even rejected by the BTC network, typically after a several weeks long delay.
The Payment Protocol would remove the ability for the Bitpay customer to choose the transaction fee and give that decision to Bitpay instead. Bitpay would specify a transaction fee high enough that they would be reasonably confident that they would eventually receive the money in a reasonably timely manner, thus heavily reducing the number of customer support tickets generated.
Bitpay did not try to start centrally controlling “the rules of Bitcoin.” They just saw a harmless way to reduce their customer support department costs and announced their necessary requirement to accomplish that goal more efficiently.
No clarification has been given on why the BIP070 Payment Protocol is now considered “deprecated and will be removed in a later version of Bitcoin Core” because “The protocol has multiple security design flaws and implementation flaws in some wallets,” at least not on the Bitcoin Core documentation site since Nov. 22, 2018 until May 7, 2019. Maybe it’s just a matter of their documentation being poorly updated or maybe it’s because BIP070 actually works well enough to not have to be deprecated.
The latter reason seems more likely because Bitcoin Core (BTC) advocates have been politically hostile against Bitpay and especially so after Bitpay announced that they have started supporting BCH in addition to BTC.
This seems to be a political move to signal that Bitcoin Core should make the important decisions about how payments should be made and not a BCH friendly company such as Bitpay.
BIP070 was authored by two BCH friendly individuals (“Satoshi’s second in command” and former Bitcoin Core project leader Gavin Andresen and Bitcoin XT founder Mike Hearn) whereas the now suggested Payment Protocol BIP021 was co-authored by the well-known Bitcoin Core and small base blocksize limit advocate and developer Matt Corallo.
Bitpay could’ve chosen to mandate the significantly older Payment Protocol BIP021 (created Jan. 29, 2012) instead of mandating the newer Payment Protocol BIP070 (created July 29, 2013). For whatever reasons, Bitpay chose the newer standard BIP070. Bitcoin Core implemented support for BIP070 all the way back on March 19, 2014 as can be read in their release notes: “Add payment request (BIP 0070) support.”
It’s odd that the Bitcoin Core project implements the newer standard BIP070 and then many years later deprecates the newer standard in Bitcoin Core and starts suggesting that everyone should be using the much older standard BIP021 that even Bitcoin Core themselves did not choose initially. It’s odd unless you consider the politics between the competing Bitcoin variant currencies, BTC and BCH, in which case the events start making sense again.
Bitcoin Core wants to distance itself politically from BIP070, the former BCH-friendly Bitcoin Core project leader Gavin Andresen, and the BCH-friendly Bitpay payment processor company. Bitcoin Core advocates state the reasons as being: “The protocol has multiple security design flaws and implementation flaws in some wallets,” without clarifying those reasons, when in fact their reasons are clearly politically motivated as has been argued in this article.
The currently most widely accepted, supported and endorsed BTC and BCH Payment Protocol BIP070 works well enough for now (see graph below), even though mandating its use was decided by the BCH-friendly payment processor company Bitpay and not by the current project leader of the now BTC maximalist Bitcoin Core project. It makes sense to keep endorsing and supporting BIP070 at least until a better standard has been developed and its merits have been well argued and thoroughly debated within the BTC and BCH communities. The older BIP021 standard does not seem to be better than the newer BIP070 standard.
The best counterargument to enforce the use of BIP070 for wallet apps was arguably given by Andreas Antonopoulos, and Bitpay motivated their enforcement convincingly in this excellent summary: “Near the end of the video, Andreas pointed out that people are using third parties to unwrap the BIP-70 protocol to get to the BIP-21. This creates additional security concerns for BitPay users by introducing additional trusted parties. This point is not only valid, but, if our sole and primary motivation for enforcing BIP-70 was about security, would present a compelling case to roll-back enforcement until more of or all of the Bitcoin ecosystem adopted Payment Protocol. But as we said before, BIP-70 is not only about security for BitPay, but about usability. And the usability of cryptocurrency is not just about the short-term success of BitPay, but also the long-term success of cryptocurrency.”
Andreas talks about “The BIP-70 controversy.” He reads a question that was submitted by one of his viewers. The viewer says “Samurai wallet for example does not support BIP-70 and refuses to implement that feature. Could you explain why BIP-70 is controversial in itself and why Bitpay implements a non-universal BIP? Do users have a role to play in this controversy?”
It’s easy to understand why the Samurai wallet team refuses to implement and support BIP-70. They endorse the Bitcoin Core (BTC) currency above all and consider any other competing cryptocurrency, BCH especially, as “an attack on Bitcoin.”
The Samurai wallet team tweeted that they approve of Bitcoin Core advocates “viciously attacking” Bitcoin Cash advocates and that Bitcoin Cash advocates are “lunatics” and “frauds.” That’s a pretty strong choice of words to describe a group of people that have a difference of opinion regarding how Bitcoin should scale.
“Bitcoin will not bend the knee for you, your business, or anyone else. Bitcoin will not compromise. That’s a feature not a bug. You lunatics forked yourself off, now you can deal with the consequences and the ‘vicious attacks’.” And then this comment: “Forking is not the issue. That is exactly what they should have done. The ongoing narrative that ‘BCH is Bitcoin’ is the problem and should be ‘viciously attacked’ or at least highly ridiculed. If you don’t call out fraud, you yourself are a fraudster.”
It’s About Politics, Not Technology
It should not come as a surprise then that the Samurai wallet team refuses to support the BIP-70 technology that the Bitcoin Cash-friendly payment processor Bitpay started requiring from all wallet app providers. It’s about politics, not about technology. Andreas too has become a Bitcoin Core advocate so it’s not a surprise that he omits mentioning that the Samurai wallet team is not a typical example of a politically neutral wallet team. He just pretends that the person who asked the question in his video is right about the Samurai wallet team being politically neutral.
Andreas Antonopoulos further says (regarding Bitpay’s choice to make the use of BIP070 mandatory for all of their customers) at 6:04 in his video that: “From a certain perspective I think that makes sense. However it’s created a lot of pushback … leading in fact to the emergence of alternatives and competitors to Bitpay with projects such as BTCpay Server.”
Notice how Andreas says it’s the reason and not a reason that people started competitors to the Bitpay company. That’s not a very honest description of the events now, is it? Bitpay requiring BIP070 is just one reason among many reasons that people started competing companies. The two most major reasons are that 1) people start competing companies in growing ecosystems all the time, and 2) Bitpay was one of the earliest and most influential community members that publicly advocated raising the base blocksize limit for the Bitcoin currency before Bitcoin split into Bitcoin Core (BTC) and Bitcoin Cash (BCH) on Aug. 1, 2017. This is what Stephen Pair (co-founder and CEO of Bitpay) wrote all the way back on Jan. 7, 2016 about Bitpay’s political stance regarding the blocksize limit debate:
“Miners need a simple, but adaptive consensus rule for determining the block size limit. Of all the ideas we’ve examined, the one that seems most appealing is a simple adaptive limit based on a recent median block size. To determine the block size limit, you compute the median block size over some recent sample of blocks and apply a multiple. For example, you might set the limit to 2x the median block size of the last 2016 blocks … At BitPay, we will experiment with this approach. We will perform back testing to analyze what impact various settings might have on historic blocks. We will also analyze behavior under extreme circumstances and critique it from a game theoretic perspective. You can follow our work with our fork of the bitcoin client: https://github.com/bitpay/bitcoin. If our findings convince us that it is the best approach for Bitcoin, we will work to convince others (most importantly, miners) as well. In the meantime, if miners reach a consensus on a temporary bump in the fixed limit, you’ll be able to spend those coins at any BitPay merchant.”
As you can see, it’s no wonder Bitcoin Core advocates view Bitpay as being a very influential and important competitor to the scaling roadmap that the Bitcoin Core team fought and keeps fighting for.
Interestingly, it just so happens that Amaury Sechet (project leader of Bitcoin ABC) is advocating a very similar long-term solution to deciding the base blocksize limit for Bitcoin Cash. Bitcoin ABC stands for “Adjustable Blocksize Cap” and Bitcoin ABC’s base blocksize limit previous increases from 1 MB to 8 MB, and then to 32 MB have been merely short-term solutions while the long-term solution is still being researched and worked on. Amaury (“Deadalnix” on Github) wrote this on Jan. 6, 2019, almost exactly three years after the above mentioned Bitpay blog post:
“Given the goal of keeping the system secure without running while keeping the [base blocksize] limit above actual use, I would chose the parameter of the adjustment using the largest value of these two computations:
1/ the median block size of the last 11 block multiplied by 2.
2/ the average block size over a large duration (I’m not sure what’s a good value at this time).
Rationale: We want to avoid the usage to run into the block size. To do so, it is important to adapt quickly in case of rapid change in usage. We also desire to keep multiplier small as we want to reduce the attack surface. It follows that a small window (11) and a small multiplier (2) fits the bill best. 11 is considered safe from manipulation and used for other computation like MTP for that reason.”
Notice the striking similarity between Bitpay’s and Amaury’s preferred long-term solutions to the base blocksize limit for BTC and BCH. Great minds seem to think alike. It’s no wonder that Bitpay announced (March 28, 2018) that they would support BCH in addition to BTC for their payment services: “BitPay Merchants Can Now Accept Bitcoin Cash Payments.” Bitcoin Cash (BCH) is simply more Bitcoin than “Bitcoin.”
Where do you stand on this debate? Share your thoughts on the subject in the comments section below.
This post was written by Tomislav Dugandzic, independent bitcoin cash (BCH) user and currency speculator.
OP-ed disclaimer: This is an Op-ed article. The opinions expressed in this article are the author’s own. Bitcoin.com is not responsible for or liable for any content, accuracy or quality within the Op-ed article. Readers should do their own due diligence before taking any actions related to the content. Bitcoin.com is not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any information in this Op-ed article.
Images courtesy of Shutterstock, Github, Bitpay, Stephen Pair (Twitter).
Do you want to dig deeper into Bitcoin? Explore past and present cryptocurrency prices through our Bitcoin Markets tool and head to our Blockchain Explorer to view specific transactions, addresses, and blocks.