Overview
Withdrawals are processed through a challenge-response mechanism where operators front the withdrawal payment and later prove their actions were valid. The system uses pre-signed transactions, zero-knowledge proofs, and a dissection game to ensure security without requiring changes to Bitcoin’s protocol.Key Participants
Operator
- Fronts withdrawal payments to users on Bitcoin L1
- Creates kickoff transaction to initiate BitVM2 process
- Executes bridge circuit off-chain to prove correctness
- Posts assert transactions revealing proof intermediate states
- Must provide more proof-of-work than any watchtower challenger
Watchtowers
- Monitor operator behavior for malicious actions
- Submit challenge transactions with Work Only Proofs (WOP)
- Provide alternative proof-of-work chains
- Automatically include all verifiers plus additional watchtowers
Challengers
- Verify operator’s assert transactions
- Post disprove transactions if errors are found
- Can slash operator collateral if malicious behavior is proven
- Execute single computation steps on-chain for verification
Pre-Signed Transaction Framework
During the deposit (peg-in) phase, verifiers pre-sign a comprehensive set of transactions that govern future withdrawals. This creates a deterministic “game tree” for the BitVM2 protocol.Why Pre-Sign?
- Covenant Emulation: Creates enforceable rules without Bitcoin script changes
- Deterministic Execution: Operators and challengers follow predefined paths
- Automated Challenge Flow: Each transaction input maps to verified circuit state
Pre-Signed Transaction Types
- Kickoff Connectors: Multiple small UTXOs spent by specific subsequent transactions
- Challenge Connectors: Enable watchtower and challenger actions
- Assert Connectors: Allow operator to post proof intermediates via WOTS
- Disprove Connectors: Enable on-chain verification of disputed steps
- Operator ChallengeACK/NACK: Acknowledge or fail to acknowledge watchtower challenges
Withdrawal Workflow
User Initiates Withdrawal on Citrea L2
User submits withdrawal request on Citrea L2 bridge contract:
- Specifies amount and Bitcoin destination address
- Burns or locks equivalent cBTC on Citrea
- Withdrawal recorded in Citrea state with deposit UTXO reference
- Storage proof becomes available for verification
Operator Fronts Payment
Operator executes the payout transaction on Bitcoin L1:
- Sends Bitcoin to user’s specified address
- Transaction included in a Bitcoin block
- Operator notes the block hash containing the payout
- Prepares to prove this action via bridge circuit
Kickoff Transaction
Operator broadcasts kickoff transaction to initiate reimbursement:
- Spends deposit UTXO from bridge vault
- Creates connector outputs for challenge-response game
- Commits payout block hash via Winternitz One-Time Signature (WOTS) in witness
- Locks operator collateral as security
Watchtower Challenge Period
Watchtowers can challenge if they detect issues:
- Watchtower sends challenge transaction spending personal funds
- Submits Work Only Proof (WOP) showing alternative proof-of-work
- Operator must acknowledge via OperatorChallengeACK transaction
- If operator fails to acknowledge, challenger can slash via OperatorChallengeNACK
Bridge Circuit Execution (Off-Chain)
Operator executes the bridge circuit off-chain to generate proof:Verification steps:
- Header Chain Proof (HCP): Verifies operator followed canonical Bitcoin chain with sufficient proof-of-work
-
Watchtower Challenge Processing:
- Verifies Schnorr signatures on watchtower challenges
- Sorts challenges by total work (descending)
- Finds maximum valid work from watchtowers
- Proves operator’s work exceeds watchtower maximum
-
Simple Payment Verification (SPV):
- Proves payout transaction inclusion in claimed block
- Uses Merkle proof with mid-state txid
- Verifies block header in Merkle Mountain Range (MMR)
-
Light Client Proof (LCP):
- Verifies Groth16 proof of Citrea L2 state
- Extracts state root from LCP output
- Ensures L1 block hash matches payout transaction block
-
EVM Storage Proofs:
- Verifies deposit UTXO storage proof
- Verifies withdrawal data storage proof
- Confirms withdrawal matches payout transaction
Assert Transactions
Operator posts assert transactions revealing proof computation:
- Breaks down Groth16 verification into steps
- Each assert transaction reveals intermediate values via WOTS
- Creates public, verifiable trace of computation
- Commits to next step’s expected output
Challenge Window
Challengers verify assert transactions:If valid:
- Operator successfully claims reimbursement after timeout
- Collateral returned to operator
- Withdrawal completes successfully
- Challenger posts disprove transaction (next step)
Disprove Transaction (If Challenged)
If error detected, challenger posts disprove transaction:BridgeDisproveScript:
- Verifies the Groth16 proof on-chain
- Checks all bridge circuit conditions
- Executes single disputed computation step
- Verifies inputs to bridge circuit match on-chain commitments
- Ensures WOTS-committed block hashes are correct
- Confirms watchtower challenges weren’t censored
Reimbursement or Slashing
Final outcome based on verification:Successful withdrawal:
- Operator retrieves reimbursement from vault
- Collateral returned
- User has received Bitcoin on L1
- Operator collateral burned
- User may need to re-submit withdrawal
- System maintains security invariants
BitVM2 Challenge-Response Game
Dissection Game
When a challenger disputes operator’s computation:- Initial Disagreement: Challenger identifies incorrect assert transaction
- Binary Search: Iteratively narrow down to specific computation step
- Single Step Execution: Execute disputed step on-chain in Bitcoin script
- Resolution: On-chain execution determines correctness
Why This Works
- Computation Decomposition: Large computation broken into tiny steps
- Script Size Limits: Only single step needs to fit in Bitcoin script
- Security Through Challenges: Optimistic execution with fraud proofs
- Trust Minimization: Bitcoin’s consensus rules verify disputed steps
Winternitz One-Time Signatures (WOTS)
Purpose
Bitcoin script cannot natively verify Schnorr signatures over arbitrary messages. WOTS enables message signing verifiable in Bitcoin script.How It Works
- Pre-computation: Generate hash chains for signature
- Signing: Reveal specific hashes based on message bits
- Verification: Hash revealed values and check against public key
Use Cases in Clementine
- Committing block hashes in kickoff transaction
- Revealing intermediate proof states in assert transactions
- Propagating state across UTXOs in BitVM2 protocol
Proof-of-Work Verification
Canonical Chain Determination
Bitcoin’s canonical chain is determined by total work (not just block count). Operator Requirements:- Must prove more total work than any watchtower challenger
- Uses Header Chain Proof (HCP) with accumulated difficulty
- Ensures operator followed the true Bitcoin consensus chain
- Submits Work Only Proof (WOP) with alternative chain
- Circuit verifies signature and proof validity
- Extracts total work from valid WOPs
- Operator must exceed maximum watchtower work
Failure Modes
If operator’s work ≤ watchtower work:- Operator automatically considered malicious
- Did not follow canonical Bitcoin chain
- Withdrawal validation fails
Security Guarantees
Trust Assumptions
- At least 1-of-N honest verifier: Funds safe if one verifier key secure
- At least 1-of-M honest operator: System operational if one operator participates
- Honest watchtower: Detects and challenges malicious operators
- Honest challenger: Can disprove invalid operator claims
Attack Scenarios
Malicious Operator:- Cannot steal funds due to proof verification
- Cannot censor watchtower challenges (enforced by pre-signed txs)
- Collateral at risk if invalid proof posted
- Multiple operators cannot bypass proof requirements
- Each withdrawal independently verified
- Watchtowers monitor all operators
Bridge Denominator
Withdrawals are processed in 10 BTC increments (bridge denominator). Why 10 BTC?- Each round transaction has limited kickoff connectors
- Smaller denominator = lower withdrawal throughput
- 1 BTC denominator currently infeasible
- Open research question for optimization
Code References
- Bridge circuit implementation:
risc0-circuits/bridge-circuit/ - Disprove scripts:
core/src/builder/script/ - BitVM2 integration:
core/src/bitvm_client.rs - Transaction builders:
core/src/builder/transaction/