Author: Robin Linus
Source: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
Abstract: CTV enhances BitVM bridges by eliminating the need for pre-signed commitment transactions and fundamentally removing the honest participant security assumption. Additionally, CSFS significantly improves capital efficiency and reduces startup burden.
Introduction
In BitVM, we use input-committing covenants to represent states, such as expressing "if no one initiates a challenge, the operator can withdraw funds from the bridge contract" as a specific output that challengers can burn to indicate they believe the operator's withdrawal is malicious, thus forcing the operator into a challenge process. Conversely, in an ideal scenario, this output can "survive" through the entire challenge period, after which the operator can execute a withdrawal transaction.
The current BitVM bridge contract design relies on simulated covenants to ensure deposit safety. This commitment requires a 1-of-n honest participant assumption and introduces various undesirable complexities in practice. Until recently, we believed CTV was insufficient to replace commitment transactions because CTV was designed to commit only to outputs, not inputs. However, the truth reveals a trick that can enable the functionality we need.
Script Signature Trick
The key idea is to leverage the fact that CTV can commit to all input script signatures. Suppose we want to express "Input A can only be spent together with Input B", we can do this as follows:
- Define Input B as a (traditional) P2SH script.
- Pre-generate a signature using the `SINGLE|NONE` sighash flag, essentially signing only Input B. This signature only commits to Input B, and because P2SH is not a SegWit type, this signature will appear in Input B's "scriptSig" field.
- Define Input A as a P2TR output containing a CTV condition, where the template hash commits to the script signatures of future transaction inputs, including the signature of Input B.
The result is: Input A commits to the signature of Input B, which in turn commits to Input B. So Input A can only be spent together with Input B.
Details
Such a commitment is unidirectional: Input A commits to Input B, but not vice versa. A bidirectional commitment would theoretically be better, but is impossible due to hash cycling (even if we had `TXHASH` or other introspection opcodes).
For our bridge contract, it's sufficient to constrain that Input B is always burned. However, this cannot be achieved with CTV - the template hash would need to commit to its own `scriptSig`, and the signature already commits to Input B, its TXID - creating a hash cycle.
To solve this, we redesigned the transaction graph to ensure the contract remains secure even if Input B is not spent together with Input A. The specific details of the new design are beyond the scope of this article, as they require a deeper understanding of the bridge contract architecture.
Specific Improvements
- CTV provides unconditional deposit safety. Even if all operators are malicious, they cannot steal funds from the bridge contract. While we still rely on a fundamental liveness assumption to ensure withdrawals, the simplified startup process allows us to significantly expand the operator set - possibly by an order of magnitude. Thus, the assumption that at least one operator remains online becomes more likely.
- CSFS replaces Lamport signatures, reducing transaction size by approximately 10 times. This greatly reduces the capital overhead for bridge contract operators.
- Non-hardened key derivation becomes possible with CSFS, allowing anyone to non-interactively compute the operator's public key. This significantly simplifies the fund locking process by reducing the amount of data operators need to provide.
- In the current design, fund locking still requires an operator signature, introducing potential censorship. While this can be mitigated by other systems, our long-term goal is to point towards completely non-interactive locking by changing the bridge contract, thus completely eliminating interaction requirements.
For these reasons, the BitVM Alliance strongly supports the CTV + CSFS proposal.
Conclusion
The above techniques demonstrate that by flexibly using CTV and CSFS, we can greatly simplify the construction of BitVM bridge contracts while improving security and efficiency. By removing the need for pre-signed commitment transactions and the fundamental honest participant assumption, CTV allows bridge contracts to obtain unconditional security guarantees. Meanwhile, CSFS can reduce capital overhead and operational complexity, paving the way for more scalable and decentralized bridge contracts. While some open challenges remain - such as making fund locking completely non-interactive - the new design represents a significant step towards minimally trusted, practical Bitcoin interoperability.
