BitVM-based bridges and emergency upgrades
New bitcoin bridges offer improved trust assumptions over standard federations, but there may be a catch...
As BitVM-based bridges near production use, I’ve started thinking about a topic known as “emergency upgrade” paths. With the help of the Citrea team, I was able to work through different ways to validate a BitVM bridge’s spending paths to determine if it has an emergency upgrade mechanism. This blog is an attempt to discuss how upcoming projects might implement these spend paths. Please note that emergency upgrade paths, and the multisigs that spend them, are not a “BitVM feature”. They’re a mechanism that are widely used in bridges secured by proving systems, and I believe they will be leveraged within BitVM-based bridge constructions. This post is exploratory and hopefully sparks a discussion on how we should disclose these types of spend paths.
Ever been in a jam where you need to withdraw money from your account instantly? Maybe your car broke down and you need to pay a mechanic. Or, maybe you found out your friend had a few too many cocktails and needs to get bailed out of jail.
Well, BitVM-based bridges probably want the same guarantees. We want bridge operators to be bound by the rules of the specific BitVM set up. But what if something went wrong? What if there was an exploit in the system that could see an attacker take all of the money with no recourse or cause funds to be permanently frozen?
If an honest actor finds a bug, they’d likely want a way to move all the money out of the bridge contract before an exploit occurs.
We achieve this with emergency multisigs – an additional spending path that can be implemented in BitVM-based bridges to enable a set of signers, or a single signer, to spend the funds out of a given bridge instance and bypass the challenge game and optimistic reimbursement mechanism entirely.
BitVM is a new technology and its corresponding bridge programs are nascent implementations. Some teams don’t want to ship these new bridge constructions without guardrails in place. Early partners who operate the bridge, and supply liquidity, may also want an emergency off switch that ensures their funds can be moved if a bug arises. Immutability doesn’t align with business incentives 100% of the time.
Emergency upgrade multisigs might already exist in live BitVM bridge implementations. More bridge constructions are coming to market and they’re likely going to launch with security councils – a permissioned group of signers that operate an emergency multisig. If the security model in these systems ultimately falls back to a permissioned M-of-N multisig (albeit a temporary one), users have a right to know.
I’ve spent the last two weeks diving into how these security councils might be set up and have thought through ways to validate their existence (with the help of some BitVM alliance members, of course).
The exercise raised an interesting “problem”. We can’t verify the spending paths, onchain, until they are spent. Meaning, some users may never even know that a permissioned M-of-N multisig is the ultimate trust assumption in a BitVM-based bridge if its participants never disclose it.
BitVM Bridges refresher
BitVM is a way to perform arbitrary computation on bitcoin pioneered by Robin Linus. It sparked a new wave of bitcoin development, and a number of teams are using this technique to build layer 2 bridge contracts. These contracts enable layer 2s to have multiple operators escrow bitcoin that backs wrapped bitcoin assets on the layer 2. But, most crucially, it additionally enables an optimistic fraud detection mechanism that can be used to dispute any malicious (or incorrect) withdrawal attempts from a bridge operator.
In the set up phase, a group of signers come together in an N-of-N multisig to presign the transaction graph for a given bridge. If someone deletes their key used in the pre-signing ceremony, then the UTXOs locked in the bridge contracts can only be spent by the pre-defined spending scripts.
In some designs, operators must front liquidity and then request a reimbursement from the bridge contract. The spending paths restrict the spending paths to the operators themselves after a certain period of time passes. Other designs enable users to work with honest operators who give them the private key needed to spend the funds out of the bridge.
In either design, an honest operator is required to process a withdrawal. If they are dishonest, for example, they attest to a withdrawal that conflicts with a sidesystem's latest state, then they can be challenged by a watchtower.
A watchtower is an entity, or person, that runs the BitVM verifier software and is able to challenge, and stop, fraudulent withdrawal requests from BitVM bridge operators.
An example of an incorrect withdrawal could be an operator withdrawing more bitcoin from the BitVM instance than they’re supposed to. This is why payouts from the bridge contract include a timelock. It enables a watchtower ample time to submit a challenge. The window of time between the withdrawal transaction being broadcasted and the timelock is known as a challenge window.
Operators (or users) should only be able to withdraw funds from the bridge after a challenge window has passed. In BitVM-based bridges, theft requires all operators and watchtowers to collude to rug the bridge. If 1 party is honest, regularly checks the chain, and their verifier is online and willing to submit a challenge, the funds cannot be stolen. This 1-of-N trust assumption is desirable because it means we trust less people than a standard federation where a dishonest majority can steal the funds.
The example above creates a more trust-minimized bridge set up than what’s currently on bitcoin today. But in practice, the core trust assumption will likely fall back to a permissioned multisig (albeit temporarily).
An introduction to emergency multisigs
As pointed out in the intro, teams can (and will) include an emergency spending path in their BitVM instances. Whether they should, or shouldn’t, isn’t really important. It’s more important to simply acknowledge that nearly all in-production BitVM-based bridges will include an emergency spend mechanism in their infancy. We should expect that teams properly disclose the nature of these emergency spend paths.
Emergency multisigs are not a feature of BitVM. They’re widely used in bridges secured by proving systems as a way to upgrade systems if a bug is found. Rollups in other ecosystems have set a precedent for deploying emergency multisigs.
BitVM bridges use v1 SegWit scripts to create, and pre-sign, the spending paths for their bridge contracts. Taproot Scripts use MAST to enable a variety of spend conditions for a single UTXO. When a leaf script is used to spend a UTXO, only the individual leaf script, that was used to spend the locked funds, is revealed.
The BitVM2 paper correctly states that pre-signed transactions can restrict an operator to only withdraw funds in a way that can be challenged. But, there’s nothing stopping the developers of a particular instance to include additional spending paths, that can withdraw funds from the bridge, in the Taproot tree.
Each spending path for a Taproot tree is called a “leaf” script. To unlock and spend the UTXO, only one of the valid leafs needs to be revealed.
Let’s look at an example: the first path, or leaf, is the standard withdrawal path with a challenge window. The other path is an emergency spending path that can bypass the challenge window.
Leaf A: the 1-of-N fraud proof, protected spend condition
OP_PUSHBYTES_2 <SomeDelay>
OP_CSV
OP_DROP
OP_PUSHBYTES_32 <OperatorPubKey>
OP_CHECKSIGLeaf B: a 2 of 3 emergency peg-out spend condition
OP_PUSHBYTES_32 <pubkey1>
OP_CHECKSIG
OP_PUSHBYTES_32 <pubkey2>
OP_CHECKSIGADD
OP_PUSHBYTES_32 <pubkey3>
OP_CHECKSIGADD
OP_PUSHNUM_2
OP_NUMEQUALLeaf A is a normal withdrawal reimbursement in a BitVM instance. After a challenge period (<SomeDelay>) passes, a pre-defined operator can redeem the money from the bridge contract. If the operator who spends a UTXO locked in the bridge contract is dishonest, a watchtower can challenge them during the challenge window (<SomeDelay>, the time in between a BitVM contract spend and the expiration of the timelock) and prevent the dishonest withdrawal request.
Leaf A represents a pre-signed transaction constructed by the N-N pre-signing committee.
Leaf B, on the other hand, is an immediate spend path where a 2/3 multisig can immediately spend all of the funds in the BitVM contract. They can do this if the team detects an unexploited bug in the contract, or they decide to run off with all the money.
When I say “contract”, I’m referring to the BitVM contract that governs the spending conditions for a bitcoin UTXO.
Both of these spending paths can exist in a bridge’s Taptree. While it’s not necessarily desirable to have spending paths that bypass the BitVM challenge-response game, there’s no reason they couldn’t be implemented.
Still, the spending conditions within these trees can be quite flexible. In our example, we only display two spending conditions. However, teams can create trees that contain spending conditions with various types of logic. For example, an emergency that can result in user funds being stolen, can have no delay and be spent by a small 2-of-3 signer set. Whereas a broader protocol upgrade can be initiated by a 9-of-12 security council and be bound by a timelock.
Independent of the specific design, as they’ll vary across implementations, it’s important that we can verify the various spending conditions. An “issue” with modern bitcoin scripts is that you can’t publicly validate the script until it is spent. Strictly related to BitVM-based bridges, this means that we cannot verify the spending paths until a specific leaf is used to spend a UTXO. Remember, when a leaf is spent, the spending conditions of that leaf alone is revealed. So if we only have an instance where normal withdrawals are executed, we cannot verify if an emergency spend path exists and vice versa.
This can raise an issue. If the team inserted an emergency spend mechanism into the Taptree, but never disclosed it, users can never be sure that there isn’t a permissioned multisig, or one person, that can spend all the money locked in the bridge.
After mulling on this for a week or so, I’ve thought of some ways a team can disclose a bridge’s spend paths.
Disclosure methods
Simply disclose the spend paths in the docs
The simplest way to go about this is for teams to publish the various privileged roles in their docs. A team would simply publish who the bridge operators are, who participated in the pre-signing ceremony, who runs the light client(s), and who the watchtowers are.
Some disclosure is better than none, but we can’t verify the spending paths for the bridge based on statements in documentation sites alone. Being able to directly verify the scripts is more desirable.
Test transactions prior to deposits
Teams can, of course, spend test transactions for the various spending paths from the bridge addresses. They can spend some funds in a given instance, eventually reveal all the spend paths, and users can verify the spending paths themselves.
This requires teams to spend every leaf in the Taptree. But even with test transactions, we can never be sure that a team didn’t insert an additional spending condition that was never spent and revealed. Teams can always opt to not spend a specific leaf and not reveal the spending condition. This is typically a feature of Taproot MAST, but in the context of bridges, it can lessen users’ confidence that teams are in-fact revealing the entirety of the spending script.
Unfortunately, test transactions don’t provide the level of transparency we’re expecting as we trust the teams to test every valid spend path.
Leverage large covenant emulation committees
Another path forward is that teams leverage a substantially large covenant emulation committee, and give independent parties the opportunity to participate in pre-signing all of the transactions within the bridge's transaction graph. This would give independent parties the ability to verify the existence of emergency multisigs and how many signers are present within them.
But, this still requires users to trust the covenant committee’s participants rather than verify the scripts themselves. I’d still argue there is a path forward where we can give any user the opportunity to verify the bridge’s spend paths.
Create a standardized disclosure method
In my opinion, we should expect teams to publish the entire tapscript MAST that was created for the BitVM instance.
If teams provide the internal pubkey that created the tapscript, the entire set of script leaves, and the corresponding bridge addresses, we can do some magic.
With this information, we can take the internal pubkey that was used to generate the spending paths, and the merkle root derived from the Taptree, and add them together to produce a tweaked public key. If the tweaked public key matches that of the BitVM bridge addresses, then we’ve verified that the script is in fact the sole spending script.
Voila! We have a verifiable, disclosure method. If a team publishes an incorrect tapscript MAST, then the tweaked public key wouldn’t match that of the bridge addresses.
This disclosure method gives us a way to actually verify the key trust assumptions related to a BitVM bride instance. But it requires the teams to publish the entire tree and associated internal pubkey.
Importance for transparency
Even if we don’t disclose the signers’ identities, we still need the scripts to understand what the actual trust assumptions are. These systems are built to have 1-of-N trust assumptions. But if the trust assumption ultimately falls to a permissioned multisig, those who are depositing funds into these contracts have a right to know.
I expect most BitVM-based bridges to include this type of spend path. I hope that emergency multisig spend paths aren’t in place forever and we can upgrade to more trust-minimized designs. But, we can’t hand wave away emergency multisigs and say they aren’t the sole trust model.
The emergency spend path is quite literally the trust model as long as it’s in place.
— Janusz