In late 2023, Robin Linus published the BitVM whitepaper, taking the bitcoin developer community by storm. “Compute anything on bitcoin”, the whitepaper promised. Robin and other developers in the BitVM community are now actively working on building a trust-minimized bitcoin bridge using BitVM. One of the bridge variants that has been designed so far is what I am calling a “permissioned optimistic bridge” that relies on a 1-of-N (+ miners won’t steal) trust model.

In the permissioned optimistic bridge model, there is a permissioned group of N bridge participants. One participant assumes the role of “prover” aka “operator” and N-1 participants assume the role of “verifier” aka “watchtower”. The role of the operator is to process withdrawal requests from users, and the role of the watchtowers is to keep the operator honest. Every time the operator initiates a withdrawal, this starts a “challenge period” during which the withdrawal can be challenged by a watchtower. If the operator tries to make an invalid withdrawal from the bridge, then any one of the watchtowers can submit a challenge transaction on bitcoin to kick off the challenge process. If the challenge is successful, then the withdrawal is cancelled and the operator has some collateral slashed by the BitVM program. A more complete description of the permissioned optimistic bridge protocol can be found here.

This post introduces Bitstake, a variant of the permissioned optimistic bridge that uses a proof of stake protocol for bridge participant selection. The Bitstake protocol combines ideas from the Nomic bridge with the BitVM permissioned optimistic bridge. It can also be thought of as a more secure version of StakePeg. The purpose of introducing proof of stake to this bridge model is to provide a way for anyone to participate in the bridging process, provided they have enough stake to meet the qualification threshold.

Here is a step by step explanation of how the protocol works:

1. The Bitstake implementer defines the core logic of the Bitstake BitVM program. This includes details about the chain that BTC is being bridged to (the “destination chain”) and the operation of the bridge itself, including the asset to be used as the staking asset for the bridge. The staking asset could be BTC or any other asset. Note: If a new purpose-specific staking asset is used (perhaps created via proof of burn, as in StakePeg) then users could socially slash the stakers if they all become malicious.
2. The initial users who want to participate in the bridge protocol (the initial “stakers”) coordinate to construct the Bitstake address using BitVM. This initializes the state on the destination chain with the stake that should be allotted to each initial staker. The stakers receive staking power proportional to the amount of the staking asset that they have deposited/received and staked. Anyone can stake, but the active staker set participating in the bridge protocol is limited to the top N stakers by staking power (the aforementioned “qualification threshold”). This limit is enforced by the BitVM program and set by the implementer based on their assessment of bitcoin script size limits and practical MPC e.g. Musig2 coordination limits. See how the Nomic reserve wallet provides canonical ordering based on voting power for an in-depth explanation.
3. With the initial stakers set up, the bridge is now ready to start accepting deposits from users. Users send BTC to the Bitstake address and are credited with an equivalent amount of BTC on the destination chain. They can then use BTC on the destination chain according to whatever logic is supported by the chain’s consensus rules.
4. From time to time, stakers will come and go and modify their stake. When this happens, the BitVM program enforces that the next time there is a transaction spending from the Bitstake address, that the new Bitstake address that the change must be sent back to must be constructed with the most up-to-date staker set according to their current staking power. If the destination chain is a rollup, this staker rotation could happen as often as every rollup block, since every rollup block requires a state update transaction on bitcoin. See how the Nomic checkpoint transaction works for an in-depth explanation.
5. Censorship of stakers (preventing them from staking or modifying their stake) can be circumvented if the destination chain supports forced inclusion. Using forced inclusion, a staker or would-be staker can confirm a transaction on bitcoin that will guarantee that the transaction gets confirmed in the next block (or some block in the near future) on the destination chain. If the transaction is still excluded, then the destination chain will halt. This makes censorship potentially very costly for the attacker.

The rest of the protocol works like the 1-of-N permissioned optimistic bridge mentioned earlier. One of the stakers becomes the operator, and the rest are watchtowers. Users submit withdrawal requests to the operator, and the watchtowers keep the operator honest, etc etc.

As mentioned before, the main benefit of Bitstake is that there is now a way for anyone to become a participant in the bridge protocol, changing bridge operation from permissioned participation to permissionless participation. The staker set could also be used to provide other services to the destination chain, such as block production, validity proving, and data availability.

The main risk is that by allowing anyone to participate in the bridge, it could become dominated by a well-funded attacker. If the attacker gains control of all staker slots above the qualification threshold then they could steal all funds from the bridge, and they only risk their stake being slashed if a purpose-specific staking asset is used. It follows that for maximum security, the total value of active stake should comfortably exceed the total value of BTC held in the bridge.

Another risk is that, because anyone can become a staker, there is possibly a higher risk that one of the stakers may be willing to collude with a malicious hashpower majority to steal from the bridge. See my previously cited post for an empirical analysis of this risk.

Proof of work variant

An alternative to proof of stake is, of course, proof of work. A user who wants to be a (Bitwork?) bridge participant could submit proofs of work to a smart contract on the destination chain, and they would receive signing power in the bridge proportional to the total difficulty of the proof of work they have provided. The proof of work-based signing power would be socially slashable, like a purpose-specific staking asset, by switching the source of signing power to a different smart contract (or halting the chain altogether). The rest of the protocol would work as described above. The main tradeoff for using proof of work is that this is a sunk cost, whereas in proof of stake users may be able to sell their stake to someone else if they want to exit the protocol.

Acknowledgements

Shout outs to Robin Linus for providing feedback on a draft of this post and for inventing BitVM, Matt Bell for his work on the Nomic bridge, and gnar for independently coming up with a similar idea at the same time.

Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch! I will never sell, rent, or share your email address.