Drivechains: BIP-300 Overview & Issues
BIP-300 and BIP-301 were proposed by Paul Sztorc in Aug. 2017 and Jul. 2019, respectively. Sztorc started down the path to BIP-300 as a means to build his project Truthcoin, which is meant to be the reincarnation of InTrade.com using Bitcoin. There were two threads (here and here) about this topic on bitcointalk.org in February, 2014. In May and June of 2017 there was some discussion on the bitcoin-dev mailing list, and BIP-300 was proposed in August of that year. BIP-301 was later added in July 2019 to help codify the protocol for what Sztorc calls “Blind Merged Mining”. This post is mostly about BIP-300, which enables a feature called Drivechains on the Bitcoin network. Normally, one would hope that the author of a BIP is not very central or relevant to whether or not it gets attention, but as Sztorc seems to be the major voice continuing to push for Drivechain after being essentially rejected or ignored on the forums and mailing list, it might be worth knowing this brief background & motivation. Sztorc is no intellectual slouch, and he's very open about his conviction that the success of Bitcoin is fully dependent on its adoption of Drivechain:
As far as I am concerned, Drivechain was simply ahead of its time. Eventually, one or more of the following --the problem of Altcoins, the human desire for freedom and creativity, the meta-consensus/upgrade/ossification problem, the problem of persistently low security budget, and/or the expressiveness of Bitcoin smart contracts-- will force Bitcoiners to relearn drivechain-lore and eventually adopt something drivechain-like. At which point I will write to historians to demand credit. That is my plan so far, at least. (bitcoin-dev)
So what exactly are Drivechains, and why are they so controversial?
The documents scattered around the forums, the mailing list, drivechain.info, truthcoin.info and other places are verbose. There are hundreds of pages of explanatory material, rationale, and Q&A to dig through. This blog post is an attempt to present they key points in an understandable format, and to explain the various pros and cons that have been raised on both sides of the issue.
Sidechains
A sidechain is a blockchain or other network that uses the Bitcoin network as a point of reference, but is otherwise unrelated to Bitcoin. It is a network that “follows alongside” the Bitcoin network, constantly looking to Bitcoin as at least one source of truth for its own network. In the prototypical scenario, a sidechain might watch a specific type of bitcoin address. Any bitcoin sent to those addresses could then be issued as “sidecoin” in the other network, possibly at a 1:1 ratio, or using any other method as determined by the sidechain. The sidecoin can then be used on the sidechain network for any purpose and in any way that the users of that network see fit. Importantly, from Bitcoin’s perspective, there is no sidechain or sidecoin. There is only a normal Bitcoin transaction. The fact that users of the sidechain make reference to that transaction for issuing sidecoin (or for any other purpose) is unknown and irrelevant to Bitcoin.
The difficult part is then how to spend from that reference transaction to some other Bitcoin address. If the addresses were normal Bitcoin addresses, the owner would have the keys and could spend the coins freely. In that case, no (reasonable) sidechain would be able to use the address as a point of reference, since the coins might be spent at any time. The address must somehow “lock” coins with something more than just a private key, and yet also provide an “unlock” function so that the coins may be spent in the future. Sidechain users would like some way to guarantee that locked coins stay locked while they are in use on the sidechain, and yet retain the option to unlock those coins at some point in the future without depending on a single point of failure (e.g., someone who holds the keys). It’s a difficult problem.
There are other protocols already in use with a similar concept of locking bitcoin into a specific address for use on another network. For example, a 2-of-2 multisig called a Lightning channel locks coins in for use on the Lightning Network. Getting coins out of an LN channel is straightforward: the two parties to the channel spend the funds using the 2-of-2 signatures, or in case of disagreement, either party can unlock the funds unilaterally. Essentially, LN allows users to trade a redeemable option for real bitcoin. These options take the form of real, cryptographically signed Bitcoin transactions, and might be broadcast at any time to take ownership of the funds. Sidechains use something more like an IOU for bitcoin. For sidechains, there is no such cryptographic proof possible for redeeming bitcoins locked into a “sidechain channel”. (Or at least, no cryptographic proof that Bitcoin itself is aware of.) Instead, BIP-300 attempts to enable spending from these transactions without cryptographic proof. BIP-300 requires six new types of transactions for the purposes of:
Proposing a new sidechain,
depositing to it (locking up funds, also known as a peg-in), and
withdrawing from it (unlocking the funds, also known as a peg-out).
Withdrawal is the interesting part, since that is where the difficulty lies. To peg-out from a sidechain, the user first builds an unsigned transaction spending the locked bitcoin. The user sends this transaction as a proposal to miners. If a miner agrees to support the withdrawal, they can add the hash of the transaction to the coinbase of a block they mine. In each subsequent block, other miners can choose to either support or reject the proposal by setting a 1-byte flag in their own coinbase. If at least half of the blocks in the subsequent 6-month period (13150 of 26300 blocks) have the support flag in the coinbase, then the withdrawal transaction may be broadcast. Under the BIP-300 consensus rules, the transaction spending coins from the locking transaction will be valid if and only if the 13150-of-26300-block rule is met. In other words, rather than depending on cryptographic signatures, BIP-300 assumes a game theoretic Schelling point about the actions taken by miners and other adversarial actors during a 26300-round voting system, where each block constitutes 1 vote.
To make this concrete: Alice sends 1 BTC to an address for which nobody holds the keys. Alice’s BTC is effectively gone forever—burned. Sidechain-net sees this “burn” transaction and does whatever it is that Sidechain-net does (which is irrelevant for our purposes). Later, Alice decides she does not like Sidechain-net anymore and would rather have her 1 BTC back. To do that, she must “un-burn” 1 BTC. She creates a transaction spending the 1 BTC she had originally burnt, but of course she doesn’t have the key and can’t sign it. Instead, she sends this transaction (and some additional fee) to a miner, and asks the miner to initiate a vote on her behalf. The miner places her transaction hash in the coinbase. After 3-to-6 months, that hash receives 13150 block-votes in support, allowing Alice’s transaction to go through. Alice has successfully un-burned 1 BTC and can now spend it like any other bitcoin. (Presumably, she would have already burned her corresponding coin on Sidechain-net at some point, but that is hypothetically a matter for the sidechain to sort out and not relevant for Bitcoin.)
Criticisms
Miner Incentives
There are many issues that have been raised on numerous occasions by different individuals. To his credit, Sztorc has duly responded to each of them, but I think it is clear from the various interactions that his interlocutors often remain unconvinced.
First and perhaps most fundamentally, the proposal modifies Bitcoin game theory significantly. Satoshi detailed his reasoning around design choices for the existing incentive structures, and today these are widely understood. Miners are not assumed to be honest. Even though it would be technically possible for a miner with 51% of the hash rate to cheat, the incentives work out so that it's more profitable for them to not cheat. The game theory of Bitcoin is that miners are greedy, self-interested, profit-driven capitalists. Under that assumption, even a miner with a majority of the hash rate is unlikely to cheat. Part of the reason for this is that even if they did cheat, they could only access funds for which they had keys in the past (or by colluding with such a person). Another part of the reason, of course, is that a major attack on bitcoin would cause the price to plummet—a pyrrhic victory.
The same is not necessarily true with BIP-300 drivechains. Remember: no cryptographic proof is required for the peg-out. The only requirement is a miner vote. For a large sidechain doing something people find valuable, we might reasonably expect large amounts of Bitcoin to be locked in such sidechain channels. Imagine a scenario where 1% of bitcoin (~200,000 coins) are locked in a sidechain. At current market value, that would be something like $5 billion worth of bitcoin. That $5 billion worth of bitcoin could—theoretically, at least—be spent without any proof of ownership. Sztorc provides three arguments about why the attack might not happen, or if it did, why it might not succeed.
First, he claims that the attack would not happen because miners would be collecting fees from the sidechain. However, it seems implausible that the fees collected even over a many-year period would come anywhere close to the potential billion-dollar honeypot up for grabs. The fees would need to be higher than the amount that could be withdrawn in order to keep the existing incentive structure of Bitcoin. This point was raised in 2017 on the mailing list, and Sztorc did not provide much of a rebuttal.
Second, he says that because spending the funds requires at least 3 months (and up to 6 months), with 13150 blocks agreeing to accept the spending transaction, whoever was being attacked would have plenty of time to sort things out. Would-be victims have a 3-6 month window in which to garner support for their cause. If the victim could demonstrate that a theft was taking place, Bitcoin miners and/or users could agree to something called a “user-activated soft fork” (or UASF) which blocks that transaction. In other words, the Bitcoin network should simply agree to censor the transaction. But the whole point of sidechains was that anyone who does not use a particular sidechain should be able to completely and fully ignore it. Now, far from being able to ignore it, users are being asked to weigh the merits of a he-said-she-said case for which they don't have any cryptographic proof one way or the other, or go download and validate the entire sidechain (which may not be possible for a variety of reasons), and then cast their vote based on whatever information they have available. It should be noted that BIP-300 allows for up to 256 active sidechains at any one time. Thus, there may be multiple competing actors pushing for multiple soft fork transactions simultaneously. If no Bitcoin users wanted to get involved, miners could simply vote for whoever pays the highest fees. An attacker and an honest user could end up in a bidding where the attacker has nothing to lose and the honest user is bidding away his own money.
Third, he argues that the current situation on mainchain is somehow already even more precarious. He argues that a 51% attacker could build a 13150-block reorganization in secret, while buying and selling Bitcoin (and double-spending it in their secret attack chain), and also while colluding with other Bitcoin owners to double-spend it to them for part of the profits. However, he fails to mention why any profit-motivated actor would launch an attack that caused the value of their stolen goods to drop to zero immediately. Of course, if a sidechain had only a small fraction of bitcoin and a similarly small fraction of users, a total theft might not have much of an impact on the rest of the network. The attack is technically very easy to do, so the barrier to entry for a daring miner is low. Then again, if such an attack were successful, it might destroy confidence and lead to network-wide impacts.
At the very least, the game theory is complicated and difficult to predict. What exactly is the Schelling point of a Drivechain with respect to miner theft? In fact, anyone could initiate the withdrawal process simply by making the proposal and paying the fee required by the miner. Since these attacks would be so easy to initiate, it’s safe to say we would see them. The only questions are around how all of the various actors will respond, and that requires finding the Schelling point. I would say that, as with Bitcoin, we can’t know for sure until we try. With Bitcoin, however, the game theory is much simpler—it can be summed up as “people are greedy”—and the trial already occurred during a slow phase of natural growth when the network was not worth so much. I don't doubt that Paul has thought a lot about all of these scenarios, but I did not find any definitive solutions to the game theory across his many lengthy posts.
The beauty of Bitcoin's current consensus model insofar as it pertains to validating transactions, is that every transaction comes with an attached cryptographic proof that anyone can validate. Drivechain throws this out the window and replaces it with a particular type of adversarial game that we don't really know much about. We don’t know how that game will play out, and we also don’t know what effects (if any) it might have on Bitcoin as a whole. If it were provable that it would have no effects on the rest of the network, then I think more people would be happy to let risk-takers do as they might with their own coins. The problem, of course, is that it is not only not provable, but it is very difficult to analyze concretely and predict what the outcomes might be.
Desirability & Uses
BIP-300 hinges on the idea that people want to be able to use sidechains in a very specific way. That is: users want to lock bitcoin in a channel, issue sidecoin at some fixed rate (e.g. 1:1) on some other network, and retain the option to unlock those bitcoin in the future (without a cryptographic proof). Importantly, this means that any sidechain or sidecoin using BIP-300 must work within the Bitcoin protocol; sidecoin is only ever an IOU for bitcoin. Whatever happens on Sidechain-net, however many coins are issued or whatever fancy things the protocol can do, the only way out is through the same bitcoin that were locked up in the first place. Sidechain users must want to use (or at least trust) Proof-of-Work with Nakamoto Consensus, a 21-million coin cap, a fixed inflation rate and halving periods, 10 minute blocks, etc. For sidechains that want to experiment with different inflation rates, removing caps, switching to Proof-of-Stake or any other consensus mechanism, etc., it is unclear that they could run those experiments while being stuck to Bitcoin as a sidechain.
That’s not to say there are no possible uses, or no good uses, or that any Bitcoin user should have a say in what other users may use their coins for. However, Bitcoin users have all agreed to follow the Bitcoin consensus protocol, and Drivechains are a significant modification to that protocol. Even significant modifications are not necessarily bad, but users must agree to make the changes, and it is unlikely that users will ever agree when the consequences are so unclear.
Arguably, the only real use case that necessitates a timechain that has been discovered to date is money. Bitcoin provides a solution for that one problem. Second layers like Lightning Network allow for that money to be used in different ways, but the money and the protocol stay the same. Drivechains allow for developers to experiment with other use cases for timechain tokens or other protocols entirely (within the limitations set by Bitcoin). But if the goal is experimentation, that is already being done entirely off-chain on 10,000 other crypto-nets at no (technical) risk to Bitcoin. If the goal is to add some new, desirable feature to Bitcoin, then that feature could be added by agreement among the users as has happened many times in the past.
Again, to make this concrete: suppose a user wanted to spend bitcoin on a network that had the programming capabilities of Ethereum. The user would like to peg-out from Bitcoin to Bitcoin-over-Ethereum, while retaining the option to peg back in in the future. This is already possible! WBTC (Wrapped BTC) is an ERC-20 token that has a 1:1 peg with BTC. Users can trade BTC for WBTC using any exchange, and then use WBTC in any Ethereum contract. If they want to come back to BTC, they simply trade back. WBTC is effectively Bitcoin-over-Ethereum in practice. Drivechain is not needed to enable this particular use case, since it already exists. The only difference, of course, is that WBTC relies on a secondary trading market to swap BTC for WBTC. However, because Drivechain requires at least 3 months to complete a successful peg-in, the proposal actually assumes that there will be secondary markets for trading sidecoins with bitcoin. The assumption is that the rate would always be near 1:1, with a small premium for the party who is willing to wait 3 months for a withdrawal back into bitcoin.
Sztorc’s claim is that unless Bitcoin adopts Drivechain or something like it, human creativity will ultimately cause people to move away from Bitcoin to newer, better solutions that provide more bells and whistles. In other word: Sztorc believes that The Flippening is nigh, and although it might not be Ethereum, some as-yet unknown project will surely topple Bitcoin unless it can exist as a Bitcoin sidechain, in which case it will become dependent on Bitcoin rather than an adversary. He also claims that unless Bitcoin adopts Drivechain, halvings will eventually remove so much of the block reward that, if we assume fees will not go up significantly, miners will be unable to continue mining Bitcoin. A large part of the Drivechain proposal (BIP-301) is around how miners can collect fees from sidechains, thus increasing the total amount of fee revenue on the table for miners and improving Bitcoin’s attractiveness in the long run. This is a laudable goal, but as I explained above, the incentive structures are not clear enough, at least for me, to agree that this is what would happen, or even that it would be the most likely outcome.
Conclusion & Proposal
There’s no risk-free lunch. You can’t have your bitcoin and your sidecoin risk-free. The risk has to go somewhere. In the case of Drivechain, it is shared out among all users of the Bitcoin network. There are many unknowns (including many unknown-unknowns) in the Drivechain proposal, and these will not likely have any kind of broadly accepted answer unless they are simply tried out on mainnet. There are many other BIPs that add all kinds of features to the Bitcoin protocol, but most of these are not fundamentally different. Drivechains fundamentally change the transaction validation mechanism from “all spends must provide cryptographic proofs” to “some spends do not require cryptographic proofs”. It fundamentally changes the ability to attack the network from “the attacker must acquire 51% of the hash rate” to “the attacker must propose a transaction and fight out ownership in meatspace”. It fundamentally changes attack response from “move hash away from the bad actor” (e.g., out of a pool, or by adding more honest hash) to “convince all the miners or nodes to do a UASF in favor of one party over another”.
There are an enormous number of ways to play these games, which is precisely why the game theory is so complex. For what it’s worth, I will stick with the game theory that I understand, and that was proposed by Satoshi: people are greedy. I understand that, and I understand how it impacts the Bitcoin incentive structures so that the whole network is maximally anti-fragile.
My proposal is that if Sztorc and others believe Drivechain is a superior and absolutely necessary system, they should get together behind a hard fork. They can hard fork Bitcoin to activate BIP-300 and BIP-301. If they are correct, Drivecoin will outperform Bitcoin, and users will naturally migrate. In fact, if all goes to plan, Drivecoin will attract all of the users and fees from Ethereum ZCash, Namecoin, and every other crypto project that does anything “worthwhile”, quickly surpassing Bitcoin in utility and market value. If it’s a hard fork, Bitcoin hodlers who keep their Drivecoins will be exposed to all of the upside and none of the downside: it’s a win, win, win! This is the easiest way to see if Drivechain works, and has the least risk for Bitcoin users. Importantly, it also has the least risk for Drivechain proponents! From their perspective, if Bitcoin will die without Drivechain, and if Drivechain is unlikely to be adopted in Bitcoin Core, a hard fork might be the only way to save Bitcoin. I don’t know if Sztorc or others have already considered hard forking Bitcoin to create Drivecoin right away, but I strongly urge them to consider it. That way, we will all get exactly what we want.