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.
_________________________________________________________________
Here is part two of the experiment. Last week I published a short prompt challenging readers to respond with their own defense or criticism of drivechains. The purpose of this was to instigate challenges to my own criticisms, questions, or even new criticisms I have not thought of or considered. Written form content is generally more thorough and easier to digest than real-time communication, as both parties have time to sit and think before formulating a response as opposed to needing to do so immediately. I think this can help to change the tone of conversations around contentious topics by trying to facilitate them in this format.
So that said, time to go through the responses to last week’s prompt.
Paul Sztorc
Paul Sztorc responded in long form on Twitter, the entirety of which can be found here. For formatting clarity in quote snippets, bold text is denoting which of my statements Paul is responding to.
> 1) Drivechains introduce a hodgepodge of new variables into miners’ incentives … Drivechain is comparable to RIOT’s use of “power curtailment credits”. https://riotplatforms.com/bitcoin-mining It is just a new way for miners to make money. When I’m asked: “does drivechain affect miner incentives?” I say “no”. I personally lived through the invention of: FPGAs/ASICs, heat-reuse, stranded natgas flaring, curtailment credits, and a whole lot else. Merged mining was invented by Satoshi in 2010, and is already in continuous use — https://truthcoin.info/blog/security-budget-ii-mm/#c-its-too-late–mm-is-already-widespread . Same with the withdrawals — miners do plenty of nice things, such as MASF activate soft forks or hold peoples mistaken fee money ( https://x.com/satofishi/status/1701042302238724512?s=20 ), or hire Bitcoiners to shill Bitcoin. So, to someone like me, getting revenues from merged mining, or overseeing 4 fully-automated withdrawals per sidechain per year, doesn’t even register as a change. It’s just business as usual.
Paul claims that power curtailment agreements are equivalent to the centralizing pressures of drivechains. This is a broken comparison for a few reasons, first of which is the wild difference in terms of scale. Something like operating infrastructure for drivechains, or the proportional advantage of pool size in doing so, runs on economies of scale. The larger an operation engaging in such a behavior is the more of a global advantage it gives them. Power curtailment on the other hand doesn’t, it has diseconomies of scale. One mining operation engaging in power curtailment on Texas’s grid has no impact at all on miners connected to another grid being able to engage in similar agreements. Combine this with mining actively being used to expand renewable energy production, which creates the need for these curtailment agreements, and the entire dynamic over time is guaranteed to decentralize and become more and more open to other miners. Also, the claim that miners being put in absolute control of custodying other people’s funds and decide which withdrawals to process (somehow without knowing the current balances of legitimate users) is no change in their role is just patently false.
> 2) Existing Sidechains Have No Adoption Wait!? I thought sidechains were going to change miner incentives?? Not if they have “no adoption”. 😉 Anyway… RSK/Liquid are federated, and the federated model is terrible. “federation vs PoW”, is literally the only difference between Bitcoin (a success) and its failed predecessors. We can similarly expect BIP300 to outcompete Federated. Furthermore, they aren’t even in the same league. Liquid does not provide us a website (for example) where we can paste in (for example) the zCash Altcoin source code, and get out of that a zCash federated sidechain. Instead we are stuck with just one piece of closed source junk that we cannot modify. That misses the entire point of sidechains. Comparing RSK/Liquid to Bip300 is comparing two handwritten books to the printing press. Liquid was completely closed source until very recently; no one knows who the federation members are (despite the model relying solely on their reputation); all of the Liquid txn fees go only to the corporation that created it. For a while (and still to this day, in my opinion), Blockstream engineers could abscond with the funds if they actually put five man-hours into it (see https://x.com/_prestwich/status/1277089486111817728?s=20 ). RSK aspires to be a drivechain — so I have their vote, at least. They agree with me that they should be a drivechain, not federated. Finally, the fact that we have failed to build things that the end-user enjoys? That should only spur us onward, to invent new things. Not give up faster.
I don’t know what to say here…essentially every claim here is false. Liquid/Elements the platform has always been entirely open source and possible to modify, only the code the federation members run to sign blocks and withdrawals was closed, but that is now open source. Paul pretending and trying to imply the entire project was closed source is not true. As well, the claim that “five man hours” could steal all of the funds is entirely false. The incident that he is referring to was a bug (that has been patched) in the federation member code. All Liquid coins have a timelocked recovery path using a 2-of-3 keyset in the event of catastrophic key loss by federation members that would result in all funds being lost. In order for these keys to be used, the Federation must fail and cease moving these UTXOs. That is not “five man hours” of work as Paul claims, it is attacking a globally distributed set of HSMs that are incredibly robust to remote attacks and almost certainly require physical access to compromise.
> 3) Drivechains Exacerbate The Risks Of MEV > MEV is something that is possible on Bitcoin already … but … Drivechains open the door to arbitrarily complex forms of MEV on sidechains, MEV = “miner side hustle”. In other words, if I offer Foundry $20 to shine my shoes, then that is MEV. If Slush Pool sells t-shirts on the side, then that is MEV ( spoiler alert they already do: https://shop.braiins.com/products/braiins-polo-shirt ). Miner’s main hustle is ordering transactions and blocks — anything else they do, is a side hustle. Obviously we don’t want the two hustles to conflict! I addressed such “cross chain MEV” long ago, in 2016, long before anyone had ever heard of shinobi (or MEV) ( https://youtube.com/watch?v=2OOKgTSrITs&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=2 ). I designed Drivechain to have something called “categorical control”, to *defeat* cross chain MEV …unlike for example Blockstream’s simplicity which I believe could exacerbate it (see Part 5 / code obfuscation ; or see http://truthcoin.info/blog/contracts-oracles-sidechains/ http://truthcoin.info/blog/drivechain-op-code/ http://truthcoin.info/blog/wise-contracts/ for more). Truthfully though: MEV is a distraction. Could a smart contract pay miners to reorg, or censor txns?? Yes. But a human, could also bribe a miner to do those things. Ultimately it comes down to: $ from txn fees, vs $ the attacker pays. Best way to help miners is to make sure they are rich — collecting lots of $ from the “main hustle”. Ie lots of merged mining.
I don’t know what else to say except that Paul continues to make absurd and extreme arguments here. Selling t-shirts requires new equipment, new services, new investments, whereas reusing your mining hardware doesn’t. A miner picking up a penny on the ground does not have any relevant impact to miner income or incentives, whereas someone offering miners $10,000 a week to reuse their hashrate for a new purpose does. Comparing the two is absurd.
These are in reference to my reply https://twitter.com/Truthcoin/status/1699093434026406322 to his previous article. I stand by everything in that reply! > …these just shove the liquidity requirements onto yet another party, assuming they will provide massive amounts of liquidity for almost nothing in return Both halves of this are wrong. First, on the L1 side of the trade, nothing is locked up — EVERY coin on L1, is already “providing liquidity” (in this context). Second, they certainly don’t get nothing! They charge a fee. The model would be: “buying 1 sidechain coin, for 0.99 L1 coins” (for example). > don’t think it’s a foregone conclusion that enough liquidity to cover the “solution to the security budget problem”
I think Paul here is oversimplifying what is going on, and ignoring the dynamics of arbitrage, which is what is happening here. Yes, in an ideal scenario, all mainchain coins are available to swap for sidechains, but in reality that is not the case. That assumes everyone thinks drivechains are equivalently secure to the mainchain. In reality, there is a security and risk difference, and people engaging in this arbitrage are bearing that risk on behalf of people they swap with. Most Bitcoiners are not taking their bitcoin and arbitrage trading for yield with it, they just hold it. That won’t magically change because of drivechains, and ultimately the people doing this arbitrage need to get the coins they have swapped into drivechains back out to the mainchain to close the arbitrage loop. This simply shifts that bottleneck directly from sidechain block constructors to arbitrage traders. Also at the end of the day, this adds another cut someone else is taking from the fee sharing, and is a margin that miners can capture by running a sidechain node themselves.
idBrain
Anon idBrain on X (Twitter) posted the question what would I do if drivechains were activated. Well, in most situations nothing. A URSF (User Resisted Soft Fork) trying to go up against the entire ecosystem would be mostly futile, i.e. if most users, businesses, and miners all supported activating the proposal. If only miners activated it, with no users or businesses worth mentioning enforcing it, it might be worth it to continuously propose withdrawal transactions, looting the sidechain and paying it all out to miners. If 51%+ of miners defected from enforcing the rules all drivechains could be looted with no time delay in a single block. If it did successfully activate with wide support though, I would probably cease looking at Bitcoin as something that could realistically stand up to state and alter the dynamics of money and state. It would be simply a fiat denominated investment to me at that point on the road to state capture.
Mister Ticot
Mister Ticot sent in an email a question:
You mentioned sidechains arn’t being used and are only federated. What about Stacks? Doesn’t it qualify as a permissionless side-chain with some level of success?
I would not qualify or describe Stacks as a sidechain at all. I would call it a para-chain, or a parasite chain. Stacks is an independent network with a native base token different from Bitcoin, and as such I do not qualify it as a sidechain. It interacts with Bitcoin in a similar way, and by that virtue can influence Bitcoin miner incentives, but it is not built on a foundation of BTC as the core native asset, which I think is the main requirement for a secondary blockchain to be considered a sidechain.
Micah Warren
Micah Warren wrote in an email: Responding to your call to stir up technical conversation.
Responding to your call to stir up technical conversation.
My understanding is that the huge unavoidable havoc-wreaking problem with blind merged mining is that it’s trivial to obtain as many blocks as you’d like simply by outbidding other ‘miners’. It quickly degenerates into a bluffing/signaling game. It also create situations where you can create massive MEV opportunities by committing to longer reorgs, in addition to short term plays like fee-sniping. In proof of work, if someone tries to perform a longer reorg, the honest miners (provided there’s 51%,) can just default to the same thing they always do. However in BMM, once you commit to winning the auction to carry out your shenanigan, there is no default mode that honest miners can retreat too. All bad stuff. In my opinion, this makes BMM not really a serious consensus mechanism.
HOWEVER, it probably can be fixed- you just have to slightly think outside of the PoW box.
Here’s the thing, because the map from SC blocks to L1 blocks is injective, we obtain a linear, sequential, total ordering of all candidate sidechain blocks. So really, we’re 99% of the way there as far as consensus goes – we’ve narrowed it down from trillions of possible blocks to a small discrete handful of candidate blocks and these blocks come with a clear total ordering. The only thing wrong with taking the first block at height N to be the canonical one is that such a block at height N might not be valid. So all you need is a simple mechanism to determine, within a short period of time, whether the block at height N is correct or whether it should be discarded. Clearly invalid blocks will eventually be discarded, the only question is how to enforce a time limit so that someone can’t maliciously withhold a block for a long time in order to jam up consensus.
This doesn’t seem like a hard problem. One solution: You could simply declare a jury of community-trusted sidechain nodes, say 5 of 9, who would wait 20 seconds after the block is mined, and if they can validate the underlying block, they say it’s good, it’s now in the canon. If they can’t see the block or can’t validate it, they declare it invalid.
Now the 20 seconds is arbitrary, the jurors are just calling balls and strikes, there doesn’t need to be a correct answer – the only thing is that 21 seconds after the last L1 block has been mined, sidechain miners now know for sure whether to mine a new block or on top of the old one.
Problem solved. The only drawback (laser-eyed maxis might want to ear muff for this), you have to rely on something other than proof of work to resolve rare consensus disputes. Of course, such disputes would almost never happen, because the only reason they would happen is if an adversary was trying to create a schism point, and by breaking the tie instantly, you are obviating the schism point.
Of course what happens on a sidechain is the sidechain’s business – but if I could argue that the best design of a sidechain would always involve some reorg protection, then all the concerns about chaotic reorging forcing the L1 miners to enter the game are no longer valid.
In response to this observation, I would say a different potential solution that is superior would be a Zero Knowledge Proof of correctness for commitments to new sidechain blocks. However, I think solving this issue undermines one of the core goals of drivechains architecture: to not introduce new reasons or incentives for miners to reorg the mainchain to accomplish a reorg on a sidechain. Micah’s proposal for federating validity attesting to sidechain blocks would create the same incentive, but additionally ultimately backstop the entire trust model of the sidechain with a federation. I.e. nothing would be considered valid without the attestation of those chosen arbitrators. This defeats the purpose of drivechains design, which is to have miners fill the role as the ultimate backstop in the trust model.
Alright, so that is it for this week’s Strawman. Next week I will try to be more triggering.