# Building the BitVM Bridge with OP_CTV: A Feasible Path Forward
## Overview
After extensive consideration, the opcode `OP_CTV` ([CheckTemplateVerify](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki)) has been thoroughly studied, reviewed, and is now well understood by the Bitcoin community and its developers. 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`. It is possible that developers may not have to wait much longer before this feature is officially activated.
The BitVM bridge, on the other hand, seeks to establish a trust-minimized bridge system between Bitcoin and various sidechains or sidesystems. Historically, implementing covenants in Bitcoin has typically relied on mechanisms such as a presigning committee, which ensures that transactions are submitted in a predetermined manner. However, this approach often introduces trust assumptions and operational complexity.
For those interested in the technical details of how the BitVM bridge works, further information can be found [here](https://bitvm.org/bitvm2). While the latest design of the BitVM bridge has undergone significant changes compared to earlier iterations, it still retains the fundamental principles and key insights necessary for its implementation. Furthermore, it can be used as a reference example to demonstrate a potential approach for implementing the BitVM bridge with the use of `OP_CTV`. In the end, a demo is provided for you to see how the BitVM bridge may work in practice.

## 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

in that case, the`DefaultCheckTemplateVerifyHash` for any transaction can be precomputed in advance. Remarkably, this process does not require prior knowledge of the UTXOs that these transactions will eventually use as their inputs. Furthermore, the locking script of these transactions is pre-committed, enabling the prediction of the subsequent transaction in the sequence. This pre-commitment mechanism ensures a predictable execution flow, providing a clear framework for how the transactions will be executed.
The locking script appears straightforward if the goal is merely to select the spent transaction based on its `DefaultCheckTemplateVerifyHash`:

<DefaultCheckTemplateVerifyHash of spent transaction> OP_CHECKTEMPLATEVERIFY

In addition to BitVM bridge, it can also be applied in the following scenarios:

- [Vaults](https://github.com/jamesob/simple-ctv-vault)
- [ARK](https://ark-protocol.org/)
- [Sapio](https://github.com/sapio-lang/sapio)

## Demo

Below figure shows The original BitVM transation graph:
There are four possible paths based on the behavior of the operator and the challenger's actions:
1. Happy Path: If the operator is honest, no one challenges it. In that case, transaction sequence is: Pegin -> Pegout -> Kickoff -> Take1
2. Unhappy Path: Even if the operator is honest, a challenger might still attempt to challenge it, but the challenger won't success eventually. In this case, the transaction sequence would be: Pegin -> Pegout -> Kickoff -> Challenge -> Assert -> Take2
3. Disprove Path: If the operator is malicious and a challenger raises a challenge, the operator will ultimately be penalized. In this case, the transaction sequence would be: Pegin -> Kickoff -> Challenge -> Assert -> Disprove
4. Timeout Path: If the operator is malicious and a challenger raises a challenge, but the operator refuses to issue the assert transaction, the operator will still be penalized after a predefined timeout period. In this case, the transaction sequence would be: Pegin -> Kickoff -> Challenge -> Burn

Before `OP_CTV` is activated, a presigning committee is necessary to presign certain transactions from the BitVM transaction graph. These transactions include: Take1, Challenge, Assert, Take2, Disprove, and Burn. The purpose of this presigning process is to ensure that these transactions are executed in the precise order they were originally designed, thereby maintaining the integrity and predictability of the system's operation.

To simplify this model without losing its most critical technical aspects. a simple demo shows below:

It only includes two paths, based on the feature of `OP_CTV`, it looks like:
1. Happy Path: If the operator is honest, no one challenges it. In that case, transaction sequence is: Pegin -> Kickoff -> HappyTake
2. Disprove Path: If the operator is malicious and a challenger raises a challenge, the operator will ultimately be penalized. In this case, the transaction sequence would be: Pegin -> Kickoff -> Challenge -> Assert -> Disprove -> Reward.

Apart from the paths(Unhappy Path, Timeout Path) we have omitted, certain parts of this transaction graph still differ significantly from the original one. There are several reasons for these differences:
1. In the `OP_CTV` version of the BitVM bridge, Almost every transaction's input in `OP_CTV` version BitVM bridge are from the same transaction, with the exception of Kickoff. This difference arises because, even with `OP_CTV`, it appears impossible for Pegin to commit to Take1 and for Take1 to commit to Kickoff, as was achieved in the presigning committee version. This limitation introduces a critical vulnerability: if Pegin is submitted, a malicious operator could potentially submit a false Kickoff transaction to steal funds from Pegin.
However, the collateral input of Kickoff (the second input of Kickoff) does not face this issue. This is because the operator is solely responsible for selecting a collateral UTXO from its own funds to issue the Kickoff transaction. As a result, the operator cannot steal funds from itself, and no other party has the ability to exploit this mechanism either.
2. As discussed in the chapter on `OP_CTV`, it commits to all outputs of a specified transaction. However, in the Disprove Path of the BitVM bridge, the challenger must be rewarded for their action in challenging the malicious operator. In the presigning committee version, the challenger can be anyone, as long as they successfully submit the disprove transaction (in practice, this might often be the miner, as miners would have an incentive to front-run the transaction for their own gain). This is precisely why we need P2A ([Pay-to-Anchor](https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/)).With a P2A output, anyone can claim the funds as long as they successfully submit the reward transaction. This ensures that the reward mechanism remains fair and accessible, incentivizing challengers to act against malicious operators while maintaining the integrity of the system.
The reason why there are two P2A outputs in the Disprove transaction is that having only one P2A output would result in a transaction that is too small in size, which would then be rejected by the mempool's policy. If the mempool policy could be modified, the fee that is currently burnt could instead be set as the transaction fee paid to the miner. This adjustment would ensure that the transaction complies with the fee rate requirements and does not exceed the maximum allowable fee rate.
3. Actually, even if the malicious operator is slashed, the funds it attempted to claim should ideally be reclaimed by other operators rather than being given as a reward to the challenger. However, implementing such a mechanism could be overly complex for the purposes of a simple demo. That said, it is indeed feasible to design and implement such a system in practice.

The repository for the demo can be found [here](https://github.com/bitlayer-org/bitvm-ctv-demo), feel free to explore and enjoy!

## Reference:
BIP119 a.k.a OP_CTV: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
The upgrade plan of Bitcoin covenant: https://x.com/JeremyRubin/status/1889458352889143718
An introduction of BitVM: https://bitvm.org/bitvm2
P2A: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/
bitvm-ctv-demo: https://github.com/bitlayer-org/bitvm-ctv-demo