Blockchain briefing for DoD

I was asked to deliver Blockchain: What's Not To Like? version 3.0 to a Department of Defense conference-call. I took the opportunity to update the talk, and expand it to include some of the "Additional Material" from the original, and from the podcast. Below the fold, the text of the talk with links to the sources. The yellow boxes contain material that was on the slides but was not spoken.
[Slide 1]

It’s one of these things that if people say it often enough it starts to sound like something that could work,

Sadhbh McCarthy

I'd like to thank Jen Snow for giving me the opportunity to talk about blockchain technology and cryptocurrencies. The text of my talk with links to the sources is up on my blog, so you don't need to take notes.

There's been a supernova of hype about them. Almost everything positive you have heard is paid advertising, and should be completely ignored. Why am I any more credible? First, I'm retired. No-one is paying me to speak, and I have no investments in cryptocurrencies or blockchain companies.

[Slide 2]

This is not to diminish Nakamoto's achievement but to point out that he stood on the shoulders of giants. Indeed, by tracing the origins of the ideas in bitcoin, we can zero in on Nakamoto's true leap of insight—the specific, complex way in which the underlying components are put together.

Bitcoin's Academic Pedigree,
Arvind Narayanan and Jeremy Clark

Second, I've been writing skeptically about cryptocurrencies and blockchain technology for more than five years. What are my qualifications for such a long history of pontification?

Nearly sixteen years ago, about five years before Satoshi Nakamoto published the Bitcoin protocol, a cryptocurrency based on a decentralized consensus mechanism using proof-of-work, my co-authors and I won a "best paper" award at the prestigious SOSP workshop for a decentralized consensus mechanism using proof-of-work. It is the protocol underlying the LOCKSS system. The originality of our work didn't lie in decentralization, distributed consensus, or proof-of-work. All of these were part of the nearly three decades of research and implementation leading up to the Bitcoin protocol, as described by Arvind Narayanan and Jeremy Clark in Bitcoin's Academic Pedigree. Our work was original only in its application of these techniques to statistical fault tolerance; Nakamoto's only in its application of them to preventing double-spending in cryptocurrencies.

We're going to start by walking through the design of a system to perform some function, say monetary transactions, storing files, recording reviewers' contributions to academic communication, verifying archival content, whatever. My goal is to show you how the pieces fit together in such a way that the problems the technology encounters in practice aren't easily fixable; they are inherent in the underlying requirements.

Being of a naturally suspicious turn of mind, you don't want to trust any single central entity, but instead want a decentralized system. You place your trust in the consensus of a large number of entities, which will in effect vote on the state transitions of your system (the transactions, reviews, archival content, ...). You hope the good entities will out-vote the bad entities. In the jargon, the system is trustless (a misnomer).

Techniques using multiple voters to maintain the state of a system in the presence of unreliable and malign voters were first published in The Byzantine Generals Problem by Lamport et al in 1982. Alas, Byzantine Fault Tolerance (BFT) requires a central authority to authorize entities to take part. In the blockchain jargon, it is permissioned. You would rather let anyone interested take part, a permissionless system with no central control.

[Slide 3]

In the case of blockchain protocols, the mathematical and economic reasoning behind the safety of the consensus often relies crucially on the uncoordinated choice model, or the assumption that the game consists of many small actors that make decisions independently.

The Meaning of Decentralization,
Vitalik Buterin, co-founder of Ethereum

The security of your permissionless system depends upon the assumption of uncoordinated choice, the idea that each voter acts independently upon its own view of the system's state.

If anyone can take part, your system is vulnerable to Sybil attacks, in which an attacker creates many apparently independent voters who are actually under his sole control. If creating and maintaining a voter is free, anyone can win any vote they choose simply by creating enough Sybil voters.

[Slide 4]

From a computer security perspective, the key thing to note ... is that the security of the blockchain is linear in the amount of expenditure on mining power, ... In contrast, in many other contexts investments in computer security yield convex returns (e.g., traditional uses of cryptography) ... analogously to how a lock on a door increases the security of a house by more than the cost of the lock.

The Economic Limits of Bitcoin and the Blockchain,
Eric Budish, Booth School, University of Chicago

So creating and maintaining a voter has to be expensive. Permissionless systems can defend against Sybil attacks by requiring a vote to be accompanied by a proof of the expenditure of some resource. This is where proof-of-work comes in; a concept originated by Cynthia Dwork and Moni Naor in 1992. In a BFT system, the value of the next state of the system is that computed by the majority of the nodes. In  a proof-of-work system such as Bitcoin, the value of the next state of the system is that computed by the first node to solve a puzzle. There is no guarantee that any other node computed that value; BFT is a consensus system whereas Bitcoin-type systems select a winning node.

Proof-of-work is a random process, but at scale the probability of being selected is determined by how quickly you can compute hashes. The idea is that the good voters will spend more on hashing power, and thus compute more useless hashes, than the bad voters.

[Slide 5]

The blockchain trilemma

much of the innovation in blockchain technology has been aimed at wresting power from centralised authorities or monopolies. Unfortunately, the blockchain community’s utopian vision of a decentralised world is not without substantial costs. In recent research, we point out a ‘blockchain trilemma’ – it is impossible for any ledger to fully satisfy the three properties shown in [the diagram] simultaneously ... In particular, decentralisation has three main costs: waste of resources, scalability problems, and network externality inefficiencies.

The economics of blockchains,
Markus K Brunnermeier & Joseph Abadi, Princeton

Brunnermeir and Abadi's Blockchain Trilemma shows that a blockchain has to choose at most two of the following three attributes:

• correctness
• decentralization
• cost-efficiency

Obviously, your system needs the first two, so the third has to go. Running a voter (mining in the jargon) in your system has to be expensive if the system is to be secure. No-one will do it unless they are rewarded. They can't be rewarded in "fiat currency", because that would need some central mechanism for paying them. So the reward has to come in the form of coins generated by the system itself, a cryptocurrency. To scale, permissionless systems need to be based on a cryptocurrency; the system's state transitions will need to include cryptocurrency transactions in addition to records of files, reviews, archival content, whatever.

Your system needs names for the parties to these transactions. There is no central authority handing out names, so the parties need to name themselves. As proposed by David Chaum in 1981 they can do so by generating a public-private key pair, and using the public key as the name for the source or sink of each transaction.

[Slide 6]

we created a small Bitcoin wallet, placed it on images in our honeyfarm, and set up monitoring routines to check for theft. Two months later our monitor program triggered when someone stole our coins.

This was not because our Bitcoin was stolen from a honeypot, rather the graduate student who created the wallet maintained a copy and his account was compromised. If security experts can't safely keep cryptocurrencies on an Internet-connected computer, nobody can. If Bitcoin is the "Internet of money," what does it say that it cannot be safely stored on an Internet connected computer?

Risks of Cryptocurrencies,
Nicholas Weaver, U.C. Berkeley

In practice this is implemented in wallet software, which stores one or more key pairs for use in transactions. The public half of the pair is a pseudonym. Unmasking the person behind the pseudonym turns out to be fairly easy in practice.

The security of the system depends upon the user and the software keeping the private key secret. This can be difficult, as Nicholas Weaver's computer security group at Berkeley discovered when their wallet was compromised and their Bitcoins were stolen.

[Slide 7]

2-yr Bitcoin "price" history

The capital and operational costs of running a miner include buying hardware, power, network bandwidth, staff time, etc. Bitcoin's volatile "price", high transaction fees, low transaction throughput, and large proportion of failed transactions mean that almost no legal merchants accept payment in Bitcoin or other cryptocurrency. Thus one essential part of your system is one or more exchanges, at which the miners can sell their cryptocurrency rewards for the "fiat currency" they need to pay their bills.

Who is on the other side of those trades? The answer has to be speculators, betting that the "price" of the cryptocurrency will increase. Thus a second essential part of your system is a general belief in the inevitable rise in "price" of the coins by which the miners are rewarded. If miners believe that the "price" will go down, they will sell their rewards immediately, a self-fulfilling prophesy. Over time, permissionless blockchains require an inflow of speculative funds at an average rate greater than the current rate of mining rewards if the "price" is not to collapse. To maintain Bitcoin's price at $10K would require an inflow of $750K/hour, or about $5B from now until the next reward halving around May 20^th 2020. 

[Slide 8]

Ether miners 07/09/19

can we really say that the uncoordinated choice model is realistic when 90% of the Bitcoin network’s mining power is well-coordinated enough to show up together at the same conference?

The Meaning of Decentralization,
Vitalik Buterin

In order to spend enough to be secure, say $750K/hour, you need a lot of miners. It turns out that a third essential part of your system is a small number of “mining pools”. A year ago Bitcoin had the equivalent of around 3M Antminer S9s, and a block time of 10 minutes. Each S9, costing maybe $1K, could expect a reward about once every 60 years. It would be obsolete in about a year, so only 1 in 60 would ever earn anything.

To smooth out their income, miners join pools, contributing their mining power and receiving the corresponding fraction of the rewards earned by the pool. These pools have strong economies of scale, so successful cryptocurrencies end up with a majority of their mining power in 3-4 pools. Each of the big pools can expect a reward every hour or so. These blockchains aren’t decentralized, but centralized around a few large pools.

At multiple times in 2014 one mining pool controlled more than 51% of the Bitcoin mining power. At almost all times since 3-4 pools have controlled the majority of the Bitcoin mining power. Currently two of them, with 35.2% of the power, are controlled by Bitmain, the dominant supplier of mining ASICs. With the advent of mining-as-a-service, 51% attacks have become endemic among the smaller alt-coins.

The security of a blockchain depends upon the assumption that these few pools are not conspiring together outside the blockchain; an assumption that is impossible to verify in the real world (and by Murphy's Law is therefore false).

[Slide 9]

Since then there have been other catastrophic bugs in these smart contracts, the biggest one in the Parity Ethereum wallet software ... The first bug enabled the mass theft from "multisignature" wallets, which supposedly required multiple independent cryptographic signatures on transfers as a way to prevent theft. Fortunately, that bug caused limited damage because a good thief stole most of the money and then returned it to the victims. Yet, the good news was limited as a subsequent bug rendered all of the new multisignature wallets permanently inaccessible, effectively destroying some $150M in notional value. This buggy code was largely written by Gavin Wood, the creator of the Solidity programming language and one of the founders of Ethereum. Again, we have a situation where even an expert's efforts fell short.

Risks of Cryptocurrencies,
Nicholas Weaver, U.C. Berkeley

In practice the security of a blockchain depends not merely on the security of the protocol itself, but on the security of both the core software, and the wallets and exchanges used to store and trade its cryptocurrency. This ancillary software has bugs, such as last September's major vulnerability in Bitcoin Core, the Parity Wallet fiasco, the routine heists using vulnerabilities in exchange software, and the wallet that was sending user's pass-phrases to the Google spell-checker over HTTP. Who doesn't need their pass-phrase spell-checked?

Recent game-theoretic analysis suggests that there are strong economic limits to the security of cryptocurrency-based blockchains. To guarantee safety, the total value of transactions in a block needs to be less than the value of the block reward, which kind of spoils the whole idea.

Your system needs an append-only data structure to which records of the transactions, files, reviews, archival content, whatever are appended. It would be bad if the miners could vote to re-write history, undoing these records. In the jargon, the system needs to be immutable (another misnomer).

[Slide 10]

Merkle Tree (source)

The necessary data structure for this purpose was published by Stuart Haber and W. Scott Stornetta in 1991. A company using their technique has been providing a centralized service of securely time-stamping documents for nearly a quarter of a century. It is a form of Merkle or hash tree, published by Ralph Merkle in 1980. For blockchains it is a linear chain to which fixed-size blocks are added at regular intervals. Each block contains the hash of its predecessor; a chain of blocks.

The blockchain is mutable, it is just rather hard to mutate it without being detected, because of the Merkle tree’s hashes, and easy to recover, because there are Lots Of Copies Keeping Stuff Safe. But this is a double-edged sword. Immutability makes systems incompatible with the GDPR, and immutable systems to which anyone can post information will be suppressed by governments.

[Slide 11]

BTC transaction fees

Cryptokitties’ popularity exploded in early December and had the Ethereum network gasping for air. ... Ethereum has historically made bold claims that it is able to handle unlimited decentralized applications  ... The Crypto-Kittie app has shown itself to have the power to place all network processing into congestion. ... at its peak [CryptoKitties] likely only had about 14,000 daily users. Neopets, a game to which CryptoKitties is often compared, once had as many as 35 million users.

How Crypto-Kitties Disrupted the Ethereum Network,
Open Trading Network

A user of your system wanting to perform a transaction, store a file, record a review, whatever, needs to persuade miners to include their transaction in a block. Miners are coin-operated; you need to pay them to do so. How much do you need to pay them? That question reveals another economic problem, fixed supply and variable demand, which equals variable "price". Each block is in effect a blind auction among the pending transactions.

So lets talk about CryptoKitties, a game that bought the Ethereum blockchain to its knees despite the bold claims that it could handle unlimited decentralized applications. How many users did it take to cripple the network? It was far fewer than non-blockchain apps can handle with ease; CryptoKitties peaked at about 14K users. NeoPets, a similar centralized game, peaked at about 2,500 times as many.

CryptoKitties average "price" per transaction spiked 465% between November 28 and December 12 as the game got popular, a major reason why it stopped being popular. The same phenomenon happened during Bitcoin's price spike around the same time. Cryptocurrency transactions are affordable only if no-one wants to transact; when everyone does they immediately become un-affordable.

Nakamoto's Bitcoin blockchain was designed only to support recording transactions. It can be abused for other purposes, such as storing illegal content. But it is likely that you need additional functionality, which is where Ethereum's "smart contracts" come in. These are fully functional programs, written in a JavaScript-like language, embedded in Ethereum's blockchain. They are mainly used to implement Ponzi schemes, but they can also be used to implement Initial Coin Offerings, games such as Cryptokitties, and gambling parlors. Further, in On-Chain Vote Buying and the Rise of Dark DAOs Philip Daian and co-authors show that "smart contracts" also provide for untraceable on-chain collusion in which the parties are mutually pseudonymous.

[Slide 12]

ICO Returns

The first big smart contract, the DAO or Decentralized Autonomous Organization, sought to create a democratic mutual fund where investors could invest their Ethereum and then vote on possible investments. Approximately 10% of all Ethereum ended up in the DAO before someone discovered a reentrancy bug that enabled the attacker to effectively steal all the Ethereum. The only reason this bug and theft did not result in global losses is that Ethereum developers released a new version of the system that effectively undid the theft by altering the supposedly immutable blockchain.

Risks of Cryptocurrencies,
Nicholas Weaver, U.C. Berkeley

"Smart contracts" are programs, and programs have bugs. Some of the bugs are exploitable vulnerabilities. Research has shown that the rate at which vulnerabilities in programs are discovered increases with the age of the program. The problems caused by making vulnerable software immutable were revealed by the first major "smart contract". The Decentralized Autonomous Organization (The DAO) was released on 30^th April 2016, but on 27^th May 2016 Dino Mark, Vlad Zamfir, and Emin Gün Sirer posted A Call for a Temporary Moratorium on The DAO, pointing out some of its vulnerabilities; it was ignored. Three weeks later, when The DAO contained about 10% of all the Ether in circulation, a combination of these vulnerabilities was used to steal its contents.

The loot was restored by a "hard fork", the blockchain's version of mutability. Since then it has become the norm for "smart contract" authors to make them "upgradeable", so that bugs can be fixed. "Upgradeable" is another way of saying "immutable in name only".

[Slide 13]

security researchers from SRLabs revealed that a large chunk of the Ethereum client software that runs on Ethereum nodes has not yet received a patch for a critical security flaw the company discovered earlier this year.

"According to our collected data, only two thirds of nodes have been patched so far," said Karsten Nohl, ... "The Parity Ethereum has an automated update process - but it suffers from high complexity and some updates are left out," Nohl said.

All of these issues put all Ethereum users at risk, and not just the nodes running unpatched versions. The number of unpatched notes may not be enough to carry out a direct 51% attack, but these vulnerable nodes can be crashed to reduce the cost of a 51% attack on Ethereum, currently estimated at around $120,000 per hour. ...  "The patch gap signals a deep-rooted mistrust in central authority, including such any authority that can automatically update software on your computer."

A large chunk of Ethereum clients remain unpatched Catalin Cimpanu

It isn't just the "smart contracts" that need to be upgradeable, it is the core software for the blockchain. Bugs and vulnerabilities are inevitable. If you trust a central authority to update your software automatically, or if you don't but you think others do, what is the point of a permissionless blockchain?

[Slide 14]

Permissionless systems trust:

• The core developers of the blockchain software not to write bugs.
• The developers of your wallet software not to write bugs.
• The developers of the exchanges not to write bugs.
• The operators of the exchanges not to manipulate the markets or to commit fraud.
• The developers of your upgradeable "smart contracts" not to write bugs.
• The owners of the smart contracts to keep their secret key secret.
• The owners of the upgradeable smart contracts to avoid losing their secret key.
• The owners and operators of the dominant mining pools not to collude.
• The operators of miners to apply patches in a timely manner.
• The speculators to provide the funds needed to keep the “price” going up.
• Users' ability to keep their secret key secret.
• Users’ ability to avoid losing their secret key.
• Other users not to transact when you want to.

So, this is the list of people your permissionless system has to trust if it is going to work as advertised over the long term.

You started out to build a trustless, decentralized system but you have ended up with:

• A trustless system that trusts a lot of people you have every reason not to trust.
• A decentralized system that is centralized around a few large mining pools that you have no way of knowing aren’t conspiring together.
• An immutable system that either has bugs you cannot fix, or is not immutable
• A system whose security depends on it being expensive to run, and which is thus dependent upon a continuing inflow of funds from speculators.
• A system whose coins are convertible into large amounts of "fiat currency" via irreversible pseudonymous transactions, which is thus an irresistible target for crime.

If the “price” keeps going up, the temptation for your trust to be violated is considerable. If the "price" starts going down, the temptation to cheat to recover losses is even greater.

Maybe it is time for a re-think.

Suppose you give up on the idea that anyone can take part and accept that you have to trust a central authority to decide who can and who can’t vote. You will have a permissioned system.

The first thing that happens is that it is no longer possible to mount a Sybil attack, so there is no reason running a node need be expensive. You can use BFT to establish consensus, as IBM’s Hyperledger, the canonical permissioned blockchain system plans to. You need many fewer nodes in the network, and running a node just got way cheaper. Overall, the aggregated cost of the system got orders of magnitude cheaper.

Now there is a central authority it can collect “fiat currency” for network services and use it to pay the nodes. No need for cryptocurrency, exchanges, pools, speculators, or wallets, so much less temptation for bad behavior.

[Slide 15]

Permissioned systems trust:

• The central authority.
• The software developers.
• The owners and operators of the nodes.
• The secrecy of a few private keys.

This is now the list of entities you trust. Trusting a central authority to determine the voter roll has eliminated the need to trust a whole lot of other entities. The permissioned system is more trustless and, since there is no need for pools, the network is more decentralized despite having fewer nodes.

[Slide 16]

1

4

2

7

3

10

4

13

5

16

6

19

a Byzantine quorum system of size 20 could achieve better decentralization than proof-of-work mining at a much lower resource cost.

Decentralization in Bitcoin and Ethereum Networks,
Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert van Renesse and Emin Gün Sirer

How many nodes does your permissioned blockchain need? The rule for BFT is that 3f + 1 nodes can survive f simultaneous failures. That's an awful lot fewer than you need for a permissionless proof-of-work blockchain. What you get from BFT is a system that, unless it encounters more than f simultaneous failures, remains available and operating normally.

The problem with BFT is that if it encounters more than f simultaneous failures, the state of the system is irrecoverable. If you want a system that can be relied upon for the long term you need a way to recover from disaster. Successful permissionless blockchains have Lots Of Copies Keeping Stuff Safe, so recovering from a disaster that doesn't affect all of them is manageable.

[Slide 17]

Source

So in addition to implementing BFT you need to back up the state of the system each block time, ideally to write-once media so that the attacker can't change it. But if you're going to have an immutable backup of the system's state, and you don't need continuous uptime, you can rely on the backup to recover from failures. In that case you can get away with, say, 2 replicas of the blockchain in conventional databases, saving even more money.

I've shown that, whatever consensus mechanism they use, permissionless blockchains are not sustainable for very fundamental economic reasons. These include the need for speculative inflows and mining pools, security linear in cost, economies of scale, and fixed supply vs. variable demand. Proof-of-work blockchains are also environmentally unsustainable. The top 5 cryptocurrencies are estimated to use as much energy as The Netherlands. This isn't to take away from Nakamoto's ingenuity; proof-of-work is the only consensus system shown to work well for permissionless blockchains. The consensus mechanism works, but energy consumption and emergent behaviors at higher levels of the system make it unsustainable.

[Slide 18]

Mentions in S&P500 quarterlies

Still new to NYC, but I met this really cool girl. Energy sector analyst or some such. Four dates in, she uncovers my love for BitCoin.

Completely ghosted.

Zack Voell

S&P500 companies are slowly figuring out that there is no there there in blockchains and cryptocurrencies, and they're not the only ones:

So if both permissionless and permissioned blockchains are fatally flawed, and experts in both cryptography and economics have been saying so for many years, how come they are generally perceived as huge successes?

The story starts in the early 80s with David Chaum. His work on privacy was an early inspiration for the cypherpunks. Many of the cypherpunks were libertarians, so the idea of money not controlled by governments was attractive. But Chaum's pioneering DigiCash was centralized, a fatal flaw in their eyes. It would be two decades before the search for a practical decentralized cryptocurrency culminated with Nakamoto's Bitcoin.

[Slide 19]

Bitcoin failed at every one of Nakamoto's aspirations here. The price is ridiculously volatile and has had multiple bubbles; the unregulated exchanges (with no central bank backing) front-run their customers, paint the tape to manipulate the price, and are hacked or just steal their user's funds; and transaction fees and the unreliability of transactions make micropayments completely unfeasible.

David Gerard

A parallel but less ideological thread was the idea that the business model for the emerging Internet was micropayments. This was among the features Nakamoto touted for Bitcoin in early 2009, despite the idea having been debunked by Clay Shirky in 2000 and Andrew Odlyzko in 2003. In fact, none of Nakamoto's original goals worked out in practice.

But Nakamoto was not just extremely clever in the way he assembled the various component technologies into a cryptocurrency, he also had exceptionally good timing. His paper was posted on 31st October 2008, and met three related needs:

• Just 40 days earlier, on 15th September 2008 Lehman Brothers had gone bankrupt, precipitating the Global Financial Crisis (the GFC).
• The GFC greatly increased the demand for flight capital in China.
• Mistaking pseudonymity for anonymity, vendors and customers on the dark web found Bitcoin a reassuring means of exchange.

A major reason Bitcoin was attractive to the libertarian cypherpunks was that many were devotees of the Austrian economics cult. Because there would only ever be 21 million Bitcoin, they believed that, like gold, the price would inevitably increase. Consider a currency whose price is doomed to increase. It is a mechanism for transferring wealth from later adopters, called suckers, to early adopters, called geniuses. And the cypherpunks were nothing if not early adopters of technology.

Sure enough, a few of the geniuses turned into "whales", HODL-ing the vast majority of the Bitcoin. The Gini coefficient of cryptocurrencies is an interesting research question; it is huge but probably less than Nouriel Roubini's claim of 0.86.

The whales needed to turn large amounts of cryptocurrency in their wallets into large numbers in a bank account denominated in "fiat currency". To do this they needed to use an exchange to sell cryptocurrency to a sucker for dollars, and then transfer the dollars from the exchange's bank account into their bank account.

[Slide 20]

We’ve had banking hiccups in the past, we’ve just always been able to route around it or deal with it, open up new accounts, or what have you … shift to a new corporate entity, lots of cat and mouse tricks.

Phil Potter of the Bitfinex exchange.

FOWLER opened numerous U.S.-based business bank accounts at several different banks, and in opening and using these accounts FOWLER and YOSEF falsely represented to those banks that the accounts would be primarily used for real estate investment transactions even though FOWLER and YOSEF knew that the accounts would be used, and were in fact used, by FOWLER, YOSEF and others to transmit funds on behalf of an unlicensed money transmitting business related to the operation of cryptocurrency exchanges.

US vs. Reginald Fowler and Ravid Yosef

For the exchange to have a bank account, it had to either conform to or evade the "Know Your Customer/Anti-Money Laundering" laws. The whole point of cryptocurrencies is to avoid dealing with banks and laws such as KYC/AML, so most exchanges chose to evade KYC/AML by a cat-and-mouse game of fraudulent accounts.

Once the banks caught on to the cat-and-mouse game, most exchanges could not trade cryptocurrency for fiat currency. To continue, they needed a "stablecoin", a cryptocurrency fixed against the US dollar as a substitute for actual dollars. The guys behind Bitfinex, one of the sketchier exchanges, invented Tether. They claimed their USDT was backed one-for-one by USD, promising an audit would confirm this. But before an audit appeared they fired their auditors. Earlier this year, after the New York Attorney General sued them, they claimed it was 74% backed by USD (except when they accidentally create 5 billion USDT), and revealed an 850M USD hole in Bitfinex' accounts.

[Slide 21]

"approximately 95% of this volume is fake and/or non-economic in nature, and that the real market for bitcoin is significantly smaller, more orderly, and more regulated than commonly understood."

Bitwise Asset Management's detailed comments to the SEC about BTC/USDT trading on unregulated exchanges.

According to Blockchain.info, about $417m worth of bitcoin was traded on Friday on the main dollar-based exchanges. Which sounds decent until you notice that about $37bn worth of Tether was traded on Friday, according to CoinMarketCap.

Jemima Kelly, FT Alphaville

There were many USDT exchanges, and competition was intense. Customers wanted the exchange with the highest volume for their trades, so these exchanges created huge volumes of wash trades to inflate their volume. Around 95% of all cryptocurrency trades are fake.

[Slide 22]

"An upset Mt. Gox creditor analyses the data from the bankruptcy trustee’s sale of bitcoins. He thinks he’s demonstrated incompetent dumping by the trustee — but actually shows that a “market cap” made of 18 million BTC can be crashed by selling 60,000 BTC, over months, at market prices, which suggests there is no market."

David Gerard.

Because there was so little real trading between cryptocurrencies and USD, trades of the size the whales needed would crash the price. It was thus necessary to pump the price before even part of their HODLings could be dumped on the suckers.

[Slide 23]

P&Ds have dramatic short-term impacts on the prices and volumes of most of the pumped tokens. In the first 70 seconds after the start of a P&D, the price increases by 25% on average, trading volume increases 148 times, and the average 10-second absolute return reaches 15%. A quick reversal begins 70 seconds after the start of the P&D. ... For an average P&D, investors make one Bitcoin (about $8,000) in profit, approximately one-third of a token’s daily trading volume. The trading volume during the 10 minutes before the pump is 13% of the total volume during the 10 minutes after the pump. This implies that an average trade in the first 10 minutes after a pump has a 13% chance of trading against these insiders and on average they lose more than 2% (18%*13%).

Cryptocurrency Pump-and-Dump Schemes
Tao Li, Donghwa Shin and Baolian Wang

Off-chain collusion among cryptocurrency traders allows for extremely profitable pump-and-dump schemes, especially given the thin trading in "alt-coins". But the major pumps, such as the one currently under way, come from the creation of huge volumes of USDT, in this case about one billion USDT per month.

[Slide 24]

Issuance of USDT

[In April] there were about $2 billion worth of tethers on the market. Since then, Tether has gone on a frenzied issuance spree. In the month of May, the stablecoin company pumped out $1 billion worth of tethers into the market. And this month, it is on track for another $1 billion. Currently, there are roughly $3.8 billion worth of tethers sloshing around in the bitcoin markets.

Whether this money is backed by real dollars is anyone's guess.

Amy Castor

Who would believe that pushing a billion "dollars" a month that can only be used to buy cryptocurrency into the market might cause people to buy cryptocurrency and drive the price up? If we believe Bitfinex that the 26% of USDT that isn't USD is in cryptocurrencies, that might provide a motive for a massive pump to recover, say, 850M USD in losses.

I want to end by talking about a technology with important implications for software supply chain security that looks like, but isn't a blockchain.

[Slide 25]

A green padlock (with or without an organization name) indicates that:

• You are definitely connected to the website whose address is shown in the address bar; the connection has not been intercepted.
• The connection between Firefox and the website is encrypted to prevent eavesdropping.

How do I tell if my connection to a website is secure? Mozilla

How do I know that I'm talking to the right Web site? Because there's a closed padlock icon in the URL bar, right? The padlock icon appears when the browser has verified that the connection to the URL in the URL bar supplied a certificate for the site in question carrying a signature chain ending in one of the root certificates the browser trusts.

Browsers come with a default list of root certificates from Certificate Authorities (CAs). My current Firefox browser trusts 133 root certificates from 72 unique organizations, among them foreign governments but not the US government. Some of the organizations whose root certificates my browser trusts are known to have abused this trust, allowing miscreants to impersonate sites, spy on users and sign malware so it appears to be coming from, for example, Microsoft or Apple.

[Slide 26]

A crucial technical property of the HTTPS authentication model is that any CA can sign certificates for any domain name. In other words, literally anyone can request a certificate for a Google domain at any CA anywhere in the world, even when Google itself has contracted one particular CA to sign its certificate.

Security Collapse in the HTTPS Market, Axel Arnbak et al

For example, Google discovered that "Symantec CAs have improperly issued more than 30,000 certificates". But browsers still trust Symantec CAs; their market share is so large the Web would collapse if they didn't. As things stand, clients have no way of knowing whether the root of trust for a certificate, say for the Library of Congress, is the one the Library intended, or a spoof from some CA in Turkey or China.

In 2012 Google started work on an approach based on Ronald Reagan's "trust but verify" paradigm, called Certificate Transparency (CT). The basic idea is to accompany the certificate with a hash of the certificate signed by a trusted third party, attesting that the certificate holder told the third party that the certificate with that hash was current. Thus in order to spoof a service, an attacker would have to both obtain a fraudulent certificate from a CA, and somehow persuade the third party to sign a statement that the service had told them the fraudulent certificate was current. Clearly this is:

• more secure than the current situation, which requires only compromising a CA, and:
• more effective than client-only approaches, which can detect that a certificate has changed but not whether the change was authorized.

Clients now need two lists of trusted third parties, the CAs and the sources of CT attestations. The need for these trusted third parties is where the blockchain enthusiasts would jump in and claim (falsely) that using a blockchain would eliminate the need for trust. In the real world it isn't feasible to solve the problem of untrustworthy CAs by eliminating the need for trust. CT's approach instead is to provide a mechanism by which breaches of trust, both by the CAs and by the attestors, can be rapidly and unambiguously detected.

This can be done because:

• Certificate owners obtain attestations from multiple sources, who are motivated not to conspire. Clients can verify these multiple attestations.
• The attestors publish Merkle trees of their attestations, which can be verified by their competitors.

[Slide 27]

1. Each log operates independently.
2. Each log gets its content directly from the CAs, not via replication from other logs.
3. Each log contains a subset of the total information content of the system.
4. There is no consensus mechanism operating between the logs, so it cannot be abused by, for example, a 51% attack.
5. Monitoring and auditing is asynchronous to Web content delivery, so denial of service against the monitors and auditors cannot prevent clients obtaining service.

Certificate Transparency David S. H. Rosenthal

How do I know I'm running the right software, and no-one has implanted a backdoor? Right now, there is no equivalent of CT for the signatures that purport to verify software downloads, and this is one reason for the rash of software supply chain attacks. The open source community has a long-standing effort to use CT-like techniques not merely to enhance the reliability of the signatures on downloads, but more importantly to verify that a binary download was compiled from the exact source code it claims to represent. The reason this project is taking a long time is that it is woefully under-funded, and it is a huge amount of work. It depends on ensuring that the build process for each package is reproducible, so that given the source code and the build specification, anyone can run the build and generate bit-for-bit identical results.

To give you some idea of how hard this is, the UK government has been working with Huawei since 2015 to make their router software builds reproducible so they know the binaries running in the UK's routers match the source code Huawei disclosed. Huawei expects to finish this program in 2024.

With a few million dollars in funding, in a couple of years the open source community could finish making the major Linux distributions reproducible and implement CT-like assurance that the software you were running matched the source code in the repositories, with no hidden backdoors. I would think this would be something the DoD would be interested in.

Thank you for your attention, I'm ready for questions.