Analyzing Bitlayer’s OP-DLC Bridge Proposal to Address the Shortcomings of bitVM Bridge
Authors: @Nickqiaoo & @faustliu1997
In our recent article, we briefly introduced BitVM2, an optimistic withdrawal bridge based on BitVM.
BitVM Bridge and OP-DLC (Part1) : Next Generation of Bitcoin Layer2 Bridges
This scheme uses a “prepay-and-reimburse” model where the Operator pays funds on behalf of the BitVM bridge users and later claims reimbursement from the BitVM bridge. If an Operator submits a false reimbursement request, it can be challenged by anyone to be slashed.
However, it’s really challenging to implement BitVM (hard to achieve in the short term). BitVM also faces liveness/availability issues, and lacks fund transparency: the BitVM bridge collects users’ deposits into a pooled account.
To address these issues and provide a clean, independent channel for funds, BitLayer proposed the OP-DLC cross-chain bridge similar to DLC.link in addition to the optimistic BitVM2 bridge, offering users two exits — BitVM bridge and OP-DLC bridge — to slowly get rid of the BitVM bridge and federation.
DLC: Discreet Log Contracts
DLC, proposed by MIT’s Digital Currency Initiative, is a lightweight Bitcoin smart contract. It enables contracts protecting privacy via off-chain interactions and pre-signed methods instead of sending contract details onto the chain. We’ll illustrate the work flow of DLC through a football betting scenario below.
Suppose Alice and Bob bet on the result of a match between Real Madrid and Barcelona happening in 3 days, each betting 1 BTC.
If Real Madrid wins, Alice gets 1.5 BTC and Bob gets 0.5 BTC, so Alice gains 0.5 BTC and Bob loses 0.5 BTC. If Barcelona wins, Alice gets 0.5 BTC and Bob gets 1.5 BTC. If it’s a draw, both get their 1 BTC back.
To make this bet trustless, we need to prevent either party from cheating. Using 2/2 or 2/3 multisig alone isn’t trustless enough. DLC addresses this with a solution relying on third-party oracles. The process has four main parts.
Take Alice and Bob’s case for example.
The first step in creating a DLC involves locking funds in a multisig address. This process ensures that both parties commit their respective 1 BTC to the agreement.
Step 1: Creating a Fund Transaction and Locking Funds in a Multisig Address
- Alice and Bob create an off-chain fund transaction.
- This transaction locks 1 BTC from each party into a 2/2 multisig address.
- The multisig address requires both parties’ signatures to spend the 2 BTC.
The fund transaction remains off-chain, stored locally on Alice’s and Bob’s clients. Both parties understand the implications of the fund transaction taking effect. The theoretical groundwork is laid for the DLC’s creation.
In the first stage of creating a DLC, we can confirm that both parties will lock their 1 BTC each in a multisig address in the future.
Step 2: Simulating Future Events and Outcomes
In the second step, Alice and Bob continue to simulate possible future events and outcomes. For instance, after the match results are announced, there could be various scenarios: Alice wins, Bob wins, or a tie. These outcomes lead to different distributions of the Bitcoin in the aforementioned 2/2 multisig address.
CETs: Contract Execution Transactions
Different outcomes require different transaction instructions to be triggered. These “transactions that may be on-chain in the future” are called CETs (Contract Execution Transactions). Alice and Bob must first simulate all possible CETs and generate a transaction dataset that includes all CETs.
Example: CETs for the Alice-Bob Bet
Based on the possible outcomes of the Alice-Bob bet, Alice creates the following CETs:
CET1: Alice receives 1.5 BTC from the multisig address, Bob receives 0.5 BTC.
CET2: Alice receives 0.5 BTC from the multisig address, Bob receives 1.5 BTC.
CET3: Both parties receive 1 BTC each.
How to Create a CET ( CET1 breakdown)
Let’s consider CET1 (Alice gets 1.5 BTC, Bob gets 0.5 BTC) as an example.
This transaction involves transferring 1.5 BTC from the multisig address to a Taproot address triggered by Alice and the oracle’s output. The remaining 0.5 BTC is transferred to Bob’s address. The corresponding event is: Real Madrid wins, Alice wins 0.5 BTC, Bob loses 0.5 BTC.
To spend the 1.5 BTC in CET1, Alice must obtain a signature from the oracle confirming “Real Madrid wins.” In other words, Alice can only withdraw the 1.5 BTC after the oracle broadcasts the “Real Madrid victory” message.
The mechanisms for CET2 and CET3 follow a similar pattern and will not be elaborated on here.
What if Alice broadcasts CET1 prematurely or attempts to withdraw the 1.5 BTC in the “Barcelona wins” scenario when CET1 is only triggered by “Real Madrid wins”?
As illustrated in the previous diagram, upon on-chain execution, CET1 transfers the locked 2 BTC from the original multisig address:
- 0.5 BTC to Bob
- 1.5 BTC to a Taproot address
Alice can only unlock the BTC locked in the Taproot address after the oracle outputs “Real Madrid wins.” The effect is as shown in the diagram below.
Additionally, this Taproot address is subject to a time lock. If Alice fails to withdraw the 1.5 BTC within the specified time lock window, Bob has the right to claim the funds.
Assuming the oracle is honest, Alice cannot claim the 1.5 BTC. Upon time lock expiration, Bob can withdraw 1.5 BTC. Combined with the 0.5 BTC directly transferred to Bob upon CET1’s on-chain execution, Bob will ultimately receive all the funds.
For Alice, regardless of the outcome, the most advantageous strategy is to broadcast the valid CET. Broadcasting an invalid CET would result in greater losses.
The CETs described above incorporate an improvement to Taproot’s Schnorr signatures. This involves utilizing the oracle’s public key and event outcomes to construct distinct addresses for different results. Subsequently, only when the oracle publishes the signature corresponding to a specific outcome can the BTC locked in the corresponding address be spent.
Besides, it’s likely that Alice, aware of her loss, might refrain from broadcasting her constructed CET1. What can we do?
Bob can construct a custom CET for the “Alice loses, Bob wins” scenario. This CET’s outcome aligns with Alice’s CET1, differing only in specific details.
The outlined steps represent the core CET construction process.
Step3 : Communication and Signatures
In the third step of DLC creation, Alice and Bob communicate to verify each other’s constructed CET transactions. They attach their signatures to the valid CETs. Once verified, both parties can trust each other and deposit 1 BTC each into the aforementioned 2/2 multisig address. They await the broadcasting of a CET to trigger the subsequent process.
Upon the oracle’s disclosure of the result and acquisition of the oracle’s signature, either party can broadcast the valid CET. This triggers the redistribution of the 2 BTC locked in the multisig address.
If the loser hastily broadcasts an invalid CET, they forfeit all funds. Broadcasting the valid CET allows the loser to reclaim 0.5 BTC.
A common question arises: How does DLC differ from a standard 2/3 multisig?
In a 2/3 multisig, collusion between any two parties can lead to theft of the entire asset. DLC, through the construction of a CET set in advance, restricts all scenarios for the opposing party. Even if the oracle colludes, the resulting losses are often limited.
Multisig requires each party to sign specific on-chain transactions. In contrast, DLC only requires the oracle to sign the outcome of a specific event. The oracle does not need to know the content of the CET/on-chain transaction, or even the existence of Alice and Bob. It interacts with users just like a regular oracle.
DLC essentially shifts trust from multisig participants to the oracle. As long as the oracle does not engage in malicious behavior, the DLC protocol design can be trusted. Theoretically, DLC can utilize mature and well-established third-party oracles to prevent malicious activities.
http://DLC.link and BitLayer leverage DLC’s unique characteristics to transfer bridge trust to third-party oracles.
BitLayer’s DLC bridge also supports self-built oracle nodes with an added layer of fraud proofs. When a self-built oracle broadcasts an invalid CET, anyone can challenge it.
We will delve into the mechanism of BitLayer’s OP-DLC bridge in a subsequent thread.
OP-DLC Bridge: DLC Channel + Fraud Proofs
Let’s delve into the OP-DLC bridge’s mechanism using a deposit scenario. Imagine Alice deposits 1 BTC to Layer 2 (L2) via the OP-DLC bridge. Following the two-step transaction mechanism, Alice generates a pre-fund transaction as illustrated below:
Step 1: Secure Funds in Taproot
- We begin by transferring 1 BTC to a Taproot address.
- This Taproot address requires both Alice and the BitVM Federation members’ signatures for spending.
- Essentially, the funds are held securely in a joint account.
Step 2: Cooperation or Retrieval
Cooperation: If the BitVM Federation cooperates with Alice’s deposit request:
- Both parties communicate off-chain.
- They generate the formal Fund deposit transaction (initially off-chain).
- All CETs (Contract Execution Transactions) for potential withdrawal scenarios are created and signed.
- Once CETs are verified, the Fund transaction is broadcast to the blockchain.
Non-Cooperation: If the BitVM Federation refuses cooperation:
- Alice can wait for the timelock to expire.
- Upon time lock expiry, she can retrieve her funds from the Taproot address.
Step 3: Proof of Deposit and Token Release
- Alice specifies her L2 receiving address within the Fund transaction’s Witness data.
- After the Fund transaction is on-chain, Alice submits the data to the L2 bridge contract.
- This data serves as proof of her deposit on Bitcoin.
- With this proof, the L2 bridge contract releases tokens to Alice’s specified L2 address.
Unlock BTC by CET
After the Fund transaction is triggered, Alice & BitVM Federation share control of the locked deposit via Taproot. It is important to note that this multi-signature address can only be unlocked by CETs; the BitVM Federation cannot arbitrarily transfer the funds.
CETs constructed in advance handle various Alice withdrawal scenarios. Imagine a 1 BTC deposit with a 0.3 BTC initial withdrawal. The remaining 0.7 BTC goes to the Federation’s public pool, but further withdrawals require the BitVM bridge.
Alternatively, Alice can reuse the 0.7 BTC for a new deposit, treating it like a fresh asset. This repeats the process of fund transaction & CET creation.
Simply said, it allows Alice & BitVM acting as counterparties federation to construct CETs for various scenarios. The oracle then reads Alice’s withdrawal statement on Layer2 to determine which CET to trigger (essentially, wants to withdraw).
The risk here is that the oracle might collude with the BitVM Federation. Imagine Alice requests 0.5 BTC, but the oracle says 0.1 BTC, sending 0.9 BTC to BitVM instead.
How to mitigate oracle collusion:
1) Use a well-designed third-party oracle
2) Make oracle stake & publish Commitments periodically.
Anyone can challenge these Commitments using BitVM’s fraud-proof protocol to slash bad oracles.
Unlike traditional bridges, OP-DLC lets you keep control, preventing funds from being misappropriated by the BitVM Federation.
This channel-like design offers users more autonomy and avoids mixing their funds with others, more resembling a P2P deposit and withdrawal scheme.
Moreover, considering that it still takes some time for the BitVM solution to be implemented, the DLC bridge offers a more reliable bridging model compared to simple multisig solutions.
This approach can also serve as one of two major deposit and withdrawal gateways alongside the BitVM bridge. If one gateway fails, users can use the other, providing a robust fault-tolerance method.
