I have written quite a bit about my concerns regarding drivechains and miner incentives over the years, because I think it is a very important set of risks to be aware of. Bitcoin is almost 15 years old as a live network at this point, and it has stood up to a good bit of pressure and outright malicious griefing and attacks over those 15 years. Bitcoin has withstood internal attacks from developers trying to radically alter the system, it has withstood the same attack from most of the major businesses in the space, it has survived what could have been fatal and catastrophic bugs, super powers banning it, wild price volatility, etc. It has stood up to everything to date that has been thrown at it. Why?

Because of the resilience of its incentive structure.

Developer coups failed because of invested users incentivized to figure out the rational long term direction to go. Business coups failed because those same users and their customers to those businesses is what made them money. Nation states coming down and banning Bitcoin had no effect, because invested enough users had every reason in the world to leave and flee to friendlier jurisdictions. If it weren’t for the incentives of individual users, and how their individual incentives interacted with each other as a complex system, Bitcoin would not have survived any of those issues.

Anything that presents a serious possibility of severely altering the balance of those incentives is something that should be approached with extreme caution and skepticism. In my opinion, destabilizing the incentive balance that makes Bitcoin work is essentially the only way to really cause a system failure. Anything else that can be thrown at Bitcoin is something that should be robustly adapted to, even if it does cause you upset because the fiat price is affected negatively.

Closed Versus Open Layers

When it comes to mining incentives and how they are affected by secondary layers on top of Bitcoin, there is one important variable or characteristic to consider: Is the layer open or closed. What I mean by that, is how does the participation in that layer work? Does it actually require active collaboration and cooperation between participants on the second layer to function, or can it work asynchronously like Bitcoin’s base layer where participants do not need to synchronously cooperate for it to work?

This single detail has massive implications for the effect any new Bitcoin layers can have on the base layer mining incentives. And, at least from my point of view, people in this space dangerously miscalculate which one has positive consequences. A very widely held belief is that layers which require synchronous cooperation are inherently flawed, and that property is a massive shortcoming, while simultaneously believing that asynchronous non-cooperative layers are the holy grail of scaling.

I would contend the exact opposite is true. That requirement to synchronously cooperate that many people look at as a friction for users, engineering constraints that are crippling, or an insurmountable hurdle, can also be looked at as a form of defensive architecture.

While requiring interaction between participants in a layer to update the state of that layer, no one outside of the set of participants can try to game that layer. Think about a Lightning channel: Who can update the state of that Lightning channel? Only the participants. Who can directly gain from malicious actions on-chain to close or modify a channel on-chain? The participants. Miners can benefit indirectly from fees paid for malicious closures, but they have no direct control over that. They can only look at what each participant is willing to pay in fees, and pick the highest payer. That is in no way different than any other case of conflicting on-chain transactions competing to be confirmed first. Miners won’t even find themselves in that situation either, unless a channel participant chooses to submit a malicious close — which they have no control over.

So what does this do to alter or change the dynamic of miner incentives? Nothing. It is ultimately no different than Bitcoin incentives are without Lightning. Miners have to choose between a set of transactions, with no control whatsoever over what those transactions are, and pick the ones that make them the most money. Contrast that with drivechains.

The contents of a drivechain block can be thought of as a “transaction” for the purpose of thinking about this here, with the one exception that the single “transaction” contains a multitude of internal transactions whose order all have serious consequences for the value of the “transaction.” Who can modify or update the contents of this “transaction?” Literally anyone. Now to be clear, this is a weird conceptual thing trying to map the technical reality to this analogy, but it’s necessary I think to make the point I am trying to make. The drivechain block, or the data that anyone can modify or update and include in a transaction, isn’t so much the transaction itself as it is data anyone can include in their own transaction. But the point is anyone can include their own version in a transaction, and only one of them can confirm.

That immediately gives miners an asymmetric advantage in interacting with that layer over any other participant who is not a miner. When it comes to a Lightning channel, miners can’t just update or change the current state of the channel between you and someone else. That someone else has to be the miner themselves, or they have zero influence over that. When you and someone else have a channel, and your counterparty tries to confirm an old state, the miner gains nothing from that except mining fees, just like any other transaction. They have no special incentive to confirm an old state over the current one except the feerates between each other, just like every other transaction they consider. They receive no special benefit from one or the other.

Contrast that with a drivechain. Let’s ignore the issue of miners stealing coins in a way that validates sidechain rules, and pretend that is not an issue and will never happen. Drivechains still add a completely different dynamic and incentive for miners: Their ability to preferentially benefit from specific transactions occurring, not occurring, or the order they occur in. A miner can’t just jump into a Lightning channel they are not a member of, and change how it updates off-chain. They can’t stop you from making that off-chain payment just because it would benefit them to have it not occur. That’s just fundamentally not how Lightning works. That is exactly how drivechains work though. Anyone can make a transaction crafting a new drivechain block, but that block will never be confirmed without miners approval. Combine that reality with the fact that anyone can make one of those transactions, including miners themselves, and they have a massive asymmetric power no other participants do. They have total control over what the contents of sidechain blocks every time they mine a mainchain block. So unlike Lightning, in the context of drivechains, if a miner can benefit from your transaction not occurring, they can prevent it occuring so long as they mine the next block, and they can replace it with whatever they want.

That is a very, very big difference in terms of how these two types of second layers influence overall network incentives, and it doesn’t just apply to drivechains. It applies to any type of second layer system that is “open” in the sense that anyone can interact with it in a way to change or update its state. The same issue exists for non-federated rollups. Any type of rollup that doesn’t store the information users require to withdraw their money on the mainchain, but allows anyone who can provide a Zero Knowledge Proof that all the balance updates are valid to perform a state update, is the same type of dynamic, even worse arguably. Any miner at any time could update that rollup with perfectly valid transactions, and just hold the data users need to exit the rollup hostage. At any time. Even if they are just 1% of the mining hashrate. Miners can do nothing of the sort with “closed” systems like Lightning.

Wrapping It Up

Imagine all the types of systems people want to build on Bitcoin; decentralized exchanges, arbitrary smart contracts, programmatic stable value systems, etc. Applications built on top of Lightning inherently heavily restrict who can manipulate or try to game those applications; i.e. only the people actually involved in the Lightning channels hosting these applications can do so. Those types of applications constructed on something like a drivechain, or a rollup, are open for absolutely anyone to attempt to manipulate or game. Any type of application or system built on top of Bitcoin that has open access is gameable by anyone. And in an open access paradigm in Bitcoin, the miners always have the first place in line to game those applications. No matter what the application is, or how difficult it is to game it, or how much you can profit by gaming it, the miners always have the ability to game it first without letting anyone else make that attempt.

This is a very massive deviation from the current dynamic, or the future dynamic of closed systems, wherein miners simply select from a set of transactions presented by other people with no ability or control over what those transactions are. It’s a completely different universe. Closed systems entirely wall off the ability to extract value by gaming the system from miners, absent active collaboration with a majority of miners by a participant in that system. Open systems can be gamed asymmetrically by miners without even requiring a majority.

That is a complete paradigm shift, and a potentially dangerous one. The common argument why this isn’t a worry is that it is already made possible with systems like Stacks, or tokens on Ordinals. These systems, even though they are open systems, are not a proper part of the Bitcoin market. Stacks or an Ordinal token aren’t just inherently going to increase in value because Bitcoin does: They are freely floating tokens valued independently of bitcoin. If the value of those systems does not grow in lockstep with the value of bitcoin itself, then the degree to which they distort or alter incentives shrinks accordingly to the gap in growth between those systems and Bitcoin itself. They do not have the same degree of influence at all on incentives that a similar open system pegged directly to the value of Bitcoin itself does.

Arguing we should continue building more open systems on Bitcoin because some are possible now is akin to arguing that you have a high but not quite fatal dose of poison in your body, so you might as well keep ingesting more of that poison. It is a completely irrational and self-harming attitude and way of thinking.

From where I stand, the single most important factor to consider when developing and extending the functionality of Bitcoin going forward is to get the functionality we want or need while actively avoiding the enabling of any more “open systems” as I have defined them above. If distorting incentives is the only way for Bitcoin to fail, these types of systems are the poison pill with a lethal dosage within. We should avoid them like the plague.