# Unlocking the Potential of OP_CTV: Key Concepts for implementing BitVM Bridge
After extensive consideration, the opcode `OP_CTV` ([CheckTemplateVerify](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki)) has been well understood by the Bitcoin community and its developers now. As a result, [Jeremy Rubin](https://x.com/JeremyRubin/status/1889458352889143718) has expressed his support for a covenant upgrade plan aimed at activating `OP_CTV`. Soon after that announcement, Robin claimed his [support](https://x.com/robin_linus/status/1908981041450385408?s=46&t=kmKQtU-_oyvUW6FjhHSNTw) for `OP_CTV` too. In this article, I am trying to explain Why `OP_CTV` is important to the BitVM bridge, and the key points for implementing BitVM bridge with `OP_CTV`

## BitVM Bridge
Below figure shows The original BitVM transation graph:
the key point for implementing BitVM bridge is the `committee`. It forces all transactions of that graph should follow the specifed order. Otherwise the graph is broken and the fund that is locked in the transaction graph is in danger. Due to the `committee`, it based on 1-of-n honesty assumption, which means at least there is one honest member of `committee`, the bridge is safe. More information about BitVM bridge can be found [here](https://bitvm.org/bitvm2)

But that is also the biggest limitation of `committee`. the `committee` has to get involved a lot of members. Otherwise it will be hacked easily if all of the members are controlled. More and more members join the committee, the cost of communication will become higher and interaction between each other will become more complex. It is a tradeoff between cost and safety finally.

If `OP_CTV` is activated, the `committee` is unnecessary, because all transactions of that graph can be forced to follow the specified order by `OP_CTV`. Efficiency and cost will be improved highly then. Even the `OP_CTV` is activated, the way to implement BitVM bridge may still not very intuitive. Then two key concepts will be introduced.

## OP_CTV
`OP_CTV`, also known as `OP_CHECKTEMPLATEVERIFY`, is a Bitcoin opcode with a straightforward yet powerful function. It verifies whether the element at the top of the stack matches the `DefaultCheckTemplateVerifyHash` of the transaction itself. The `DefaultCheckTemplateVerifyHash` represents a novel approach to computing the digest of a transaction, designed to facilitate more efficient and predictable transaction processing. This digest calculation is particularly noteworthy because it commits to specific fields of a transaction in a carefully chosen order, prioritizing fields that are least likely to change and progressing to those that are more dynamic

1. nVersion
2. nLockTime
3. scriptSig hash (Optional! if it has)
4. input count
5. sequences hash
6. output count
7. outputs hash
8. input index

## P2SH Trick
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, this script looks like: `<ctv_hash> OP_CTV`, For the witness, it is unnecessary to contain something.
- `Logic Input`: This input contains only a minimal "dust" amount and is spent through a `P2SH` script signature. The redeem script looks like `<pk> OP_CHECKSIG` and the script_sig looks like: `<signature> <redeem_script>`


P2SH trick is the most important concept to implement BitVM bridge. The transacion graph shows above looks like the happy path of the original BitVM. Imagine that Tx1 is the `Peg in` transaction, Tx2 is the `Kick Off` and Tx3 is the `Take1`. The reason why we need these two different inputs is that `OP_CTV` can commit to the sibling inputs only if they are P2SH inputs, as `OP_CTV` only commits to the `ScriptSigs`.
another big difference you may already notice is the second input's sighash type MUST be 'all|anyone_can_pay'. because second input is not aware of the first input's information, such as `txid`. otherwise a hash circle will arise.
> the Tx3's first input's txid depends on Tx1's details, Tx1's details(more specifically, the script_pubkey of the first output) depend on Tx3's second input's P2SH sig, P2SH sigs depend on first inputs' txid

Due to the sighash type of the second input, which allows selective inclusion of it. Besides, these signatures are publicly accessible, enabling anyone to verify them. As a result, the second input will be exploited by malicious actor to prevent Tx3 being included. that is the reason why the fund(2B in the figure) are required by this P2SH input. If someone want to use it, it has to prepare for the fund. Then it will not do that because of the penalty.

## Broken Case

P2SH trick can be broken by a tricky script `broken_script` looks like:

OP_2DROP OP_TRUE

by exectuing this script, `<signature>` and `<redeem_script>` will be dropped by `OP_2DROP`, then only `OP_TRUE` is left on stack.

In such a scenario, any UTXO utilizing this script can allow Tx3 to replace the original Tx2, thereby putting the funds locked by Tx1 at risk.

But `broken_script` actually is not a standard address. Any transaction use it as an output will be rejected by mempool's default policy.

one advice is given to address this issue, but it doesn't work so far. it goes like script_sig is `<sigature> OP_DUP <pk> checksig <redeem script>`, while redeem script is the same

Besides being a non-standard transaction due to its violation of push-only restrictions, this script also violates the interpreter's check in function `EvalChecksigPreTapscript`, you may refer to the source code of Bitcoin [here](https://github.com/bitcoin/bitcoin/blob/cdc32994feadf3f15df3cfac5baae36b4b011462/src/script/interpreter.cpp#L324-L338)
This check functions by determining whether there is an `OP_CHECKSIG` in the `script_sig`. If present, it will verify whether the signature that `OP_CHECKSIG` will use exists in the `script_code`. In this case, the `script_code` is ``<signature> OP_DUP <pk> checksig <redeem script>``. Clearly, it is <signature>`, which will lead to the execution being aborted.

For further discussion on this broken case, you can refer to [here](https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/7)