A Review of the the BitVM2-based "Linus24" Bridge

In a previous article I introduced a taxonomy to analyze validating bridges based on 4 properties: Consensus Validation, Interactivity, Anchor and Finality. Now we apply this taxonomy to the recently published BitVM2 Bridge. All the findings presented in this article were shared with the BitVM Alliance team weeks after the paper came out, but here we apply a more rigorous analysis based on our taxonomy.

The paper presents some neat new tools, but the security of some of those tools is questionable and they may need rework or replacement. Additionally, the design presented in the paper leaves important issues out, such as collateral optimization or how to handle operation retries. Finally, the BitVM2 bridge design works for rollups, but does not easily extend to sidechains. In this article I'll focus on identifying those issues of the BitVM2 bridge design that present challenges and are inherent to the use of the BitVM2 verification system.

From now on I will refer to the “BitVM bridge” as Linus24 bridge, using the main author's surname and date of paper publication. This is to avoid BitVM naming problems that have occurred in the past, and those that will occur in the future because of the bridge name given by the authors. The paper uses the terms BitVM2 and BitVM interchangeably but the bridge is not built on top of BitVM, but BitVM2. While BitVM is a general-purpose proving system, BitVM2 only verifies Groth16 SNARKs.

The Linus24 bridge is not generic, and only works for rollups. Since the BitVM2 verification protocol could be used also to develop bridges to sidechains, the name “BitVM bridge” is even more problematic. Many different bridge designs are being built using BitVM2. Citrea’s “Clementine” bridge, for example, is also based on BitVM2. Therefore, a unique name is required for each BitVM2-based bridge, and naming it “the BitVM Bridge” does not help.

A nice thing about the Linus24 bridge paper is that it formalizes some concepts that were previously only discussed in the Telegram forum or in github comments. For example, connected outputs, covenant emulation using a new opcode OP_BLOCKHASH, persisting state between Bitcoin transactions (priorly described in the BitVMX paper). Then it describes how a function f can be split into partial subfunctions and those subfunctions can be challenged independently.

Last minute update: Today I saw a post on X suggesting that the BitVM2 Alliance team is trying to address the major problem presented in this article (the use of superblocks). Also today I had a conversation with one of the BitVM developers who assured me the problem has not been solved without additional security assumptions.

The Design

The Linus24 bridge is a simple design, and benefits from the anyone-can-challenge property of BitVM2. However, according to our taxonomy based on 4 key security properties, the Linus24 bridge is:

• partially validating (SPV)
• “almost” interactive
• “almost” stateful

Compared to the ideal bridge we presented with our taxonomy, it has 3 of the 4 key security properties degraded.

“Almost” Interactive but not really interactive

An interactive bridge is one where there can be chain counter-proofs, not only chain proofs, to decide the “longest chain”. A chain proof involves convincing the bridge that a certain sequence of block headers are in the canonical chain, and they contain a specific transaction or event. A bridge that accepts proofs sent by anyone, but not counter-proofs, is still a non-interactive bridge.

By “almost” interactive I mean that while the Linus24 protocol does not accept multi-block counter-proofs (as it should), it does try to compensate for it by accepting single superblock as a counter-proof. A superblock is a Bitcoin header that could solve a much higher difficulty target. In other words, its hash starts with more zeros than those strictly necessary to verify its difficulty target. A superblock represents a probabilistic proof that a certain chain fork was created with a high hashrate. The higher the superblock’s implicit difficulty, the higher the rate. The problem is that while the presence of a superblock probabilistically proves a certain sustained hashrate up to that block, the absence of a superblock doesn’t prove the opposite (no hashrate) with equal cryptoeconomic security. Discarding superblocks may be cheap and can be used by malicious parties to subvert the protocol.

Almost-stateful but not not really stateful

A stateful bridge is one that connects all chain proofs to the blockchain genesis. By “almost” stateful I mean that while the Linus24 withdrawal proofs are not rooted in a specific genesis Bitcoin block hash (as they should), they are still anchored to a special block in the chain that is supposedly on the canonical chain. With a trick, the prover will try to prove that the majority of the Bitcoin hashrate was mining that special block, choosing the special block to be a superblock. If the majority of the hashrate was mining it, then it should belong to the canonical chain, right? We’ll explain several undesirable consequences of using this trick.

Since the BitVM2 does not accept two inputs, one from each party involved, it doesn’t natively support chain counter-proofs. BitVM2 can’t accept inputs from unregistered parties because the protocol has no knowledge of their Lamport public keys, which is required to accept Lamport-signed data from them. BitVM2 does accept fraud proofs, but a counter-proof is a very special type of fraud proof that not only proves fraud, but proves it by showing a “better” proof of the same nature as the one disproved. As a sidenote, BitVMX does accept multiple inputs, which maps perfectly with chain proofs and counter-proofs. To achieve something close to counter-proofs, the Linus24 bridge found a way to prove and disprove belonging to the canonical chain using another trick: it accepts a chain counter-proof using a connection between two smart contracts, a BitVM-like instance and a BitVM2 instance. The first contract checks the PoW of a given chain fork in a coarse way by checking a single superblock, but accepting another superblock as counter-proof (in the DisproveChain transaction). This first smart contract doesn’t check anything related to the content of the chain fork. The second contract checks all the properties of the chain fork in detail accepting a fraud-proof, but without allowing a counter-proof. The prover must present compatible proofs to both smart contracts (here the design in the paper has a minor vulnerability because it doesn’t enforce this with a Lamport equivocation challenge).

The benefit of using two contracts is that the first does a coarse grained checking that can be executed in a single Bitcoin script, and therefore it allows anyone to challenge it with a counter-proof. Checking the proof of work of a Bitcoin header consumes almost 1M of bitcoin opcodes, so it still needs a non-standard transaction, but it works. The second contract does the full check, without counter-proof. Checking a high number of superblocks within the first contract would not be possible while still allowing anyone to challenge, because the checking script would be so long that the proof wouldn’t be able to be checked in a single block. Anyone-can-challenge is the main selling point of BitVM2. Allowing anyone to challenge is a benefit, but this shortcut to sidestep the interactivity property of the bridge proofs may lead to vulnerabilities.

Novel Tools in the Linus24 Paper

The paper introduces 6 novel concepts. I call them “tools”, because they could be used as independent mechanisms by other bridge protocols. Here is a list of tools introduced:

1. Peg-out competition: how operators compete to be elected as peg-out forwarders and earn a fee.
2. Handling of collateral: how the participants can lock collateral (a security bond) that is slashed on misbehavior (section 2.3 of the Linus24 paper)
3. Crowdfunding a challenge: how a set of unregistered verifiers could work together to crowdfund the funds necessary to challenge a misbehaving operator (see “Crowdfunding Collateral for Challenges” in section 5.2)
4. Force signing of current time: how an operator can be forced to sign the current time with a Lamport signature so that other Bitcoin events related to Bitcoin transactions can be proven not to have occurred before the current time. The timestamp cannot be manipulated at will, and cannot be delayed more than a constant amount. This prevents the pegOut transaction to be included in a fake future block
5. Proving cumulative work after a signed time: how an operator can prove that he has started collecting confirmation blocks not before at a previously signed time proven by the previous tool (see PowPV in section 6.2).
6. Proving inclusion in Bitcoin: this is the final ingredient to a peg-out proof, and involves proving that the burn of rollup bitcoins, the PegOut transaction that pays to the user, the signed timestamp and the confirmation work all belong to the same blockchain branch and they occur in the right sequence. This is proven by a SNARK.

All these tools are interesting, and as such, they need a deeper analysis, but all seem to have certain flaws. I will summarize the potential problems that may arise when using them. These problems could render the protocol insecure.

Peg-out competition. All of the operators compete to publish the PegOut transaction in order to pay the funds (vB) to the end-user (named Bob in the paper). Operators pay Bob from their own wallet minus the operator fees by issuing PegOut transactions. However, since all operator’s PegOut transactions are in conflict, only one of the transactions will be accepted into the Bitcoin blockchain, and that will be the one paying higher transaction fees, so the mempool chooses the winner.

If the operator fees become significant (Galaxy analysts estimate fees could be around 0.38%), what will happen in practice is that operators will compete to publish their version of the PegOut transaction, each operator submitting replacement transactions to the memory pool using replace-by-fee (RBF) or child-pays-for-parent (CPFP), paying higher and higher fees to miners. This will create a race to the bottom in net revenue. The winner may end up paying almost all his revenue ( fOB ) to the miner of the block containing the PegOut. On the contrary, if the operator fees are insignificant, then no operator will take the risk to participate in the peg out process. Is there an equilibrium? At different points in time, each operator may have a different opportunity cost of fronting the peg-out, so they could become active or inactive, but as long as two operators compete for the same peg-out, only the miners will win. There is another problem with this tool: since the PegOut transaction is a anyone-can-pay transaction, it also means that it is susceptible to transaction cycling attacks. This recent and unpatched Bitcoin attack vector can be used to prevent operators from performing the PegOut transaction by replacing the transaction in the mempool and then canceling the replacement. The mempool is not a perfect auctioning system for an UTXO. To prevent this attack PegOut transactions would need to be sent directly to mining pools using an ad-hoc service.

Handling of Collateral. The design in the paper defines fixed operator and challenger security bonds (d₿ and c₿) that are locked into UTXOs. The security bonds UTXOs are tied to specific peg-out UTXOs, making the protocol inefficient in handling collateral.

In the BitVMX-based Union bridge design, as well as in Citrea’s Clementine design, bonds can be shared between peg-Ins. In Citrea’s protocol, a slashed operator loses the security bonds of all peg-ins he is participating in, reducing the individual peg-ins amounts required. Our Union bridge design is even more flexible, and security bonds can be dynamically added or removed to UTXOs. Some days ago Robin Linus posted an image of a new bridge design in the BitVM telegram channel. This new design attempts to share collateral between peg-ins to fix this problem. A problem with the solution proposed is that it limits the rate of rollup withdrawals to one withdrawal every 30 days. The Union bridge only rate limits peg-outs if there are disputes, but absent disputes all bitcoins can be withdrawn concurrently.

Crowdfunding a challenge. There are two problems with the Challenge transaction in the Linus24 design. This transaction must pay the operator the dispute cost up-front (a very high amount in the order of tens of thousands of dollars), and therefore it is supposed to be crowdfunded. The cost must cover the publication of the Assert transaction.

The first problem is that the crowdfunded amount is fixed at setup time. The paper states that the collateral (c₿) deposited by challengers should be parameterized such that it covers the transaction fees spent by the operator. However, the protocol cannot ensure that the Challenge transaction will cover the operator’s costs. Transaction fees are highly volatile in Bitcoin but the collateral amount (c₿) must be fixed at setup time. Therefore it can happen that the bitcoin fee rises to a point where the crowdfunded amount will not be enough to cover the cost. If the crowdfund is attempted during mempool congestion, this could become a DoS attack vector to the operator. The opposite can also happen: Bitcoin fees become so low that the operator is incentivized to be challenged to receive payment of c₿. This is one of the reasons why Linus24 bridge should only be used to peg-in very high amounts (probably not below 100K USD). It is hard for any blockchain protocol to reimburse transaction costs, because a party can usually overpay fees without incurring in any loss by colluding with a miner (Rootstock is one of the exceptions, as transaction fees are not collected by a single miner, but smoothed over several blocks. Ethereum also is an exception because part of the fees are burned).

The second problem is that the users who crowdfunded a Challenge transaction are not necessarily the ones who will receive the bounty (a₿) in the Disprove or DisproveChain transactions in case the operator loses the challenge. The crowdfund is a sunk cost and nobody will want to pay that cost.

Force signing of current time. One of the key novelties of the Linus24 protocol is that the operator must commit to the current time by signing a timestamp with a Lamport signature. The protocol prevents the commitment to lie in the future, by using absolute time locks. The mechanism uses several transactions: ClaimLC, ClaimTimeout, TimeTimeout and StartTime.

Due to the nature of the CLTV opcode used, the protocol cannot prevent the operator from committing to a block in the blockchain past, but this doesn’t seem to affect the protocol security. However, due to the fact that Bitcoin timestamps can go backwards in time up to the median of the past 11 block timestamps, the operator must take care not to choose a superblock that has a heavier grand parent block with higher timestamp or else his superblock may be disproved.

Proving recent cumulative work. In our previous article we discussed how non-interactive bridges are more vulnerable to double-spend attacks. In simple non-interactive bridge designs, the bridge will expect a chain proof with certain fixed cumulative work, then a minority of the miners can slowly prepare a future attack by pre-mining blocks. These blocks can later be sent altogether to the bridge to fake a peg-out, and honest observers have no recourse. The Linus24 bridge tries to prevent this attack by comparing the heaviest superblock in the chain submitted by the operator with the heaviest superblock that can be provided by any other user, for the same time interval. The time commitment tool described earlier is used to define the interval when superblocks must be monitored and collected. If a challenger can provide a superblock that is heavier than the one provided by the operator, then most probably this is an indication that the fork presented by the operator is not part of the honest chain, which normally has the highest hashrate.

There are several problems with this probabilistic proof.

First, if there were another Bitcoin-like chain with SHA-256 hashrate competing with Bitcoin during a peg-out phase, the foreign blocks could be used to fakely prove or disprove a Bitcoin bridge peg-out using a superblock from the wrong chain. This is because the protocol doesn’t check that the submitted superblock connects to Bitcoin’s honest chain, and Bitcoin-like chains do not have a “chain-id” field on their headers. Happily, currently there is no relevant Bitcoin fork with substantial hashrate (Bitcoin Cash has less than 0.5% of Bitcoin hashrate), so this attack is not possible against Bitcoin now, while it’s possible against Bitcoin Cash.

Second, if Bitcoin forks because of a consensus problem, and the hashrate splits between competing forks, then the Linus24 bridge UTXOs that lie in a temporary minority fork become immediately vulnerable to attacks. Any user monitoring both forks can use a superblock from one fork to cheat on the other. The fork doesn't need to last many blocks to produce a competing superblock, but the longer the fork, the worse it is. A hard fork where Bitcoin splits between two persistent chains (i.e. Bitcoin cash fork) would be devastating for the Linus24 bridge. If the hashrate splits evenly between forks, then a minority miner can turn the majority hashrate from one fork to the other performing a hashrate balance attack to steal the funds in one fork.

The Linus24 bridge creates a direct bounty to fork the Bitcoin mining network. Attackers will be incentivized to disrupt the peer to peer network to force forks. While in theory forks can be used to perform double-spend attacks against any payee, during forks all systems that have humans in the loop will be manually reconfigured to require more confirmations or to pause payment processing, so they are generally safe. Exchanges can temporarily halt deposits. Merchants can stop delivering goods. However, validating bridges are autonomous systems so they cannot change their confirmation policy during forks. They become vulnerable unless there is a scheme of proofs and counter-proofs, and a fork protection system. We’ll explain how forks can be detected by a smart contract in a follow-up article, but the simplest protection is that, in case of close-competing forks, the bridge discards both the chain proof and counter-proof and waits for longer proofs, without penalizing any party. We added such protective measures for the Union bridge.

Finally, the cost paid by Bitcoin for each superblock created is the same as a normal block. Bitcoin does not pay more for superblocks. This creates a potential problem with incentives. A miner that mines a block with low hash (the potentially heaviest superblock) may prefer to withhold it to use it as a counter-proof to penalize the operator issuing a DisproveChain transaction, and get rewarded (amount a₿) as if he was defending the protocol. Therefore the value "a₿" must be lower than the current block reward. If a₿ is higher than the block reward, then miners would withhold highly probable superblocks instead of publishing them to the Bitcoin network. Close to the end of the timeout period there will be higher incentives for withholding superblocks, as the chances to be outcompeted are lower. This establishes a limit on the reward to protocol defenders (the value “a₿”). Currently a Bitcoin block reward is worth approximately 300k USD, so “a₿” must be less than 300k USD, but with successive subsidy halvings the value could dangerously decrease. The paper suggests that “a” will be a small value, so it seems the protocol is secure. But if “a” is low, then the soundness of the protocol could be compromised depending on how the protocol reacts to a disproved operator (and this is unspecified in the paper).

The Superblock Withhold Vulnerability and the Retry/Revert Choice

We analyze in more detail the vulnerability of the Linus24 protocol when expecting a single or multiple superblocks. We must make some assumptions on how the Linus24 would be implemented because the paper does not cover all failure cases, specifically, what happens if an operator is challenged and loses. From the perspective of the protocol, this is a failed peg-out and the operator is assumed to be malicious. Let’s assume Bob (the user that receives the advance payment from the operator) colludes with some percentage of the miners, such as 10%. Those miners will mine normally, except that they will withhold potential superblocks. They have approximately a 9% chance to mine the highest superblock in the desired interval. The malicious miners can hide any suspected superblock when mining Bitcoin blocks, and only show its header later to win the DisproveChain challenge. The Linus24 protocol will punish the operator and probably ban him from participating in future peg-outs. It will also revert the peg-out in the rollup and give Bob his rollup-bitcoins back. However, the operator has already paid Bob, so Bob has doubled his coins ! It’s clear that the incentive to withhold superblocks is too high.

To avoid this vulnerability, each time an operator is punished by a DisproveChain transaction, the bridge must decide either revert the payment to Bob on the rollup, or command to retry it using another operator but in behalf of a PayOut made by the previous operator. In both cases (revert or retry), without the rollup having the capability of blockchain introspection, Bob would have successfully executed a double-spend attack and has doubled his coins.

If the bridge connects to a rollup, then it could be possible to make the rollup consensus depend on the payment to Bob by using blockchain introspection. We call this solution Peg-out introspection. A rollup consensus can have access to the Bitcoin blockchain since rollup state transitions are ordered within the parent blockchain. So a well designed rollup can use Peg-out introspection to correctly select between revert or retry. But the paper doesn’t mention how the operator failure case is handled, nor does it mention blockchain introspection as the solution.

Using multiple superblocks instead of a single superblock reduces the chances that a minority miner outcompetes the majority of the miners. For example, if we collect the top 4 superblocks and compare their added difficulties, 10% of the miners have only a 0.27% chance of winning. However, a single bitcoin script cannot verify the proof of work of more than 4 Bitcoin headers. The best known implementation of SHA-256 for Bitcoin script (created by Fairgate), requires 968K script bytes for double-hashing the header to obtain that block id (from which the PoW can be verified). This means that at most 4 superblocks can be checked in a single non-standard Bitcoin transaction and none in a standard one. Even if using multiple superblocks mitigates the attack, the larger DisproveChain transaction would add tens of thousands of dollars to the cost of a bridge dispute

Using the Linus24 protocol to connect to a Sidechain

A rollup consensus may be dependent on the main chain state, and therefore we can have peg-out introspection, which prevents double-spends, as mentioned before. However, this is not the case for a typical sidechain, which by definition is a fully independent blockchain. In case we try to use the Linus24 bridge as-is to connect to a typical sidechain (or any other L1), a single superblock won’t be enough to protect from block withholding attacks. We’ll need to add another, much stronger, Node-In-A-Contract (NIAC) system running on the sidechain. The sidechain should have a mechanism to enable contracts to query facts about the Bitcoin blockchain The Rootstock sidechain has such a system, a Bitcoin SPV node running in consensus. This node is part of the current bridge contract. The Union bridge makes use of this SPV node to check peg-out transactions and prevent double-spends.

Summary

The Linus24 Bridge design is a step forward to build a fully working rollup bridge, but it is not a finished design. It still needs several improvements, or possibly the redesign of some of its mechanisms. Since creating an efficient generic and fully validating bridge for Bitcoin is not currently possible, validating bridges make security/efficiency trade-offs on some of the 4 core security properties: Consensus Validation, Interactivity, Anchor and Finality. The Linus24 bridge makes trade-offs in all of them. However, giving up interactivity or anchor is not a prerequisite for Bitcoin bridges. More secure bridges could be designed. For example, BitVMX provides dual-input capability (for chain proof and counter-proof), a feature that is used by the upcoming Union bridge.
A final conclusion is that the Linus24 protocol is designed for connecting Bitcoin to a Bitcoin rollup, but it cannot be easily adapted to be used for Bitcoin sidechains without changes and the addition of more security-critical components. We will keep building a BitVMX-based Union bridge that is specifically tailored for sidechains and other L1, with the support of Fairgate Labs and Rootstock Labs.