• Although it may seem possible that BitVM can be used to implement arbitrary logic off-chain, in practice the cost of executing the fraud proof on the L1 grows quickly with the size of the off-chain program. This issue limits the applicability of BitVM to specific problems such as trust-minimized BTC bridge.
• There is debate on what truly represents a Bitcoin L2

• Trust-minimized Bridging from L1
  • In Bitcoin, it’s not possible to have a bridge that is secured by the whole set of the L1 miners. Instead, the best option is to have a multi-sig wallet that stores the L2 assets. Hence, the security of the L2 bridge depends on the multi-sig security
  • Similarly, the proposed BitVM bridge requires the multisig signers to provide a security bond.
  • The peg-out interaction is protected by BitVM fraud proofs.
  • BitVM = ZK proofs, verified off-chain and contested via fraud proofs
• Chainway
  • The Chainway rollup uses the Bitcoin L1 as a DA layer to store the rollup’s ZKPs and state differences.
  • The rollup utilizes proof recursion such that each new proof aggregates the proof that was published on the previous L1 block.
  • The proof also aggregates “Forced Transactions” which are L2 related transactions that are broadcast on the L1 to force their inclusion on the L2. —> Censorship resistance path (applicable to Nomos)
• Botanix
  • Botanix L2 uses Bitcoin as the PoS asset to achieve consensus.
  • The L2 stores the Merkle Tree Root of all the L2 transactions on the L1 using inscriptions. This doesn't guarantee the DA of these transactions.
• Bison Network
  • A zk rollup using STARKs and uses Ordinals to store the L2 TX data and the generated ZKPs to the L1.
  • The verification is delegated to users who verify the ZKPs in their devices (ie. Celestia type).
  • For BTC bridging to/from the L2, Bison uses Discreet Log contracts (DLC). DLCs are secured by the L1 but depend on an external oracle.
• Stacks V2
  • When Stacks miners create a block these blocks are anchored in the Bitcoin L1 and receive confirmations from the L1 PoW miners. When a block receives 150 L1 confirmations, this block is considered final and cannot be forked without forking the Bitcoin L1. The Stacks miner who mined that block receives a reward in STX and their BTC bond is distributed to the network Stackers.
  • This way any Stacks blocks that are older than 150 blocks (~ 1 day old) depend on the Bitcoin L1 security.
  • The important L2 transactions, e.g., miner PoX bonds, peg-out txs, are to be performed as L1.
• SatoshiVM
  • Bitcoin L1 for DA + censorship resistance by supporting the ability to broadcast transactions on the L1 + and verifying the L2 ZKPs using BitVM-style fraud proofs.

Unveiling Clementine 🍊-Citrea's BitVM Based Trust-Minimized Two-Way Peg Program

• Citrea
  • Enables the first trust-minimized two-way peg mechanism.
  • Clementine, based on BitVM, only allows static size of UTXOs to peg-in and out. (assuming 1 BTC below)
  • Peg-in:
    • To make a peg-in, user locks 1 BTC into a UTXO that is only spendable by
      • N+1 of N+1 multisig (N - 1 verifiers, the bridge operator and user)
      • User after 200 blocks
  • Peg-out
    • To initiate a withdrawal, a user must transfer 1 BTC to a smart contract on Citrea, accompanied with a Bitcoin address. This address is recorded as a new leaf in the "Withdrawal Merkle Tree", then the 1 BTC is burned on Citrea.
  • Challenge
    • At least one honest verifier should initiate a challenge at the end of the commit period if:
      • perator tries to claim more BTC than it front covered
      • or the operator fails to cover any withdrawal before the checkpoint
    • As a result, the operator provides a ZK proof that proves the following:
      • Bitcoin + Citrea Light Client Proof
      • Bitcoin SPV (Simplified Payment Verification) Proofs of Withdrawals,
      • Bitcoin SPV Proofs of Revealed Preimages.
  • Makes sure that if the bridge operator tries to claim more BTC than it covered for withdrawals, it will lose access to the bridge funds forever.
  • The operator is responsible for covering every single withdrawal once the proof including the withdrawal is finalized on Bitcoin. After each period, the operator commits the amount of bridge funds it will claim. This amount equals to the sum of the front covered withdrawals since the previous checkpoint.
  • Every transaction output has a random preimage that only the operator knows. If the operator reveals the preimage for a UTXO, that branch of the transaction tree can be burnt by anyone. Since every Clementine deposit is pre-signed with the leaf UTXOs for the operator to claim, the operator cannot take those funds in the current period anymore.