Peer Review (and Drivechain Controversies)

Visit the old peer review page.

What are the major remaining critiques of Drivechain?

Most critiques have been asked-and-answered. And the overwhelming majority of people are excited about the potential. But two major critiques persist.

They boil down to the following:

  1. “miners can steal sidechain funds”
  2. “merged minded sidechains increase pool overhead, making txn-censorship easier”

It is somewhat distressing that these critiques remain, because both of them are completely false. Each is a complex blend of false premises, self-contradiction, ignoratio elenchi, and even outright deception. For each, there is so much to say, about how wrong they are, that –when I am speaking in person– I often trip myself up by trying to articulate all of them at once.

1. Does drivechain allow miners to steal funds?

Short Answer: This seemingly innocuous question is very misleading – it is a bit like asking “Does the free market allow entrepreneurs to go bankrupt?”. If an entrepreneur is servicing their customers poorly, then they should, and will, go bankrupt.

Similarly, the drivechain security model assumes that the sidechain is “popular” – useful to both users and miners. If so, it is safe. If not, then it is not.

Longer Answer (in 5 parts):

1.1 The Validation Trilemma

First, it is admittedly true that all SPV-proofs (drivechain or otherwise) must allow miners to forge a withdrawal of funds, because SPV-proofs are only gated by proof-of-work. This design choice is intentional, as it is precisely what allows the sidechain to be optional. If we wanted to prevent miner-theft, then we could do so easily by requiring mainchain full nodes to validate all sidechain blocks, and all sidechain rules (this would be the so-called “evil fork”). But this would be a de facto unlimited blocksize increase and therefore an unlimited loss of decentralization.

Therefore, we must choose one of these three options: [1] mandatory sidechains (evil forks); or [2] Altcoins (whose mere existence violates the 21 million coin limit); or else [3] sidechains whose withdrawals rely only on SPV-proofs. So, people who criticize drivechain for its use of SPV-security, probably do not realize that they are necessarily instead supporting either [1] unlimited loss of full node decentralization (mandatory sidechains); or else [2] unlimited inflation-tax on Bitcoiners (Altcoins).

1.2 Four Withdrawals Per Year

Second, while all SPV-proofs are vulnerable to miner-tampering, Drivechain’s has extra features (which are mainchain full node enforced) designed specifically to thwart tampering. All of a sidechain’s activities over a 3 month period are compressed into a mere 32 bytes. On the mainchain, these bytes are announced and then forced to march very slowly –one step per block– across a finish line that is 13,150 steps away. Even with 100% hashrate participation, this takes 3 months. While new contestants can begin the race at any time, only one racer can step forward at a time. Whichever 32-bytes crosses the finish line, is considered to be canonically “what happened” on the sidechain. Meanwhile, the sidechain nodes (both full and SPV) will be broadcasting these 32 bytes as loudly as possible to anyone who will listen. So, even if there is constant, maximum-scale professional tampering, it will all be very easy for the user to observe and demonstrate to others.

Investors and users will have plenty of time to react to tampering. One reaction would be to UASF to block any tampered 32-bytes from crossing the final finish line. This is much easier than the SegWit UASF, because it requires no software development, and no real-life coordination on actions and timing. If the UASF fails, and if the sidechain was objectively valuable, BTC’s total transaction fees and exchange rate should fall, punishing the very miners who instigated the tampering.

More reading.

1.3 Delousing the Mainchain

Third, some sidechains are “bad”, and it is actually a good thing if miners have an incentive to “evict” them. It is rather analogous to a city with a large criminal homeless population: some sidechains can be designed purposefully, to “leech” off of other sidechains, or even to attack the mainchain directly. How can we make sure that all of the best sidechains are let in, and all of the worst ones are kept out? By giving the decision to whoever has the most skin-in-the-game. Miner’s profits are highest when they maximize exchange rate and total transaction fees, so it is reasonable to give the add/remove-sidechain decision to them.

In other words, if a particular sidechain is holding Bitcoin’s exchange rate down, we would HOPE that miners steal from it, and quickly! In the same way that we would hope oncologists would assassinate our cancer cells; or that poorly-run businesses will fall apart and free up capital for better entrepreneurs.

Further reading. And watching.

1.4 Miner-Theft Has Nothing to do With Drivechain

Fourth, the very idea of “can” (in the phrase “miners can steal”) is a complete misrepresentation of how Bitcoin works. In a naive sense, miners can always steal BTC, whether it is on drivechains on the mainchain or even in LN-channels. This is because miners control the contents of The Blockchain absolutely. But the true question has always been: “will” miners steal. And, in answering it, we have always relied on theories about miners’ choices, motivations, and behavior. We then apply these theories to a given design – in vanilla Bitcoin, we observe that miners must make choices and pay their costs in advance, are next held hostage for a while, and are then ultimately paid out by the protocol in BTC.

The purport of this “can”-language, I think, is to imply –falsely– that the Drivechain design puts user’s BTC into immediate risk of being easily claimed by miners in the very next block. And, therefore, that I am being naive in assuming that miners will not do this! But the truth is that I built features into Drivechain (especially the slow, transparent, high-effort withdrawal process), that I assume will convince profit-maximizing miners that harvesting the sidechains (for their txn-fees and value-boosting properties) is more lucrative than devouring them.

1.5 DC Is An Opt-In Layer-2

Fifth, and most important, the argument only applies to BTC that users have deposited to a sidechain! Non-sidechain funds are completely unaffected by sidechains, of course.

Consumer sovereignty is a basic principle of Bitcoin. Users are allowed to handle their funds however they like – to use unproven wallets, invest in dubious projects, and even to sell -or just straight-up destroy- their BTC. In particular, they can send BTC into LN-channels, despite the weaker security model. This is because the LN has benefits that (as the user sees it) make up for its risks. It is exactly the same with Drivechain.

Those who say otherwise have simply betrayed the liberty movement and the free software movement.

2. Does Drivechain increase the risk of txn-censorship by giving economic advantages to large pools, making them inevitable; while simultaneously making large pools less anonymous and more susceptible to coercion?

Short Answer: No.

Longer Answer:

Overview of Complaint

This complaint is a story in three parts.

First, the complaint asks us to consider “burdensome sidechains” which are expensive to run, but profitable.

So imagine that all “sidechain” software costs $5 M / year to run, but “sidiechains” bring in $100 M / year (in txn fee revenue). A solo miner with only 4% of the hashrate would earn $4M from “sidechains” (just 4% of the total $100M). But “sidechains” would cost this miner a fixed $5M. So this miner does not run any sidechains. But conversely, a solo miner with 12% would run sidechains – they’d pay $5M (fixed) and earn $12. This miner now earns a higher ROI (the $12/$5 ROI blends in with the subsistence ROI he was earning pre-sidechains). Because of sidechains, larger miners are rewarded more.

The same problem applies to pools. The pool operators who mine “sidechains”, will have an edge over those who do not. Pools which turn down the free money, will not attract Hashers. Therefore, eventually, “running all profitable sidechains” will become an activity that is de facto mandatory.

So far, nothing bad or even unusual has happened – mining has always entailed high-effort “de facto mandatory” activities (optimizing chip designs, locating cheap sources of electrical power, etc).

But the third and final part of the complaint, alleges that sidechain software (hypothetically) also makes the pool operators less anonymous and easier to coerce. Regulators will be able to force pool operators to censor transactions – specifically, now that the pools have been forced into a vulnerable state, they will be coerced into censoring mainchain transactions that were previously (before the arrival of sidechains) un-censorable.

This plausible-sounding story is false from beginning to end.

Blind Merged Mining

First, Drivechain contains something called blind merged mining, designed to address this “problem”. It allows pool operators (or solo miners) to collect all of the chain’s txn-fees, without needing to run a node. It does this by outsourcing the block-assembly work to sidechain full nodes (ie, users), who are doing it anyway. Mainchain miners just watch the mainchain for “bids”, and include only the highest bid. The sidechain network activity, no matter how burdensome, is compressed into a small, fixed number of mempool messages.

While it addresses the critique completely, I now regret developing it. It took up a lot of time, and it lent undeserved credibility to this “problem”.

In truth the problem is nonsense. Let me explain why with five reasons.

A Nonsense Problem


First, the ‘second act’ of the story above (“…runnning all sidechains is de facto mandatory”), conflates “an inducement” with “total slavery”. The DC-skeptics are arguing: if miners earn $0.10 of profit by selling t-shirts (or whatever), then eventually t-shirts will become a mandatory part of the protocol, and that whoever can control t-shirts can control Bitcoin mining.

That premise is as silly as it sounds. The claim that ‘wasteful competitors will go bankrupt in the long run’ is quite different, from the claim that ‘every $0.10 of profit is mandatory’. Intelligent humans can decline to take $0.10, if they have any real or imagined concerns about running the sidechain.

But if the premise were true, the argument gets worse! It ends up contradicting itself. The end of the story called upon us to believe that pools would bow to coercive forces, and censor transactions from blocks. But, crucially: pools lose profits when they censor. Each time they decline a valid fee-paying txn, they pay the opportunity cost of those lost fees (and save nothing on “costs”). So it comes directly out of profit.

But earlier we assumed that ‘every $0.10 of profit is mandatory’. Which means that censorship is absolutely prohibited. So, either the pools are “required” to earn every cent, in which case they can never censor a single txn, or else they aren’t (in which case they are not “required” to run every sidechain).

And it gets worse. The first txns to be censored would certainly be the sidechain’s high-overhead, low-fee-magnitude txns. So, even if the story of the complaint somehow comes true (inconsistent though it is), the Bitcoin system would just regress toward the state it is in now: one with all of the sidechain-txns censored. If pool-coercing censorship is still possible after that point, then sidechains are not to blame for it, by definition.


Second, as with the “miners can steal” language, this critique is grounded in poor Bitcoin Philosophy. Critics intentionally conflate “node centralization” and “miner centralization”, in the hopes that, by reusing a word, the audience can be tricked into thinking that the two concepts are similar to each other. In reality they have nothing to do with each other.

Node centralization (the real one) makes life harder for the user, and is self-evidently bad. But with mining it is a different story. While “mining”, the process, is the core element of Bitcoin’s design, the mere act of “finding a block” is utterly neutral – when a new block attaches to the longest chain, it was “good”; but if a new-found block attaches to an attacking reorg chain, then it was “bad”. So if we make “mining” easier, we also make “attacking Bitcoin” easier.

This is implicity recognized in Bitcoin culture – when the difficultly adjusts upwards, there is cheering and applause. As there was with the SegWit UASF. People cheer when mining becomes harder.

Miners are not Bitcoin-customers, they are Bitcoin-suppliers. After all the Pareto improvements have been found, what is good for customers will be bad for suppliers. For example: “forced teamwork in the name of efficiency” (aka “mining centralization”) is inconvenient for miners…but good for users.


Third, txn-censorship is a privacy-failure; it has nothing to do with pools or sidechains or merged mining. If Bitcoin had strong privacy, users would be protected from censorship. Adversaries could only respond by ‘censoring everything’; but if they can manage that, then we are doomed in any case.


Fourth, while critics bill out merged mining as “threat” to Bitcoin, the reverse is probably the case: going without merged-mining is the bigger threat to Bitcoin. For MM is likely to be the only decentralization-preserving way to boost on-chain fee-revenues; and these need to be boosted.


Fifth, and again most importantly, merged mining (the vanilla, non-blind version) is unblockable. There is nothing the user can do to prevent miners from doing it. And miners earn more money by doing it. So, even if we make every possible concession to Critique 2, that it is bad and that everything in it will happen, then we would just end up in a world where experimental software takes the form of Altcoins – these would be vanilla merged mined (as Namecoin is today) and ultimately we would reach the same “high overhead pool” result.

Other Critiques

Critiques 1 and 2 are the big ones.

Other critiques are possible, of course. But, in general, they are just statements about risk, the same way we might warn people about the big unsolved problem with LN-channels. Advice is always helpful, but the final decision always rests with each individual.

In other words, it is possible to dis-prefer Drivechain, but still agree that some users may find it useful.

Watch: “Drivechain: Overview and Misconceptions”


I have presented these arguments several times, in various media (writing, youtube, meme, conference presentation). But, I admit, some remain unconvinced.

In the interest of honesty and full disclosure, here are some technical experts who still endorse Critique #1:

And here are those who endorse Critique #2:

  • Peter Todd (Feb 2019)
  • Andrew Poelstra / Gregory Maxwell (Dec 2018)
  • Matt Corallo (Oct 2016)

Wall of Fame

Notable people who never fell for either mistake, or who came around:

  • Person 1 (May 2017)
  • Person 2 (June 2017)
  • Person 3 (June 2018)
  • Person 4 (Feb 2019)

( Names blanked out temporarily, and mixed in below. )


People whose opinion on Drivechain we don’t know (please tell us!), plus the four people above:

  • Adam Back
  • Bryan Bishop
  • Luke Dashjr
  • ฿tcDrak
  • Andrew Chow
  • Christian Decker
  • Nicolas Dorier
  • Thaddeus Dryja
  • Johnson Lau
  • Eric Lombrozo
  • Jameson Lopp
  • Cory Fields
  • Mark Freidenbach
  • Alex Morcos
  • John Newbery
  • Laolu “roasbeef” Osuntokun
  • Joseph Poon
  • Jeremy Rubin
  • Rusty Russell
  • Gregory Sanders
  • Jonas Schnelli
  • Patrick Strateman
  • Amir Taaki
  • Warren Togami
  • Wladimir van der Laan
  • Pieter Wuille

See Also