Bitcоin

Drivechains Are Stupid, Prove Me Wrong

Shinobi’s Strawman is a weekly series where our Technical Editor Shinobi challenges the Bitcoin community, aiming to stir up conversation around heated technical debates.

______________________________________________________________

We are going to try something of an experiment today.

Drivechains are being proclaimed by some as the savior of Bitcoin, the answer to all of its problems. It solves the long term security budget, allows complete freedom to incorporate new features into Bitcoin, and presents no downsides for existing Bitcoin users.

Sounds too good to be true? It is:

1) Drivechains Change Miner Incentives

Drivechains introduce a hodgepodge of new variables into miners’ incentives, and after introducing that instability advocates push for users simply adopting a degraded security model for all new use cases and functionality by using a sidechain in lieu of changing the base layer. How is this any different than an outright attack on Bitcoin self custody?

2) Existing Sidechains Have No Adoption

There have been many different design proposals for sidechains over the years, but the only currently deployed ones are run by federations (Liquid and RSK), both of which have failed to gain any meaningful level of adoption since they were deployed. Does this mean sidechains are not worth continued development effort? Or are they worth it, and the failure of federated chains to be adopted is simply the result of shortcomings in that specific sidechain design?

3) Drivechains Exacerbate The Risks Of MEV

MEV is something that is possible on Bitcoin already, as systems like Stacks are demonstrating, but currently the forms of MEV possible on Bitcoin are either generated by totally independent altcoins like Stacks (which historically have trended to an insignificant percentage of miners’ income, like Namecoin), or very low in the level of complexity (like frontrunning Inscriptions). Drivechains open the door to arbitrarily complex forms of MEV on sidechains, while also ensuring that the token generating that MEV is pegged to the price of Bitcoin. I.e. it cannot simply fade away to an irrelevant fraction of miner income as people stop buying an altcoin. This drastically worsens the risks and potential damage of MEV on Bitcoin.

4) No, Swap Markets Aren’t An Answer

Paul Sztorc replied to some of these concerns on Twitter, but these responses do not really address the root issues. Swap markets might sound like an answer, but the reality is that these just shove the liquidity requirements onto yet another party, assuming they will provide massive amounts of liquidity for almost nothing in return. That might work for small scale utility users, or having liquidity available to arbitrage uncertainty around the peg, I don’t think it’s a foregone conclusion that enough liquidity to cover the “solution to the security budget problem” without slippage is a given, to say nothing of all the other users who would want to swap in and out. He then goes on to ignore the difference between a mainchain reorg, which requires redoing work and energy expenditure, versus a sidechain reorg which does not. Finally, he equates a random person for no logical or profit driven reason giving money away with someone generating a profit with an activity they are the sole gatekeepers of.

Look, ultimately, I’m a Bitcoin maximalist. I want what’s best for Bitcoin.

I think drivechains are stupid, dangerous and a waste of time, but I want to hear your thoughts on the subject. Am I wrong about the points above? Is there another reason that I should be against drivechains that I’ve overlooked?

Please do not write to me with some random hopium. I’m open to novel opinions. I want the conversation to progress. Above is my best summation – we simply aren’t anywhere close to a meaningful consensus on drivechains.

My DMs are open. Opinion@bitcoinmagazine.com. Let’s hash it out.

Source

Click to rate this post!
[Total: 0 Average: 0]
Show More

Leave a Reply

Your email address will not be published. Required fields are marked *