# Bitcoin Bridge based on BitVM3

## Overview
The garbled circuit approach has minimal impact on the overall transaction graph architecture, enabling seamless migration from BitVM2 to BitVM3. The primary distinction lies in Assert transaction efficiency: garbled circuits reduce transaction size from 2.6MB to approximately 60KB.
Regarding penalty distribution, both Disprove and AssertTimeout transactions could theoretically benefit any party capable of transaction issuing (using SINGLE signature hash type), following the original BitVM2 model. Our design specifically incentivizes legitimate challengers rather than opportunistic MEV bots.
Due to the inherent limitations of Bitcoin's scripting language, we cannot directly prove the inclusion of specific transactions, such as a Pegout. We overcome this by implementing an optimistic challenge protocol, which, by its nature, makes the protocol permissioned.
While our protocol is compatible with reusable collateral and concurrent reclaim mechanisms, the implementation of these features is beyond the scope of this paper.

- Pros:
- Compared to existing approaches such as the original BitVM2 design or Citrea's light client architecture, this implementation streamlines the protocol by consolidating redundant transactions and eliminating unnecessary roles while preserving equivalent security guarantees.
- the design mitigates MEV exploitation risks associated with specific transaction types, enabling native Bitcoin-based incentivization for network participants without dependence on external side systems.
- Cons:
- Upon detection of fraudulent operator behavior, multiple challengers may simultaneously initiate challenge procedures, creating a "winner-takes-all" dynamic where only the first successful Disprove transaction receives rewards. This coordination problem necessitates an off-chain protocol to manage challenge sequencing and ensure equitable participation among legitimate monitoring parties.
- Each challenger has a different garbled circuit script for every Pegin transaction, which increases communication complexity.

A special scenario we found：
Operator-challenger Collusion Risk: The protocol faces a coordination attack where malicious operators collaborate with corrupt challengers to disadvantage honest participants. The attack sequence involves: (1) a malicious operator creating a fraudulent assertion, (2) a colluding challenger starts an invalid challenge with incorrect proof, (3) an honest challenger responding with legitimate challenges, (4) operator deliberately accepts the invalid proof, rewarding the malicious challenger.
Mitigation Strategy: While this attack imposes net losses on colluders due to higher operator stake requirements, it unnecessarily penalizes honest challengers. GC-enabled low-cost transactions could enable ecosystem fund compensation for affected honest participants. This vulnerability pattern appears consistent with some concurrent reclaim design.
## Roles
The system involves 3 key participant roles, each with distinct responsibilities:
**Operator**: Operators participate in the pre-signing ceremony and facilitate user withdrawals. When a Operator assists users in withdrawing BTC from the bridge, they become eligible to initiate a reimbursement process to recover their costs and earn rewards for their services.
**Signer**: Multiple Signers collaborate during the pre-signing phase to negotiate and establish a temporary Musig2 key, referred to as the PreSign Key. This key is subsequently used for pre-signing operations after the Signers have verified the Transaction Graph generated by the Operator, ensuring the validity of the proposed transactions.
**Challenger**: Challengers serve as the system's oversight mechanism. Once a Operator initiates a reimbursement request, Challengers conduct thorough verification to determine whether the reimbursement claim is legitimate. If a Challenger detects fraudulent or invalid reimbursement attempts, they can launch a challenge to dispute the claim and protect the system's integrity.
This multi-party architecture ensures that no single entity can unilaterally control the bridge operations while maintaining security through distributed verification and challenge mechanisms. Besides, all of them should be determined before the pre-signing ceremony

## Transactions

- Pegin:
- Inputs: Any, while all inputs are of the same type, only 1 BTC is shown here for simplicity. This does not imply that there is only one input.
- Outputs: Depends on the splitting policy and the desired deposit amount. For example, if the total input sum is $a$, the change amount is $b$, the fee is $c$ and each reclaimable UTXO's denomination is $d$, then the total output number is:$\frac {a-b-c}{d}$ + 1 (optional, for change) + 1 (MUST, for inscription). Only one is shown here for simplicity
- Take:
- Input
- any reclaimable UTXO
- The second output of Kickff
- Outputs:
- The fund will be take by Operator
- Kickoff: it is the fundamental in this protocol
- Inputs: any spendable UTXO from Operator, only 1 BTC is shown here for simplicity. If the operator is detected malicious, it will be spent by some slash transactions
- Outputs: it can be divided into two parts
- The finalizer output: This output contains the UTXO from the Operator. In the case of an honest reimbursement, this UTXO will be claimed by the Take transaction; otherwise, it will be claimed by one of the Disprove transactions.
- The challenge and assert outputs: For a system with $N$ challengers, there will be $N$ corresponding pairs of challenge and assert outputs.
- Challenge: For every reclaimable UTXO, there exists a corresponding Challenge transaction for each challenger. When a challenger detects that the reimbursement for a specific reclaimable UTXO is malicious, the challenger will issue this Challenge transaction.
- Inputs:
- This input spends the challenge output from the Kickoff transaction and commits the operator's compensation (referenced in output0). This input requires unlocking by both the operator and the challenger. During the pre-signing ceremony, it is signed using the SINGLE|ANYONECANPAY hash type by both parties.
- Serves as the funding source for the operator's compensation.
- Outputs:
- Contains the operator's address along with the corresponding compensation amount.
- Contains the longest chain proof provided by the challenger.
- ChallengeTimeout: This transaction is issued by the operator when the challenger fails to submit a Challenge transaction within the specified timeout period of a day following the Kickoff transaction. It serves to prevent the challenge path.
- Inputs:
- Spends the challenge output from the kickoff transaction but can only be executed after the a-day timeout period has elapsed.
- Spends the asset output from the kickoff transaction.
- Outputs:
- Contains a minimal dust amount to satisfy transaction validity requirements. When Ephemeral Anchors are activated, this amount may be reduced to zero.
- AssertTimeout: This transaction is issued by the challenger when the operator fails to submit an Assert transaction within the specified timeout period of b days following the Kickoff transaction. It serves to disprove the malicious operator
- Inputs:
- Spends the assert output from the kickoff transaction but can only be executed after the b-day timeout period has elapsed.
- Spend the finalizer output of kickoff transaction
- Outputs:
- a portion of the operator's staked funds will be burnt
- The rest part of the operator's staked funds will be moved to Challenger
- Assert: When a challenge is initiated by the challenger, the operator must respond by issuing an Assert transaction. This transaction serves to reveal all input labels of the garbled circuit, providing the necessary cryptographic proof to address the challenge.
- Inputs:
- Contains the revealed input labels of the garbled circuit. The bridge proof that was committed by input lables should include the header chain proof that was revealed by challenger. the header chain proof is committed by challenger's signature
- Outputs:
- The disprove script taproot
- Disprove: Upon receiving the revealed input labels from the Assert transaction, the challenger performs local verification to identify incorrect labels. If discrepancies are found, the challenger issues a Disprove transaction to challenge the operator's computation and trigger penalty mechanisms.
- Inputs:
- Contains the identified incorrect labels as evidence of operator misconduct
- Outputs:
- Burns a portion of the operator's staked funds
- Redistributes the remaining operator stake to the challenger as a reward for successful challenge