# [WIP] Building a BitVM Bridge Using OP_CTV and P2SH

The demo is shown below:

First of all, two types of inputs are defined:.
- `Fund Input`: This input holds a significant amount of funds and is secured using an `OP_CTV` script
- `Logic Input`: This input contains only a minimal "dust" amount and is spent through a `P2SH` script signature (script_sig)

Some transactions in the figure have both two types of inputs, such as `happytake`, `unhappytake` and `disprove`

Compared to the original approach (which relies on a presigning committee), several key modifications should be highlighted.

- To prevent malicious actors from spending the `Logic Input`, the corresponding output must include some funds derived from the `Fund input`. As you may observe, in transactions such as `happytake`, `unhappytake` and `disprove` each `Logic Input` is associated with an output that contains a portion of the funds. The potential for malicious misuse of the `Logic Input` stems from two key factors. First, these Logic Inputs must be signed with the SINGLE|ANYONE_CAN_PAY flag, which allows selective inclusion of inputs. Second, these signatures are publicly accessible, enabling anyone to verify them. Consequently, if malicious actors are not required to contribute funds to these `Logic Inputs`, they could exploit them to prevent the reclaim.
- The `Fund Input` of `disprove` s required to reveal the slash witness, as it cannot be incorporated into the `Logic Input`. This is due to two primary reasons: first, including the slash witness in the `Logic Input` would be too expensive; second, the slash witness becomes available only after the `assert` transaction is submitted, at which point all intermediate values are revealed

However, there are still some issues to address
- There are always multiple `Logic Inputs` but only a single `Fund Input` in the transaction. As a result, some malicious actors can use one of these `Logic Input` to prevent honest operator to reclaim with a small amount of funds. It creates an opportunity for malicious actors to exploit one of the `Logic Inputs` to obstruct an honest operator to reclaim funds, all while leveraging only a minimal amount of capital
- Due to the constraints imposed by the hash circle, it is fundamentally impossible to establish a direct connection between `time` and `kickoff`. This limitation introduces a critical vulnerability: a malicious operator cannot be effectively punished if it broadcasts time prematurely. While it is technically feasible to establish a direct connection between `time` and transactions such as `happytake` or `unhappytake`, doing so comes with the disadvantage that enabling reusable collateral is not possible
- Using P2SH as a leaf script is not allowed, which means connectors such as connectorA, connectorB, and connectorC are impractical. While it might be possible to emulate this functionality with `OP_IF`, doing so introduces significant inefficiencies and constraints. Specifically, the approach is computationally expensive, and it is further limited by the maximum allowable size of a redeem script, which is capped at 520 bytes. Limitations of P2SH can be found [here](https://learnmeabitcoin.com/technical/script/p2sh/)
- Implementing `assert` is fundamentally unachievable within these constraints. The functionality of assert relies on P2SH, but the limitations on the size of the redeem script make it impossible to incorporate a bit commitment script within P2SH. This restriction prevents the practical implementation of assert in this context.

you can find a code demo [here](https://github.com/bitlayer-org/bitvm-ctv-demo), but it is not completed yet due to the issues mention above