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 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. 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 totally 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.

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.

The “miners can steal” feature is not a design flaw, nor is it even a trade-off (as if we had to “settle” for miners-can-steal SPV proofs because they are the best we can do with present technology). Instead, miners-can-steal is the only known way of achieving “sidechain privatization”, which is necessary for many important sidechain designs. Thus, perhaps counterintuitively, removing the miners-can-steal feature will cause many sidechains to become insecure.

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 / Sidechain Privatization

Third, some sidechains are “bad”, and it is necessary to sidechain security that miners have an incentive to “evict” them.

Passively, sidechains do not affect each other in the slightest (which is, of course, the whole point). But what if a sidechain is specifically designed to interfere with some other sidechain (or the mainchain). In 2016, I researched several such problematic sidechain designs (research below). So, we now have a problem: how do we get ride of bad sidechains? Some force has to sweep through the protocol somehow, such that if a sidechain is too problematic it is eventually kicked out of the Bitcoin cryptosystem.

Luckily, an easy solution is at hand: Miner’s profits happen to be the highest, when they maximize the BTC exchange rate and the total transaction fees (across all sidechains). They are also the natural “laborers” of the system, and 51% hashrate coalition already has the ability to filter out any unwanted messages from any blockchain (mainchain or sidechain). So it is natural to give the add/remove-sidechain decision to them.

In other words, if a particular sidechain is holding Bitcoin’s exchange rate down, or supressing txns on a rival sidechain, then we would HOPE (perhaps counterintuitively) 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. Best of all, the looming threat of sidechain failure acts as a deterrant – sidechain developers will want to work hard to present a quality, law-abiding product.

Further reading. And watching. None of the people advancing the “miners-can-steal” talking point are familiar with this research. They do not know that, for example, a ZK-SNARK peg-out system (which they would presumably prefer, as miners can NOT affect withdrawal-transactions in any special way) would (among other problems) render all P2P oracle sidechains permanently insecure. And it would do so for no reason, since miners could steal from such sidechains anyway (next section).

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. So the true question has always been: “will” miners steal. (See my Lisbon BoB talk for more.)

The purport of this “can”-language, is to imply that the Drivechain design is cavalier and unconcerned – as if I would allow BTC to be snatched up by miners in the very next block! And that, therefore, I am naive (since I “assume” that miners will just not take these “up for grabs” coins).

Hopefully by now it is obvious that that is misguided. Drivechain assumes that miners profit-maximize, and take as many coins for themselves as they possibly can. The withdrawal-process is slow, transparent, and high-effort, and is very tamper-resistant. Miners have an alternative to stealing from sidechains: harvesting them, for their txn-fees and value-boosting properties. For some (but not all) sidechains, harvesting will always be more profitable than devouring.

1.5 DC Is An Opt-In Layer-2

Fifth, and most important, the “miners-can-steal” 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 core principle of Bitcoin. We all agree: users are allowed to handle their money however they like – they can use unproven wallets, invest in dubious projects, and even to sell their BTC (or straight-up destroy their BTC). In particular, we would all agree that 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. We would also all agree that users have the right to sell their BTC and buy an Altcoin. It is exactly the same with Drivechain.

Those who say otherwise, have simply betrayed the liberty movement and the free software movement. No one in Bitcoin should listen to what they have to say, about anything.

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