Drivechain could provide an avenue for continuing development on Bitcoin while not compromising the security created by ossification.

This is an opinion editorial by Nikita Chashchinskii, a software developer working on BIP300 sidechains.

Today, Bitcoin faces a challenge. There are two contradicting requirements necessary for success, and if we want to win, we have to find a way to satisfy both. First there is the requirement for security — it is paramount when billions of dollars are at stake. In the world of security professional paranoia and conservatism are a necessity. Any single change introduced into Bitcoin software is a potential security vulnerability. Ideally we would freeze Bitcoin’s codebase and then never introduce any changes that don’t fix security vulnerabilities.

This first requirement is already on its way to being satisfied with a creeping ossification, which is not a conscious strategy, but an accidental political reality established as a result of historical events and technological limitations. Every single change that touches consensus must go through a long, extensive and rigorous process of deliberation. You can see this with the Taproot soft fork, which took 46 months from proposal in January 2018 to activation in November 2021, and in the more recent OP_CTV activation controversy. It may be by accident, but we are on our way to satisfying the first requirement.

There is a grave cost to this unconscious “strategy” though. In the existing accidental ossification regime we are subject to an extreme, and perhaps even justified, level of risk aversion, because if a decision is reached and a risk is taken, every single Bitcoin user must bear that risk. Technological improvements either take years to implement or are rejected outright. In such a regime we will never see some technological advancements.

In the current situation Bitcoin will never see zero-knowledge cryptography or ring signatures implemented. And so Bitcoin will never have strong privacy. Only Bitcoin’s competition will have strong privacy.

For scaling we will be stuck with the Lightning Network and with custodial solutions. Lightning is great as far as it goes, but in terms of scaling it has limitations. Its capacity to onboard new users is limited, and it has yet unsolved UX challenges. Besides, some proposals that make Lightning meaningfully better such as SIGHASH_ANYPREVOUT will either take multiple years to activate or will never be activated.

This is all to say nothing of more experimental ideas and technologies such as Blockstream’s simplicity proposal. It enables smart contracts on Bitcoin with a better design than existing smart contract implementations on altcoins. Given the complexity of this proposal, it is very unlikely to ever see the light of day under the existing process. Only Bitcoin’s largest competitor will have smart contracts.

And that is not all. Besides that, there are the already existing technological improvements in terms of privacy, scaling and smart contracts, which Bitcoin won’t see implemented. We will voluntarily or, worse, accidentally relinquish the power of all future technological innovation to our competition. Our competition is not constrained by ossification at all.

Significant improvements are already left on the table. Imagine how far behind we will be within a decade or two of progress in cryptography and computer science, if the situation doesn’t change.

In order to win, Bitcoin requires a mechanism for change and adaptation to achieve victory in the competitive environment it is in. It doesn’t matter how great Bitcoin is in its current state. Without such a mechanism Bitcoin’s potential will stay fixed, and its competitors’ and adversaries’ potentials will grow. In this situation no matter how far ahead you are, and no matter how far behind your competitors and adversaries, eventually they will catch up. Failure to adapt in a competitive environment usually doesn’t work out.

Unless at some point there is a transition from the tradition and isolation of the Edo period to open mindedness and modernization of the Meiji period, the British will show up with ironclads, Gatling guns and rifles, and you would be stuck with samurai swords and horses.

These are the two “irreconcilable” requirements we have — change and security. The only good way to reconcile them, that I am aware of, is to separate Bitcoin into two isolated layers. Layer 1 needs to be a completely ossified base layer, never making any non-security improving changes (in all likelihood that would be the existing Bitcoin Core). Layer 2 needs to be a sidechain layer that is free to take risks and to implement arbitrary features.

There must be a secure two-way peg that lets anyone transfer funds between the base layer and any sidechain on Layer 2 at a 1:1 exchange rate. This two-way peg mechanism and perhaps a blind merged mining arrangement should be the only things that connect Layer 1 and Layer 2.

With this mechanism, the decision of how much technological risk to take on would be made individually and unilaterally by every single user. Any user could move funds into a particular sidechain, and voluntarily accept its trade-offs and risks, or move them back to the ossified security of the base layer at any time.

This individual taking or not taking of risks and trade-offs, which only affects the people who partake in it, would replace the existing process of collective risk taking through deliberation by the entire community and all-or-nothing introduction of changes that affect every single Bitcoin user.

There already exists a custodial implementation of this idea — the Liquid Network. But, because it is custodial, it is flawed. In order to attack it you need to compromise five custodians distributed around the world and not just one, which is a lot better than something like Coinbase, but it is custodial nonetheless.

Liquid’s success has been pretty limited. As of September 14, 2022 according to liquid.net there are 3,560 BTC pegged into the network. That is around $71 million or 0.019% of the current circulating BTC supply of slightly more than 19 million coins. It is better than nothing, but an implementation that relies on an 11-of-15 multisig controlled by 15 functionary incorporated companies around the world requires an unacceptable level of trust for a supposedly trustless distributed cryptocurrency, which is reflected in peoples’ reluctance to actually use it — hence there is only ~$71 million in it.

There is a non-custodial implementation of the exact same idea proposed in BIP300 and BIP301Drivechain. It requires a softfork to be activated, but it is distributed and trustless. The two-way peg is secured by paying all sidechain transaction fees to miners to perform a fixed and very simple set of functions. You can get the full description of the mechanism in the BIPs.

This is a substantial security improvement over Liquid. In order to attack Liquid you only have to compromise five incorporated functionaries, which is a woefully insufficient security arrangement given the kinds of adversaries Bitcoin might face if it continues to grow. In order to attack Drivechain you have to perform a 51% attack sustained over three months, while making it painfully obvious to every single participant of the network that you are performing an attack and giving said participants plenty of time to respond.

With Drivechain we have a way to reconcile our two “irreconcilable” requirements for change and for security. We can ossify Bitcoin more completely than with the existing “accidental political reality” kind of ossification, we can preserve Bitcoin’s trustless and distributed nature, and at the exact same time, we can ensure that, in the future, we would be the “British” with metaphorical ironclads, Gatling guns and rifles, and our competitors and adversaries would be the ones stuck with metaphorical samurai swords and horses.

This is a guest post by Nikita Chashchinskii. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Od

Pridaj komentár

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *