The current coin down turn is actually good for the industry as its exposing the ridiculousness of all the other coins business models – including Bitcoin Core (BTC) which has been seriously overvalued given its inability to be used as electronic cash. Cryptocurrency value should always have been about utility, and that requires the ability to massively scale as well as low cost secure micro-transactions. Though painful for those going in the wrong direction, this market correction will allow the facts to shine through and we hope that once this is over everyone will understand that this is and always has been about real utility and scaling.
Digital gold models and ICOs are all fiction and have been very bad for this industry. Both will result in massive loses for many investors, and have obscured the understanding that cryptocurrency needs scaling to be the new global money, what Bitcoin (now existing as Bitcoin SV) was created to do.
We are glad we fought Bitcoin ABC and had Bitcoin SV stand its ground. Otherwise, the original Bitcoin would have died again last week when Bitcoin ABC rushed in a series of code changes which depart from Bitcon’s core principles. Bitcoin SV has preserved the original Bitcoin and will make sure it succeeds.
Bitcoin SV is therefore seriously undervalued now, and the token best positioned to grow in value. Our prediction is that this market correction will result in Bitcoin SV being the only cryptocurrency that you can retreat to and preserve value. It is also the only one that will protect mining industry revenue for the future, and it’s the blockchain where the explosion of new business models will happen. In fact, we’ve quickly seen that most of the BCH native applications and businesses are switching over to BSV. Anyone who switches to BSV now will be ok…those who stay with a cryptocurrency or blockchain with no reason to exist will lose everything.
Bottom line, though painful, this correction is good for the industry longer term and good for society.
Any time you feel forced to square off to defend yourself or something you value you always need to have an end game plan. For CoinGeek that end game was always making sure there was a version of the original Bitcoin still able to show off its original economic design genius to the world. Bitcoin was born with a mature economic model and platform developers have consistently tinkered it to death…first by forking to Segwit BTC and now ABC has abandoned Bitcoin’s core principles by abandoning Nakamoto concensus and trust in miners’ Proof of Work. This is fine for them to test their thinking, but not by killing Bitcoin before it’s even been tested properly so we stepped in.
It is CoinGeek’s opinion that the two chains are now so far apart and have such divergent plans ahead that there is just no path back to joining them. We also no longer want the name Bitcoin Cash BCH as to us, Bitcoin SV is the original Bitcoin not the original Bitcoin Cash (whatever that even means). We understand that having nChain no longer fighting with them over roadmaps was the single most important issue to the ABC side. nChain tells me they are happy to leave ABC chain alone if they enact replay protection and do a permanent split. This is very convenient as the definition of winning is fundamentally different to each side so there is a win-win solution here.
From where CoinGeek sits right now, us permanently splitting the chains by ABC enacting replay protection will give both sides a WIN. Bitcoin will live on with Bitcoin SV and will finally have a chance to show off the true power of the original economic model. Similarly, ABC can join with the rest of the new chain/coin models to demonstrate what they believe they can do. The models can then all compete in the marketplace and this lets actual users vote with their actions.
I am confident that CoinGeek can enforce civility if the other side wants this in any permanent split. We believe this is in the best interests of all and call on all the exchanges and payment processors and others who have an interest in making this all go away to help us convince everyone to accept this solution so we can all focus on our visions for the future and get rid of this wasteful distraction.
I have instructed my team to start working with everyone to roll out the new Bitcoin SV coin. I hope this can be the end of this episode and look forward to the CoinGeek Week Conference next week being the launch party for the return of the original Bitcoin and all that this will enable. Look forward to seeing everyone there and especially discussing the future of the original Bitcoin.
Everyone by now is aware of what’s going on with Bitcoin Cash and the results of the hard fork. The BCH ecosystem has basically been turned upside down as the community still tries to provide some semblance of order to the cryptocurrency, but it seems that developers with Bitcoin ABC are doing exactly what Bitcoin SV supporters had feared—throwing everything they can at the network. The only thing that’s left is to try to toss in the kitchen sink.
Since November 15, Bitcoin ABC developers have introduced a number of changes that seem to be indicative of a “let’s see what sticks” mentality. The changes have mostly been found through the group’s GitHub repository, which indicates that developers—even through Wednesday—were still playing around with the code.
The disappointing part is that the developers apparently haven’t been willing to let the community know ahead of time about the changes. This smacks of draconian attempts to control the network, regardless of what the entire community may feel is best for the blockchain and shows that the developers are content with treating BCH as their own personal sandbox.
A conversation on the Bitcoin Unlimited (BU) Slack proves that developers from ABC were not willing to share their updates with the rest of the community. Tom Harding, a Bitcoin XT developer, points out, “I did not know about the 10-deep floating block finalizing,” in response to someone asking if BU knew of the upgrades. Another user, “ptschip,” also said that the first he heard of an upgrade was “when their release came out.”
As one user, “painlord2K,” aptly put it, “So BCH is ABC coin now. No doubts about it.”
The world gets it—developers have to develop. It’s in their nature; it’s who they are. This isn’t an issue in and of itself. It only becomes an issue when certain individuals feel that they are better equipped to make decisions for the community and will stop at nothing to force their opinions on everyone else, despite extreme opposition.
Cryptocurrency is too important to be utilized as a playground—that’s why testnets exist. BCH has to have a solid foundation to evolve and mature, but Bitcoin ABC developers are proving that they’re happy with the currency operating in moving sand and, possibly, quicksand.
In anticipation of the Bitcoin Cash hard fork last week, two cryptocurrencies were launched—BCHABC and BCHSV. Each corresponded to one of the two camps that were pushing BCH’s divide, but only one has the potential to be considered a fraudulent pump-and-dump scheme—BCHABC.
Medium user “Without Fear” provides a considerable amount of data to support that belief in a recent thread on the social media platform. Before anyone goes off the deep end and accuses Without Fear of being nothing more than a puppet for BCHSV, it would be in their best interest to read the post and understand better the scenario.
Without Fear points out that, prior to the hard fork, “[W]e have hash that wasn’t mining BCH before the fork, which means that (without looking at it) this is either pragmatic hash that makes money by selling the ABC coins they mine, or hash rented by the people who wanted or believed in the ABC ruleset. However it became clear after the following announcement by Bitcoin.com that a lot of the hash that would mine BCHABC the day of the fork would be stolen hash from Bitcoin.com pool miners.”
The author goes on to show that there have been a number of mining pools that have stolen hash from their customers in order to point them to BCHABC proponent Bitcoin.com, including Antpool, viaBTC and BTC.TOP, creating a pool that post’s author refers to as BABV. This hash, asserts Without Fear, is unstable and is being mined against the market’s wishes—it is forced hash.
He also shows how the Kraken exchange is trying to manipulate public sentiment. Kraken is backed by Bitcoin.com’s Roger Ver and recently stated that it will support BCHSV, but warned that Bitcoin SV “should be seen as an extremely high risk investment, citing several “red flags”: BCHSV has no wallets that support replay protection, it has no support in major block explorers and because miners are subsidized or operating at a loss, among others. This is a blatant disregard of the facts and a manipulation of the truth. Neither BCHSV nor BCHABC offer replay protection and BCHSV most definitely has support in block explorers. There is no evidence to support the fact that BCHSV miners are being subsidized, whereas Without Fear provides several examples of how BCHABC is subsidized. Ver himself has even admitted to it, telling CoinGeek’s Calvin Ayre that Bitcoin.com can subsidize BCHABC with 4000 petahashes for a decade.
So, where does this leave us? BABV is a pool that is creating hash that is supposed to be mined elsewhere, but whose components have been pointed by the pool operators—not the miners—to mine BCHABC in an attempt to signal market strength. As Without Fear correctly ascertains, “However, this is not real demand, the machine owners never asked or consented to mine BCHABC. This is being done behind their back while they are paid as if machines are mining BTC, or whatever is most profitable.”
In the absence of true market demand, the forced hash will revert to its original source and BCHABC will, by default, stop progressing. Explains Without Fear, “Considering that ABC hash support was 800 when the BCH price was around $500 and that the current BCHABC price is less than $300, such plunge in hash would spiral out of control and lead to a full halt in what these exchanges have labelled as the “BCH” chain. The portfolios of people who held BCH before the fork would now be worth zero while the BCHSV chain keeps being mined.”
Without Fear’s advice is simple and insightful: “[S]teer clear of exchanges that try to sell ABC as ‘BCH’ as ABC is extremely unstable and not comparable to your BCH holdings.”
Last November 15, during the Bitcoin Cash (BCH) network upgrade, a hash war has been fought with miners voting between two competing implementations of the BCH protocol—Bitcoin SV and Bitcoin ABC.
As expected, Bitcoin ABC took a temporary early lead, thanks to an artificial burst from “rented” hash power subsidized by Roger Ver’s Bitcoin.com, which announced that it would use pool customer hash from the Bitcoin Core (BTC) network onto the BCH chain for 24 hours, as well as from ABC’s main supporter Bitmain Technologies.
The hash war, however, is far from over. Bitcoin SV’s strongest supporters, CoinGeek and nChain, are committed to a long term fight using their legitimate, sustained hash—long after Bitmain can no longer afford to bleed money for rented hash.
On November 17, nChain CEO Jimmy Nguyen appeared on Keyport’s live stream coverage of the Bitcoin BCH hash war to speak the truth, as well as explain to the BCH community the consequences of their willingness to accept a burst of rented hash to quickly decide the hash war. And to those who are out there on social media, cheering for the supposed ABC victory, Nguyen posed this question: Is this the precedent we want to set for the Bitcoin Cash community?
Read the full transcript of Jimmy Nguyen’s Keyport speech below.
TRUTH AND CONSEQUENCES ABOUT THE ONGOING BITCOIN CASH HASH WAR
Jimmy Nguyen – CEO, nChain Group
Since the Bitcoin Cash (BCH) network upgrade on November 15, a hash war has been fought with miners voting between Bitcoin SV and Bitcoin ABC – two competing implementations of the BCH protocol. nChain and CoinGeek support Bitcoin SV. As we fully expected, Bitcoin ABC appeared to take a temporary early lead by receiving an artificial burst from temporary, “rented” hash power subsidized by Roger Ver’s company Bitcoin.com, which announced it would move its pool customer hash from the rival Bitcoin Core (BTC) network onto the BCH blockchain for just 24 hours, and from ABC’s main supporter Bitmain Technologies.
Many observers have quick to prematurely call a win for Bitcoin ABC. But the hash war is not over. nChain and CoinGeek continue to fight, mining with our legitimate, sustained hash committed to support the Bitcoin Cash network and the Satoshi Vision. For days before the hard fork, Bitcoin SV had support from over 75% of the network hash.. Knowing they clearly did not have enough support to win, Bitcoin ABC’s backers had to rent and subsidize BTC hash to move onto BCH to use as voting power. When they can no longer to afford to pay massive daily amounts to rent hash for this BCH hash war, we will still be here fighting, and the consistent hash power supporting Bitcoin SV will overtake Bitcoin ABC. That is the inevitable result of this BCH hash war
On November 17, I appeared on Keyport’s live stream coverage of the BCH hash war to provide my views and a statement to the Bitcoin Cash community about “Truth and Consequences” of their willingness to accept a burst of rented hash to quickly decide the hash war. This is a transcript of my speech, edited for clarity.
I’m about to tell you truth and consequences. These are the truth and consequences for the Bitcoin Cash community of what’s happening in this hash war.
So the weekend went exactly as I expected. There was the fork on Thursday, November 15; there was a huge burst of hash that came into the network on the side of Bitcoin ABC that was rented or subsidised— probably from the BTC network, in order to artificially boost the support for Bitcoin ABC far higher than it had ever been in the days and weeks coming up to the hard fork.
Then the Bitcoin ABC supporters decided to declare early victory, because they seemed so far ahead in hash. Then they started going to the exchanges, if not even before the hard fork. (I think they did look before to try and get them to recognise their chain as Bitcoin Cash (BCH).
They added checkpoint—not a surprise, our developers heard about that a week ago.
So everything that happened is exactly as I predicted, and we’re continuing to plug away.
And people are probably wondering why we didn’t bring more hash in to support the Bitcoin SV side of the coin. Let me explain why. We actually had plenty of petahash offered to us; in fact, we actually didn’t have to go ask any miners or mining pools to lend us their hash.
Before and after the BCH Miners Choice Summit on November 2nd that CoinGeek sponsored and which I attended, we had a potential deal for thousands of petahash —to be rented and subsidised by us much like, I’m sure, Bitmain and Roger Ver were doing in some capacity or variation. While I was at that summit, we had thousands more petahash offered to us to rent, by people who just did not like Bitmain, opposed the Bitcoin ABC implementation, or wanted to support us for all kinds of reasons.
I could have walked away from that day with easily ten to fifteen thousand petahash worth of support for Bitcoin SV. And it’s not for lack of money or resources that we decided not to do it because Calvin Ayre, CoinGeek and nChain could have easily afforded to do that for as long as it took during this battle, and we would have blown the Bitcoin ABC side out of the water, at least compared to the hash that they have demonstrated so far in the charts you can see. But I actually had a realization at that moment in Hong Kong about whether that was the right thing to do; and I decided it was not, because of the consequences it would have in the future for the Bitcoin Cash community. And here’s what they are:
The whole reason that such hash was available on the BTC network to move onto BCH is because the people who should have fought Bitcoin Core did not, and splintered off to create the Bitcoin Cash network, and allowed BTC to continue on. That’s perfectly fine. But now they’re borrowing hash, renting it, subsidizing it from the very network they so vehemently oppose—many of them – to try and claim a victory on the BCH network.
I want you to think about the hypocrisy of that, because it’s staggering. I also want you to think about the game that is being played here, if you are able to just move hash for a day or two from the rival network that many of our community do not like, and use that to claim victory. What does it say about what you would do just to win what looks to many people right now like a sporting contest.
In addition, I want people to know that I thought long and hard about what should be the governing model to decide disagreement between rule sets for Bitcoin – because that’s what this is, that’s what’s really being tested in this moment right now. It’s not just about a particular feature set here or there. It’s about what should be the governing model when there are disagreements.
And think about this: when the Nakamoto Consensus was written in the Bitcoin white paper, there was supposed to only be one Bitcoin network. There was not supposed to be miners on a network running the same hash algorithm that you could pay to rent their hash to come in and vote in a disagreement over rule sets. Instead, the Bitcoin network as we know it, this whole system, it’s magic is in its economic incentives. Miners have incentives to provide the computing power and security of the network; they earn block rewards, they earn transaction fees, they have the investment and monetary interest therefore to make decisions on rule sets that best continue that economic incentive and the security of the network.
But if you are not mining on the network and don’t have your own investment in it, and you are not making money on this network but making it over on BTC, why is it that you should have a vote for the rule set for Bitcoin Cash, particularly when it is hash borrowed from the very network that Bitcoin Cash was designed to split off from?
So the Nakamoto Consensus is being tested for the first time right now, and I want you to really think about that. Obviously, Satoshi Nakamoto could not have envisioned, at the time the white paper was written, that there was going to be some splintered-off network using the same hash algorithm. And with the idea of one CPU equals one vote, or miner hash power equals the vote, it was designed—and I’m sure most logical people can agree with it—to recognise that the people who have an ongoing continuous invested interest in the network are the ones that should vote on a rule set.
But what has happened over this weekend is that the supporters of ABC have been so quick to come forward, and say, after a day or two of hash bursts provided by Roger Ver and his company Bitcoin.com’s move of hash from his customers from BTC over to BCH – and I’m sure move of BTC hash by Bitmain and other sources – after one or two days of bursts, they are so quick to declare, therefore they must be the winner.
But we took an alternate path. And as you can now probably understand why Craig Wright and Calvin Ayre have been so repeatedly vocal about the need for genuine and legitimate sustained hash that supports the network. We made the decision to fight with genuine honest hash. And that is why, if you notice, over the days leading up to the hard fork., the CoinGeek, SVPool, and BMG pools started gradually increasing the hash they were devoting to the network.
That was done for a reason. It wasn’t just an all-in burst to vote on the day of the hard fork. It was designed to demonstrate continued commitment to sustain this network and a desire to show the world we are going to continue using that hash on this network. It wasn’t a flash in the pan.
And so the situation that has unfolded this weekend is basically akin to saying: I want to have an election in the United States, and I don’t think I have enough votes, so I’m going to go pay people from Canada to come to the US for a day, vote, and leave—even those people who have no interest in the outcome of that election; it does not affect their lives, their livelihood, what pocket of money they get to pay their bills. That is what the people on the ABC side of the fence have just created: the idea that you can do that and that you can do that every time there’s a disagreement over the rule set.
So I really want people to think about what kind of system you want to decide consensus rule disagreements in the future for Bitcoin. Is it who can pay the most for one or two days to rent hash from a competing rival network that you escaped from? Or is it the votes of the miners who are ongoing providers of sustained hash, because they have an ongoing economic interest in the network?
And you saw the numbers in the days before the fork: it was clear the SV side of was demonstrating on a daily basis—for multiple days—far more than majority support from the network.
I believe that should be the governing model for Bitcoin consensus rule decisions. I also want everyone out there in the community to think about the consequences for the future. IF you are so quick to say that ABC should be declared the victor and awarded the BCH ticker symbol, and its consensus rules should govern, you’ve just walked into a bigger problematic box that I knew you would. Because I knew this would all happen; it’s all unfolded on Twitter and online. You’ve just provided the playbook for a big corporation with really big pockets, a state actor of government, anyone who could afford to pay for just one or two days of rented hash, to come over to the BCH network and get its rule set implemented.
Now that may not be nefarious; it could be Google, IBM, or Microsoft, who are very interested in blockchain technology, and they want to shape the Bitcoin Cash network with rules that favor their business model. This may be perfectly legitimate, and some people may support it. But I know many of you out there in the Bitcoin community would say: “well, wait a minute, I don’t want some big corporations just coming to pay, to take over the rule set of my network.” It would not cost that much —20 or 30 million dollars could have bought them a victory in a day or two according to what all the people screaming and cheering for ABC want to see happen.
A state actor could do that easily, that’s a drop in the bucket. And if you continue this path where you say “AHA!” after a day or two with bursts of hash that did not exist before and were just taken from the BTC network, if that is the way to determine the rule set, you have just set up the biggest vulnerability ever to the Bitcoin Cash network: for someone with a deep pocket to come in and implement whatever rule set they want.
And for those of you who aren’t a big fan of big corporations and government – you know who you are out there in the Bitcoin Cash community – I think you need to sit back and think: what have I just done? Because that’s what I thought, and this is exactly what I knew was going to happen. I sat there in Hong Kong, and I had all these offers of hash that we could have taken, and we could have used it to quickly win. But I had a moment where I had to say: I had a moment to say, is this the precedent we want to set for the Bitcoin Cash community? That anyone who has a deep pocket to pay for hash for a day or two, who doesn’t have to mine the day before – such as a government, a big corporation who could be a zero miner the day before – to just pay enough miners enough money on a hard-fork date to have enough hash to have its rule set take over?
That’s exactly the situation you are creating now for all of those who are out there on social media and online, cheering for a supposed ABC victory. That’s all you think it takes. But that’s not what it should be, and that’s not what it was envisioned to be at a time when the white paper was introduced to the world with the idea that there was just going to be a single Bitcoin network with a single network of miners who all had an economic incentive and interest to mine that network, and therefore make the best decisions for the viability and vibrancy of that network.
I’ll close by saying that that’s the truth I wanted the Bitcoin community to realise and the consequences of the path you’re trying to take. At nChain and on behalf of the CoinGeek people who are somewhere else, I want to say—and if it’s not clear already—we’re very committed with the SV project to really advance the Satoshi Vision. Obviously, some people have a different interpretation of it; that’s okay, but if there’s one thing we’ve been consistent about time and time again—we want the original Bitcoin. We want to see it grow to what it was meant to be. You can disagree with us about what feature set it should be, what block cap size, about anything else. But there is one thing we consistently work on, day in and day out. You don’t have to like Craig, but it’s very clear that is his mission and vision, and it’s ours as well. And that vision has to be enforced by a pure understanding of what Nakamoto Consensus should be: loads of miners who have an economic interest day in and day out—not people who can be mercenaries, who are rented to come in and allow anyone, any corporation or state actor, to take over your network.
To some people out there who are cheering for an ABC victory after a day or two: I want you to think long and hard about what you just did, if that’s the result you want. Because you’re not going to like it—the hypocrisy, I think, is staggering for where Bitcoin Cash came from. . . from Bitcoin Core.
So it’s time for this community to make a choice, to make a choice about how you want disagreements to be decided, and how you want to allow the ruleset for your chain to be governed.
I know what choice I’m going to make, and it’s a choice that supports the Satoshi Vision. I’m going to leave now, because I have a lot of work to do to support that vision.
Today, the Bitcoin Cash (BCH) network goes through a protocol upgrade, and miners will begin using their hash power to vote between two competing implementations: Bitcoin SV, which seeks to restore the original Bitcoin protocol, and Bitcoin ABC, the prior leading implementation. One area of disagreement is that Bitcoin ABC is adding a new opcode not contained in the original Satoshi protocol: OP_CHECKDATASIG (or OP_DATASIGVERIFY) (we’ll call it OP_DSV for short). The Bitcoin Unlimited group also supports adding OP_DSV. Bitcoin SV opposes adding any new non-Satoshi op_codes, believing that the original Bitcoin protocol has everything it needs to enable development on top of it.
We also oppose OP_DSV for another reason: it presents legal risk. At nChain, we talk consistently about the need to build Bitcoin BCH such that it can operate in the real world: to meet real business needs, to be used by real people, and to comply with real laws. For some time, nChain’s Chief Scientist Craig Wright has voiced legal warnings that adding OP_DSV will knowingly introduce illegal transactions into the BCH blockchain. As a former technology and intellectual property lawyer (for 21 years in the U.S.), I want to add my thoughts to this important conversation about OP_DSV. I express the issue somewhat differently than Craig, but my conclusion is similar to his: as it has been proposed for usage, OP_DSV presents legal risks for the developers advocating it and any application using it for problematic purposes.
OP_DSV Proponents Identify Illegal Use Cases
OP_DSV is meant to enable usage of oracles to validate external information and allow an automated smart contract to operate. As one of its proponents, Emil Oldenberg, CTO of Bitcoin.com, describes it:
The new opcode verifies a message, returns true or false if the message is signed by the pubkey stated. This enables us to write something commonly referred to as an “oracle”. An oracle is a third party service that can be used as an authority for facts, statistics and data.
Like any technology feature, op codes can be used for both lawful and non-lawful purposes. The problem for OP_DSV is that its key proponents vocally proclaim uses cases that are, at best, legally problematic, and at worst, clearly illegal. This makes it apparent up front that code developers and companies which then use DSV transactions for those problematic purposes know or “reasonably foresee” that OP_DSV can be used for illegal activity.
Take for example the blog post written by Bitcoin.com’s CTO Emil Oldenburg about the new op code. Emil says OP_DSV serves the explicit purpose of both enabling and facilitating gambling applications, such as “on-chain bets” or “wagers” and “escrow services” – in other words, facilitating the exchange of tokens or financial assets without any actual exchange acting as the regulated approved authority. Indeed, what he describes is a marketplace of bets without the actual financial assets being traded — which falls directly in the U.S. Supreme Court’s classic definition from 1906 of an illegal bucket shop:
“An establishment, nominally for the transaction of a stock exchange business, or business of similar character, but really for the registration of bets, or wagers, usually for small amounts, on the rise or fall of the prices of stocks, grain, oil, etc., there being no transfer or delivery of the stock or commodities nominally dealt in.”
(Gatewood v. North Carolina, 203 U.S. 531, 536 (1906).) Bucket shops are illegal in the U.S. (and in other countries). In fact, just this July, the CFTC obtained a $3 million judgment against InTrade, an Irish prediction market for trading binary options – bets on commodity prices – in violation of a 2005 cease and desist order.
Bucket shops operating specifically in the blockchain world have also been the subject of legal enforcement action. Sand Hill Exchange was a blockchain-based bucket shop launched in 2014 as a fantasy trading site, allowing you to bet on the eventual market price of start-up companies. Although it shut down by April 2015, the SEC obtained an administrative order against its founders and issued a $20,000 fine.
Yet, even though it is quite clear bucket shops are illegal, we have Bitcoin.com’s CTO (one of the key proponents of OP_DSV) explaining a use case of the opcode that can easily be construed as an illegal bucket shop. That is a problem for a company or person who later uses OP_DSV to operate exactly that type of bucket-shop marketplace or transaction.
Even worse, in a recent video statement, Bitcoin.com’s CEO Roger Ver suggests that the Bitcoin Cash blockchain can be used to facilitate transactions for the purchase of drugs, and any type of transactions for that matter, saying that the blockchain allows for “permission-less use. You don’t need permission to do whatever the hell you want with it. If you want to gamble on the Internet, that’s just fine too. If you want to buy drugs on the Internet, that’s just fine too.” We fear that is the ultimate goal—decentralized marketplaces where people can buy anything, even items illegal in their jurisdictions—which some of OP_DSV’s vocal supporters want to achieve. We of course support everyone’s right to their own opinion, and take no position on how and whether governments should regulate gambling, drugs, or anything else. But countries have established laws criminalizing certain types of goods and activity, and those laws govern the real world in which we need Bitcoin to grow.
Legal Liability for Third Party Use of Code
So what if OP_DSV can be used for illegal purposes? You may be asking how people working or operating on the BCH network can be at risk if they did not themselves conduct an illegal DSV transaction?
My concerns about legal risk are not hypothetical. U.S. government agencies have made clear that legal responsibility can even extend in some circumstances to developers who create and release code that is illegally used by others. Just last month, U.S. Commodity Futures Trading Commission commissioner Brian Quintenz gave a speech about how core developers and users of public blockchains generally should not be held legally responsible for unlawful activity that occurs on that blockchain. However, he acknowledged there is a lack of definitive guidance in the law, and proposed the appropriate liability standard for code developers to be whether “code developers could reasonably foresee, at the time they created the code, that it would likely be used by U.S. persons in a manner violative of CFTC regulations.”
It may sound surprising and scary for developers to have legal exposure for how other people use their code, but it’s the real world of how government agencies are prepared to think. For example, Augur has been under scrutiny for some time. Augur is a decentralized prediction-market protocol built on Ethereum; some characterize it as an illegal “bucket shop” or prediction market. When asked about Augur and the legal responsibility of its creators for what users do on the platform, CFTC spokeswoman Erica Elliott Richardson said in an email reply:
“[…] I can say generally that offering or facilitating a product or activity by way of releasing code onto a blockchain does not absolve any entity or individual from complying with pertinent laws or CFTC regulations.”
Recently, the U.S. Securities & Exchange Commission took concrete action which makes clear that operators of a decentralized service can in fact be liable for illegal activity committed by others on their network. The SEC charged EtherDelta, a supposed decentralized token exchange, and its founder with operating an unregistered securities exchange. It announced a settlement for EtherDelta’s founder to pay $388,000 in penalties, disgorgement, and interest. This case is seen as a warning sign to other decentralized exchanges. As Andrew Hinkes, an adjunct professor at the New York University School of Law, has most recently observed regarding the EtherDelta case:
“Just because you make it and then it gets operated by a decentralised network of others doesn’t mean that any prospective responsibility or liability is gone. It’s just possibly relocated.”
While many people may disagree with the legal standard proposed by the CFTC and the SEC case against EtherDelta, the message from these events is clear: even if you create or operate code and applications for a decentralized or P2P network, there are circumstances in which you can be liable for enabling or contributing to illegal activities of people who use that code or application. This includes code developers, if they can “reasonably foresee” their code is likely to be used for illegal purposes – at least if the CFTC Commissioner’s view is adopted as a legal standard. This could potentially also include other participants in the network, if their actions are reasonably foreseeable as contributing to illegal activity.
Outside of the cryptocurrency world, the legal system has witnessed many cases where computer programmers and technology providers have been criminally prosecuted or civilly sued because someone else illegally used their code or technology.
1. A Latvian computer programmer was sentenced to 14 years in prison by a Virginia federal court for designing Scan4You. That program was connected to the 2013 credit-card information hack of the Target retail store chain. The programmer argued the software could be used for lawful purposes, and said he should not be held responsible for when it was used illegally. The program allowed hackers to see if anti-virus programmes would identify their hacking software as malicious, who then packaged it into malware kits sold to cybercriminals. The court rejected the defendant’s theory that he should not be held liable because “all online businesses have legitimate and illegitimate users,” holding that such a theory does not apply in criminal cases like this one because, as he told the defendant, “There’s zero chance that you didn’t know the harm being done by the malware hackers used your service to perfect.”
2. An Arkansas software developer pleaded guilty for developing, marketing, and distributing products used by cybercriminals, though he claimed it was designed for legal purposes. Additional articles on the same case can be found here and here.
3. A 21-year old Kentucky developer created and sold a “remote access trojan,” claiming it was intended as a legitimate tool for system administrators, before later admitting in a plea agreement that he was aware some customers used the software to control others’ computers without their knowledge or permission.
4. The motion picture industry has successfully filed many lawsuits against file-sharing sites that use P2P software to facilitate illegal copyright infringement. The Betamax defense, as it came to be known was established in Sony Corporation of America v. Universal City Studios Inc., 464 U.S. 417 (1987); it stands for the proposition that the distributor of a technology product cannot be found liable for infringement by users if the product has “substantial non-infringing uses.” However, years later when presented with a case in the P2P context, Metro-Goldwyn-Mayer Studios Inc. v. Grokster Ltd., 545 U.S. 913 (2005), the U.S. Court Supreme Court held that while the Grokster service had substantial non-infringing uses, secondary liability for copyright infringement was possible given evidence that Grokster intentionally induced, encouraged, and had actual knowledge of direct copyright infringement on its platform.
Therefore, even if a technology can be used for non-infringing purposes, its provider and other operates can still have secondary liability for other people’s illegal of that technology. As a ComputerWorld sub-headline succinctly stated: “Companies that actively enable infringement can be held liable for sins of their users.”
Build Bitcoin for the Real World
Of course, these legal principles will evolve and may develop differently in the cryptocurrency world. And legal standards will vary from jurisdiction to jurisdiction. But the warning which everyone in the Bitcoin world should heed is this: do not advocate for technical features by identifying illegal use cases. You are just setting up legal risk for yourself, application providers, and other network participants who use your proposed feature.
At nChain, that’s why we always look at Bitcoin as more than a technical system. We do not propose technical features simply because they can replicate some feature developers envy on Ethereum or other blockchain projects. We do not propose technical changes because we feel like experimenting with Bitcoin. We carefully evaluate technical needs for Bitcoin’s growth to be sound, stable money and the global public blockchain of the future. But we always balance technical concepts with the economic, business, and legal impact.
That is why we support the Satoshi Vision and the Bitcoin SV implementation: a simpler approach to restore the original Bitcoin protocol, keep it stable, and allow it to massively scale. In order to achieve the Satoshi Vision – a world where big businesses and billions of people use Bitcoin – we need the BCH network to operate in the real world. Bitcoin must meet the needs of real businesses, real people, and real laws.
Jimmy Nguyen is CEO of the nChain Group. Before joining nChain, Jimmy had a 21-year career as an intellectual property and digital technology lawyer in the U.S., where he was a partner at three major law firms. In 2008, Lawdragon named him as one of the 500 Leading Lawyers in America.
nChain’s content analyst Sebastian Ploetzeneder contributed to this article.
With the protocol upgrade of the Bitcoin BCH blockchain scheduled for today, most Bitcoin BCH enthusiasts had expected Bitcoin ABC to be the strong favorite above rival Bitcoin SV. However, the community is speaking, and speaking loudly. Not only is Bitcoin SV proving to control the hash war, BCHSV is proving to be stronger than BCHABC in the markets.
BCHABC has dropped substantially in price, falling more than 38% since its inception, according to the Poloniex exchange. Conversely, BCHSV is surging and has increased by more than 100%. At the time of this writing, in the past 24 hours, BCHSV has climbed 8.57% and BCHABC has fallen another 15.22%.
Two days ago, BCHABC saw one of its biggest movements. BitMEX futures showed the price drop a little more than 62%.
The debate over which direction Bitcoin BCH should head has been greatly heated and has resulted in two distinct trains of thought. On the one hand, Bitcoin ABC has been more concerned with creating a virtual “playground” out of Bitcoin BCH, where developers can introduce new features and changes basically on a whim without taking into consideration the impact those changes have on the long-term acceptance of the blockchain.
On the other hand, Bitcoin SV proponents want to improve the network. They want to make it highly scalable for future acceptance by both businesses and merchants and continue to allow the cryptocurrency to grow as a viable currency. This is the only reason that cryptocurrency even makes sense.
Bitcoin ABC also supports the highly contentious OP_CHECKDATASIG, or DSV, OP_CODE, which has already shown to not provide any utility to the network. Despite repeated demonstrations that it can be detrimental to Bitcoin BCH’s growth, Bitcoin ABC pundits have continued to push forward, against the will of a growing number of enthusiasts.
While everyone is entitled to their own opinions, when those opinions stifle progress and go against the wishes of a community, they become irrelevant. Cryptocurrency exists for one reason and one reason only—to be spent. Some developers have felt it necessary to try and force their will on the community, but it is now apparent that the community has spoken and its wishes need to be respected, as well as accepted.
The upcoming hard fork for the Bitcoin BCH network has produced a fervor. It’s one of the hottest topics on social media sites such as Reddit and Twitter with a persistence divide between those that support Bitcoin SV—and the idea that cryptocurrency needs to be seen as currency—and Bitcoin ABC, which is more driven to completely alter the work that has thus far gone into creating a viable digital currency. As it stands now, just three days ahead of the network upgrade, more miners are showing support for Bitcoin SV.
Bitcoin SV is now supported by 66% of Bitcoin BCH miners, according to data found on Coin Dance. This is a good sign, as it shows that miners understand that Bitcoin SV will prevent the blockchain from implementing changes that do nothing to enhance the network. Certain developers, and even some mining companies such as Bitmain, appear to be willing to use Bitcoin BCH as their personal sandbox, undermining the importance of cryptocurrency.
Bitcoin ABC is only supported by around 32% of miners, according to the same data. Bitcoin Unlimited—only versions 1.5 and newer—will follow Bitcoin ABC; all older versions won’t be compatible with either side following the fork.
One of the most contentious upgrades proposed by the likes of Bitmain’s Jihan Wu and other like-minded individuals would be the OP_CODE OP_CHECKDATASIG, or DSV. It has already been shown to provide no utility to the network and could actually lead to the introduction of criminalization of the Bitcoin BCH blockchain.
Another highly contested project is the canonical transaction ordering rule (CTOR). CTOR would completely change how transactions how transactions are sorted and—just like DSV—does not do anything to progress the blockchain. Following multiple requests, CTOR’s developers have yet to provide a single example of why CTOR needs to be introduced. It only serves as another example of how certain developers want to continue to unnecessarily “tinker” with the blockchain.
Hard fork, discord and disagreements aside, Bitcoin BCH is still a better option than Bitcoin Core (BTC), and it will continue to be so following the hard fork. It is a blockchain that is more efficient and which offers cheaper transactions than BTC. According to data available from Coin Dance, BCH transactions are 10 times cheaper than are BTC transactions.
When Bitcoin split into two chains in August of 2017, it did so because the original roadmap for Bitcoin was hijacked, and there existed an economic pressure to see the fulfilment of the original vision. This economic pressure not only resulted in the rebirth of Bitcoin in BCH but was also the cause of the sudden increase in value among numerous cryptocurrencies, which we have collectively come to refer as “alt-coins.” The fact that BTC’s congested chain ‘helped’ the market cap of many of these alt-coins is rather difficult to dispute. Certainly, the timed correlation of events between BTC blocks ‘becoming full’ (therefore limiting BTC usage), and having transactional utility (and market cap) grow in alts cannot be overlooked.
Original Bitcoin doesn’t mean that we need to strip back a hundred thousand lines of code to go back to the original three thousand lines Satoshi had in his first release. It is the design concept. That is—simple, electronic cash.
I say simple because simplicity is a fundamental key to a secure, stable system. Every hardened software engineer with years of experience under their belt knows precisely what this means. Certainly, the vast majority of security researchers understand this. Complexity is no friend to security.
ABC’s controversial ordering change CTO, and subsequently, CoinGeek and nChain’s move to create a competing client designed to continue in the restoration of the original Satoshi implementation, have caused the Bitcoin BCH ecosystem to become divided.
Such division within a decentralized system is not only possible but bound to happen. And almost certainly, there will be many repeats of divisions of this nature.
Roger Ver, CEO of Bitcoin.com, recently pointed out this very fact during a live debate with Bitcoin Core’s Jimmy Song. The division within BCH is evidence that teams have to fight and invest to have their preferred client decide the rules of consensus. There is no leadership, and this is why the struggle is real. Amusingly in this very debate, we did see a very confident Jimmy Song who started out his debate by reading from a script, slowly become relegated into a mumbling mess by the end of it. I digress.
No matter what outcome in November, one team will get their way, and the other team, sadly, will not. But BCH development will continue. And assuredly, another challenge will come from another competing client at some point. There is a reason we call these “competing” clients. At some point, they intend to mount some challenge over the code.
Locking down the protocol
CoinGeek and friends have already stated that they wish to “lock down the protocol.” This has received some mixed, some positive, and some violent opposition. I want to address the meaning behind this statement, and the motivation.
Firstly, let’s do away with the rumours. Locking down the protocol translates to a desire for a stable protocol that does not change at the whim of every developer. It does not in any way, mean that the protocol must not change under any circumstance. Such a move would be very foolish.
So what changes are welcome?
Two words: risks & opportunities. Over time, coders, testers, and well-meaning individuals may very well find and disclose vulnerabilities. Depending on the criticality of an issue, a change may be executed rather quickly.
Opportunities on the other hand need to be evaluated more critically. Unlike risks, opportunities do not present a ‘ticking time-bomb,’ and can afford the luxury of considerable time, research and testing.
Stability of code is mightily important when dealing with security. In fact, numerous studies have already confirmed the long-suspected correlation between complexity and security reduction.
CoinGeek is not closed to protocol improving opportunities. But CoinGeek does believe in employing stringent measures on any change that is not deemed a fix to an underlying vulnerability. These stringent measures involve questions such as:
Can the current suite of opcodes achieve the same desired output?
Does the function proposed affect the cash use case in any way?
Does the function affect the network topology?
Does the function affect the inbuilt incentives of the system?
Can we achieve a similar function safely in any other way?
These are some of the questions that CoinGeek would like to see sufficiently addressed before considering opportune changes to protocol. Further, there needs to be a substantial benefit without introducing any risk.
Why these measures?
nChain’s Dr. Wright, stating that the protocol needs to be stable isn’t some misplaced comment. It is a sound, research-backed position that a vast majority of security researchers agree with.
Bruce Schneier, a respected cryptographer and security researcher, who’s written volumes of information on the subject, concludes: “complexity is the worst enemy of security.”
The bigger a program, the bigger the attack surface. At least, that’s how the correlated graph goes. There are a number of reasons for this. A research paper from McCabe titled “More Complex = Less Secure: Miss a Test Path and You Could Get Hacked” lists the following points as key reasons:
Complex systems have more lines of code and therefore security bugs.
Complex systems have more interactions and therefore more security bugs.
Complex systems are harder to test and therefore, more likely to have untested portions.
Complex systems are harder to design securely, implement securely, configure securely and use securely.
Complex systems are harder for users to understand.
This is actually a key reason why Ethereum has suffered so many hacks, from the DAO hack (which resulted in the theft of 15% of all Ether in circulation at the time) to the parity freeze which saw half a million Eth frozen. Ethereum sure is powerful… It is Turing complete, enables us to create practically any application on-chain, but also has drawbacks in scalability, usability, and importantly, security.
Bitcoin has over 100,000 lines of code. Ethereum on the other hand has well over a million lines of code. Given the complex architecture of, not just Ethereum itself, but of the smart contracts built on top of it, it is no wonder that Ethereum’s strength, is also its weakness.
In a post titled ‘A Plea for Simplicity’ Schneier once wrote:
“We’ve seen security bugs in almost everything: operating systems, applications programs, network hardware and software, and security products themselves. This is a direct result of the complexity of these systems. The more complex a system is–the more options it has, the more functionality it has, the more interfaces it has, the more interactions it has–the harder it is to analyse. Everything is more complicated: the specification, the design, the implementation, the use. And everything is relevant to security analysis.”
Many developers overlook the significant importance of testing. Many will test various functions, and run simulations across a range of inputs. Rarely is every path tested. And rarely do some testers ever even look at binary analysis.
Every opcode we add over time results in an increased complexity. This in no way shutting down future opportunities for improvement. And CoinGeek may choose to welcome profoundly opportune changes that can catapult BCH utility. But CoinGeek and friends choose to err on the side of caution.
Let it be re-stated that locking down the protocol does not equate to never touching the protocol again. Moreover, in a decentralized environment where at any point a new miner can take the lead, consensus over the protocol can change at any point.
It’s easy to become excited and consumed by the latest gadget or idea that we often lose sight of the forest for the trees. Bitcoin is the only Proof of Work based cryptocurrency that can scale to global adoption, and it has the community and the drive to do so. The killer-app is money, and CoinGeek seeks to propel BCH to become not only the most dominant crypto-currency in the market but also become world-wide global cash.
CoinGeek’s position on seeking a stable protocol may upset some people, but the position is backed by studies and by some of the most well-respected security researchers. Bitcoin Satoshi Vision intends to resurrect original Bitcoin, uncapped, with all opcodes enabled. This move isn’t scary, nor is it dangerous. It is in fact, the original value proposition of Bitcoin. CoinGeek supports the roadmap that first seeks to restore the original implementation first and foremost, before making considerations for other changes.
We believe that in order to become global money and see BCH reach global adoption, we need to prove that the platform is indeed stable and that businesses can ‘trust’ that protocol development will not impede their actions. BTC has a history of tampering with the code in a manner that kills business. Consistency is important, stability is important, and the electronic cash use case comes first.
Yesterday morning, CoinEx, a company whose CEO, Haipo Yang of ViaBTC, supports Bitmain on the ABC stance, issued the following statement concerning the Bitcoin Cash hard fork in November:
The statement has caused confusion among investors, who were otherwise led to believe by Bitcoin SV supporting teams that the competing client would not produce a split.
nChain and CoinGeek, two of the biggest mining backers of the Bitcoin SV client, categorically deny any willingness or attempt to create an alternate fork chain, and will instead be competing over Bitcoin BCH directly, by the very definition of ‘Nakamoto consensus’. That is, the consensus mechanism inherently built into Bitcoin, as referenced in the founding whitepaper.
CoinGeek has noted a number of factually incorrect statements and issues the following responses:
“Bitcoin-SV (BSV) is the altered version of Bitcoin Cash protocols.”
This point is blatantly false. CoinGeek would like to request from CoinEx, a definition of ‘Bitcoin Cash protocols’. By implying that Bitcoin SV introduces an altered set of protocols, then by definition, so does ABC with their November hard-fork. Any upgrade would be effectively doing this.
We are therefore led to believe the only possible explanation to this statement is that CoinEx believes that ABC holds literal ownership of the Bitcoin Cash (BCH) brand.
This is not too dissimilar to a time in 2015, when Bitcoin XT, a competing client to the ‘BitcoinCore’ client was incorrectly labelled an alt-coin. Despite being an optional fork of the client with slightly different network protocols, Bitcoin XT was misleadingly branded an alt-coin on all BitcoinCore backed websites and forums. We fear the implication here is similar.
The next point on CoinEx’s statement follows on:
“BSV is likely to bring a potential fork of Bitcoin Cash by causing incompatibility with Bitcoin Cash network and therefore create a new cryptocurrency asset – Bitcoin-SV (Token: BSV)”
If Nakamoto consensus rules that Bitcoin SV is the dominant client, then there is no “incompatibility”. In fact in such a scenario, the only incompatibility will come from non Bitcoin SV compliant nodes in that case, which would mean ABC in this case.
Fundamentally it is premature to specify which client is “incompatible” and which client will be majority or minority. Nakamoto consensus determines this, not exchanges. Bitcoin is not democratic. The vote isn’t 1 vote per person, but 1 vote per CPU (hash).
In response to the statement, CEO of nChain Group, Jimmy Nguyen makes the key point that “Bitcoin SV is not intending nor trying to fork off from Bitcoin Cash, and Bitcoin SV is not intending to create a new coin or token. Instead, as stated in its announcement, Bitcoin SV is a professionally-driven implementation of the Bitcoin full node software for use on BCH, and is intended to provide a clear BCH implementation choice for miners who support Bitcoin’s original vision. Bitcoin SV intends to compete for miners’ votes (under Nakamoto consensus) to be the winning BCH chain”.
It is worth also noting, that recently, yet another team announced a new BCH implementation, like Bitcoin SV, it intends to fulfill the original Satoshi vision. This is called “Protocol Client” and its github repository can be found here:
CoinEx has made no mention of “Protocol Client” however, despite this being another client with different rules.
Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.
The Ledger team has resolved the reported sudden lack of Bitcoin Cash support on its wallet.
On Wednesday, a Ledger spokesperson confirmed to CoinGeek that “this issue has now been resolved.”
“Recent updates to Bitcoin Cash infrastructure resulted in Ledger customers seeing inaccurate balances displayed on their BCH Wallets. As a result of Bitcoin Cash infrastructure changes, Ledger software was temporarily unable to acquire balance and transaction information from the Bitcoin Cash blockchain. This issue has now been resolved. Customers do not need to take any action, and BCH balances will be updated automatically. We apologise for any inconvenience,” the spokesperson said.
On the Reddit forum /r/ledgerwallet, users complained that they have been unable to access their funds on the Ledger wallet for the past two days due to technical problems. Some users reported encountering problems with their transactions if they use BCH as currency, while others are completely shut out of their balances.
According to a Reddit user who wanted to transfer from Coinbase to Nano S, transfers involving SegWit-Coin BTC, LTC and ETH went through just fine but the BCH transaction did not work although the QT Code was scanned accordingly for funds to be received. The user complained that after 36 hours nothing had happened. The situation has created consternation amongst Ledger Wallet users who have taken to social media to voice their concerns.
Ledger Wallet initially addressed the incident in a tweet and also posted an “Active Incident” report after the degraded performance of BCH transactions. The report, which was lodged on April 9 at 7:10 a.m. UTC, noted that “the new version of Bitcoin ABC (Bitcoin Cash node) breaks compatibility with our parser.” This resulted in incorrect result balances on the Ledger Wallet, according to the team.
Ledger maintained that all funds were safe and can still be accessed in emergency situations using the software wallet Electron Cash.
Following an outage, we're working on bringing back our BCH infrastructure. You can get real time update of the operation at https://t.co/oSjVWsIxrU
Despite the immediate response, users still hit out at Ledger over the company’s inordinate amount of time it took for the problem to be solved. Nicolas Bacca, CTO of Ledger, addressed the issue, saying:
“The team is still investigating. I’m not following this closely, but if invalid data was fed into our parser it could be necessary to reparse the whole chain which will take a few days. Thanks for your patience, and feel free to open an issue on Electron Cash github if it isn’t working properly… for any blogger trying to misquote me—this means that another team is working on it as fast as they can, but not myself.”
Meanwhile, CEO Eric Larchevêque assured its clients that Ledger’s entire infrastructure engineering team “is working on fixing the outage since we have been aware a day ago.”
The incident report previously stated: “Our main servers are now synced and running. We’ll run on a degraded infrastructure the time for us to ensure that everything is fine (next 12 hours). Once we’re sure that everything is running smoothly, we’ll apply our patches to Ledger blockchain explorer and the BCH daemon before we sync the rest of our infrastructure.”
Note: Tokens in the SegWit chain are referred to as SegWit-Coin BTC (inaccurately called Bitcoin Legacy or Core by many) and SegWit Gold (SWG) and are no longer Bitcoin. Bitcoin Cash (BCH) is the only true Bitcoin as intended by the original Satoshi white paper. Bitcoin BCH is the only public block chain that offers safe and cheap microtransactions.