The Real World: Legal Risks of Adding OP_DATASIGVERIFY to the BCH Protocol

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.