# A Comparative Analysis of Reusable Collateral and OP_CTV

## TL;DR
Due to the properties of `OP_CTV` which allow the exact collateral UTXO to be ignored during the setup ceremony, the BitVM bridge can achieve significantly improved capital efficiency.
A [demo](https://github.com/bitlayer-org/bitvm-ctv-demo) of `OP_CTV` has been successfully completed. Through this demonstration, you can gain a deeper understanding of how the collateral mechanism operates within the system.

## Original desgin
In the original BitVM bridge design, collateral must be locked during the presigning ceremony to ensure that, in the event of malicious behavior by the operator, the collateral can be slashed as a penalty. As illustrated in the figure below, each `Kick Off` transaction requires a collateral amount of 2 BTC to be deposited. If the operator acts dishonestly, this 2 BTC collateral will be forfeited through the `Disprove` transaction. Conversely, if the operator behaves honestly, the collateral will be returned via the `Take1` transaction.


This approach results in extremely low capital efficiency, as the operator must prepare a separate deposit for each `Kick Off` transaction. For instance, if there are 10 `Peg in` transactions, each associated with 10 reclaimable UTXOs, the total required deposit would be 200BTC(2 BTC * 10 * 10)

## Reusable collateral
To address this issue, [Resulable Collateral](https://hackmd.io/dMpeW-8ZSJCfMnUSFDzwnw) is introduced. This mechanism allows sequential `time` transactions to share and reuse the same collateral across different transaction graphs, significantly enhancing capital efficiency. With this approach, only a single collateral deposit (e.g., 2 BTC) is required for each `Peg In` transaction.


However, The `reclaim` process is inherently sequential, which introduces several limitations:
1. If the operator has only one collateral. it can't perform multiple `reclaim` simultaneously.
2. Other operators MUST wait for the corresponding timeout period($\Delta T$ in the figure above), even if they didn't send the `Pegout` transaction successfully (which means they are forbidden to do the `reclaim`!)
3. A `reclaim` can only be initiated in the order dictated by the sequence of `time` transactions. In practice, this makes it challenging to determine which UTXO should be reclaimed, especially when the UTXOs have varying denominations

if you want to lean more about these scenarios, please refer to the details provided [here](https://hackmd.io/dMpeW-8ZSJCfMnUSFDzwnw)

## OP_CTV
With `OP_CTV`, there is no need to lock collateral during the presigning ceremony. This is due to the inherent properties of `OP_CTV`, which allow the collateral input to remain undetermined at the time of presigning. In the event that a `reclaim` is actually triggered, the collateral can be determined at that time, providing greater flexibility and efficiency in the process. such as in the figure below, the second input(1 BTC) is determined only when the `kickoff` transaction is ready to be sent. You can find more information about `OP_CTV` [here](https://hackmd.io/vluib9UQSq2PObPHFA7Jbw)
> The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and currently executing input index. except the exact txid and vout of previous transactions.


Because `OP_CTV` eliminates the need for sequential `time` transactions (or the `time` chain), several advantages are introduced::
1. The operator has the ability to perform multiple `reclaim` operations simultaneously, provided they have sufficient collateral available at the time. If the operator lacks enough BTC to support concurrent operations, they can still execute the reclaim process sequentially without any functional difference than before. This flexibility ensures that the process remains adaptable to the operator's available resources.
2. Other operators doesn't need to wait for the corresponding timeout period, different operators can freely select and process random reclaimable UTXOs as they wish.
3. the `reclaim` can be initiated in any order