Analysis of the OP-DLC withdrawal bridge proposed by Bitlayer for the shortcomings of the bitVM bridge

Authors: @Nickqiaoo & @faustliu1997

In the recent tweet thread, we briefly introduced BitVM2, an optimistic withdrawal bridge solution based on BitVM

https://x.com/eternal1997L/status/1789275685145723295

This solution is based on the "advance payment-reimbursement" model, allowing the Operator to withdraw funds for users from the BitVM bridge, and then the Operator applies for reimbursement from the BitVM bridge. If there is a false reimbursement application, anyone can challenge it through fraud proof.

However, the implementation of the BitVM bridge is difficult (difficult to achieve in the short term), and there are issues with liveliness/availability, and it cannot meet the transparency requirements for funds: the BitVM bridge will uniformly collect funds from depositors, to some extent, it is a pool of mixed funds.

To address the liveliness issues of the BitVM bridge and to provide a clean fund entry and exit channel for people with specific needs, the BitLayer team has additionally added a cross-chain bridge solution called OP-DLC. In addition to the optimistic bridge of BitVM2, it adopts a DLC bridge similar to http://DLC.link, providing users with two entry and exit points for the BitVM bridge and OP-DLC bridge, thereby reducing dependence on the BitVM bridge and even the BitVM alliance.

DLC: Discreet Log Contracts

DLC (Discreet Log Contracts) is a technology proposed by MIT's Digital Currency Initiative, which was originally used to implement a lightweight smart contract on Bitcoin, without the need to put the content of the contract on the chain. It can achieve privacy-protecting smart contract functionality on the Bitcoin chain through off-chain interactive communication and pre-signing methods. Below, we illustrate the working principle of DLC through a sports betting case.

Suppose Alice and Bob want to bet on the outcome of the Real Madrid and Barcelona match to be held in 3 days, with each of them contributing 1 BTC. If Real Madrid wins, Alice can receive 1.5 BTC, and Bob can only get back 0.5 BTC, which is equivalent to Alice earning 0.5 BTC and Bob losing 0.5 BTC; if Barcelona wins, Alice can only get back 0.5 BTC, while Bob can take 1.5 BTC. In the event of a draw, each of them can retrieve 1 BTC.

If we want to make the above betting process trustless, we need to find a way to prevent either party from cheating. Using a simple 2/2 or 2/3 multi-signature is obviously not enough to achieve trustlessness. DLC provides its own solution to this point (which depends on a third-party oracle). Its entire workflow can be roughly divided into four parts.

Taking the example of Alice and Bob mentioned earlier, first, both parties create a fund transaction off-chain, which locks each other's 1 BTC in a 2/2 multi-signature address. If this fund transaction takes effect, the 2 BTC in the multi-signature address will require authorization from both parties to be spent.

Of course, this fund transaction is not broadcasted on the chain for the time being, and it is only kept locally in the clients of Alice and Bob. They both know the consequences if this transaction takes effect. At this point, both parties are only engaging in theoretical deduction and then reaching a series of agreements based on the deduction results.

In the first stage of DLC creation, what we can be sure of is that both parties will lock their respective 1 BTC in a multi-signature address in the future.

In the second step, both parties continue to deduce possible events and results in the future: for example, when the match result is announced, it could be that Alice wins and Bob loses, Alice loses and Bob wins, a draw, and many other possibilities, which will lead to different distribution results in the aforementioned 2/2 multi-signature address.

Different results require different transaction instructions to be triggered, these "transactions that may be broadcasted on the chain in the future" are called CET, i.e., Contract Execution Transaction. Alice and Bob need to deduce all the CET in advance and generate a set of transaction data containing all CET.

For example, based on the various possible results of the bet between Alice and Bob, Alice creates the following CET:

CET1: Alice can receive 1.5 BTC from the multi-signature address, and Bob can receive 0.5 BTC;

CET2: Alice can receive 0.5 BTC from the multi-signature address, and Bob can receive 1.5 BTC;

CET3: Each party can receive 1 BTC.

Taking CET1 as an example (Alice receives 1.5 BTC, Bob receives 0.5 BTC):

The meaning of this transaction is to transfer the 1.5 BTC in the multi-signature address to a Taproot address triggered jointly by Alice and the oracle's output result, and transfer the additional 0.5 BTC to Bob's address. At this point, the corresponding event is: Real Madrid wins, Alice earns 0.5 BTC, and Bob loses 0.5 BTC.

Of course, in order to spend this 1.5 BTC, Alice must obtain the signature of the "Real Madrid wins" result from the oracle. In other words, only when the oracle outputs the message "Real Madrid wins," can Alice transfer this 1.5 BTC. As for the content of CET2 and CET3, we can infer similarly, and it will not be elaborated here.

It is important to note that CET is essentially a transaction waiting to be broadcasted and take effect on the chain. If Alice broadcasts CET1 prematurely, or still broadcasts CET1 that can only be triggered after "Barcelona wins" in the case of "Real Madrid wins," what will happen?

As mentioned in the previous diagram, when CET1 is broadcasted, the original 2 BTC locked in the multi-signature address will be transferred, 0.5 BTC will be transferred to Bob, and 1.5 BTC will be transferred to a Taproot address. When the oracle outputs "Real Madrid wins," Alice can unlock the BTC locked in the Taproot address. The effect is shown in the following diagram.

At the same time, this Taproot address is subject to a time lock restriction. If Alice cannot successfully withdraw the 1.5 BTC within the time lock period, Bob has the right to take away this money.

Therefore, as long as the oracle is honest, Alice cannot take away this 1.5 BTC. When the time lock period expires, Bob can take away this 1.5 BTC. Adding the 0.5 BTC directly transferred to Bob when CET1 is broadcasted, in the end, all the money will belong to Bob.

For Alice, regardless of whether she ultimately wins or loses, the most advantageous approach is to broadcast the correct CET on the chain. Broadcasting an invalid CET will make her lose more money.

In fact, when constructing the aforementioned CET, improvements have been made to the Taproot's schnorr signature, which can be understood as using the oracle's public key + event result to construct independent addresses for different results. Subsequently, only when the oracle publishes the signature corresponding to a certain result, can the BTC locked in the address corresponding to that result be spent.

Of course, there is an additional possibility here. If Alice knows that she has lost, she simply does not broadcast the CET1 she constructed, what should be done at this point? This is easily resolved because Bob can construct a custom CET for the event "Alice loses, Bob wins," and the effect achieved by this CET is basically the same as the CET constructed by Alice, with only minor differences in specific details, but the result is the same.

The above describes the most critical process of constructing CET. The third step of DLC is for both Alice and Bob to communicate, check the CET transactions constructed by the other party, and with their own signatures for that CET. After confirming that there are no errors, they can trust each other, each contribute 1 BTC, lock it in the 2/2 multi-signature address mentioned earlier, and then wait for a CET to be broadcasted on the chain to trigger the subsequent process.

Finally, after the oracle publishes the result and obtains the signature for the result from the oracle, either party can broadcast the correct CET, causing the 2 BTC locked in the multi-signature address to be redistributed. If the losing party broadcasts the incorrect CET first, they will lose all their money. If they broadcast the correct CET, the losing party can still retrieve 0.5 BTC.

Some may ask, what is the difference between DLC and a regular 2/3 multi-signature? First, under a 2/3 multi-signature, any two parties can conspire to steal all the assets, while DLC restricts all possible scenarios between the opposing parties by constructing a set of CET in advance, even if the oracle participates in the conspiracy, the resulting loss is often limited.

Next, multi-signature requires all parties to sign specific transactions to be broadcasted on the chain. In the setting of DLC, the oracle only needs to sign the results of specific events, without needing to know the content of CET/transactions to be broadcasted on the chain, or even knowing that there are two individuals, Alice and Bob. It only needs to interact with users like a regular oracle.

We can consider that DLC essentially transforms trust in the multi-signature participants into trust in the oracle. As long as the oracle does not engage in malicious behavior, the protocol design of DLC can be trusted enough. In theory, DLC can use a mature and complete third-party oracle to avoid malicious behavior. DLC.link and BitLayer utilize this feature of DLC to shift the trust issue of the bridge to a third-party oracle.

In addition, Bitlayer's DLC bridge also supports self-built oracle nodes, adding a layer of fraud proof. When a self-built oracle broadcasts invalid CET, anyone is allowed to challenge it. We will elaborate on the principles of their OP-DLC bridge below.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。