Exploring the Security and Potential of DLCs (Discreet Log Contracts)

exploring-security-and-potential-of-dlcs

This article is co-authored by ScaleBit, DLC.Link, and Bison Labs.

Discreet Log Contracts (DLCs) have been around since 2020, gaining traction over the past few years. The concept has recently been reignited as multiple projects explore Bitcoin Layer-2 solutions. Developers envision DLCs’ potential in Bitcoin lending, cross-chain transactions, and more complex custom contracts. Given these expectations, most people refer to DLCs as Bitcoin smart contracts. However, the Bitcoin network cannot handle complex logic verification. Therefore, DLCs should be understood as an agreement with predictable outcomes and a finite state space. Overhyping DLC’s capabilities and applying them in inappropriate scenarios may introduce unpredictable risks to projects.

In this article, we provide an overview of the DLC technology from a security perspective, enumerate its current common use cases, and analyze potential security issues that may arise.

The Basics of DLCs

DLCs are specifications that allow Bitcoin scripts to determine how the final scripts should be unlocked based on data inside the Bitcoin network (such as timestamps and hash values) or from an external oracle.

Example 1: Bitcoin Price Bet

Alice and Bob agree to a bet on Bitcoin’s price movement. They set the conditions that if Bitcoin’s price exceeds \$65,000 within the next two weeks, Bob will pay Alice \$100. Conversely, if the price falls below \$65,000, Alice will pay Bob \$100. Instead of involving a third party to hold their funds, they use a DLC to enter into the agreement, allowing them to manage the bet directly between themselves with their funds. The agreement can be divided into three steps:

Step 1: Initial Contract
First, Alice and Bob will jointly create a 2-of-2 multi-sig address A and fund it with \$100 each.

Step 2: Contract Execution Transactions
Next, Alice and Bob, along with an oracle/referee, construct two transactions using the funds in the multi-sig address, according to the possible outcomes. These two transactions are called Contract Execution Transactions (CETs). Both transactions require unlocking with a 3-of-3 multisig, where both parties to the transaction have provided two signatures, and the third signature will be provided by the oracle based on the final result.

Step 3: Reveal
After obtaining the result, the oracle will reveal the signature of one of the transactions, allowing Alice and Bob to execute the transaction according to the result.

This simple example illustrates the essence of a DLC: Because each outcome corresponds to a separate transaction, a DLC cannot handle overly complex transactions or allow too many participants to join. These characteristics determine its relatively limited functionality.

Example 2: Timed Automatic Unlock Contract

Step 1: Initial Contract Creation
First, Alice creates a smart contract and deposits a certain amount of funds into it. This contract includes a timer function, set to automatically unlock the funds after a specified future time point.

Step 2: Optional Early Unlock Mechanism
Bob does not participate directly in the deposit of funds but is authorized to unlock these funds early under specific conditions. These conditions could be a predetermined event such as a request from Alice or certain criteria met as judged by the contract’s internal logic.

Step 3: Fund Unlock
If Bob does not exercise the early unlock function under the established conditions, the contract’s timer will automatically execute when the predetermined time is reached, returning the funds to Alice. If Bob triggers the early unlock mechanism and meets the conditions set by the contract, the funds can be released to Alice earlier or handled according to other stipulations in the contract.

In the next section, we will discuss some scenarios and projects currently using DLCs.

The DLC Bridge

The most well-known and typical implementation of the DLC concept is managing cross-chain assets. Projects, such as DLC.Link and Bison Lab, are ambitious in their aspirations for DLCs, aiming to leverage it to create a superior cross-chain value transfer method compared to traditional bridges. Traditional cross-chain solutions require users to transfer funds to a specific address, which is almost entirely controlled by the project team. Despite increasing the credibility of such solutions through multi-signature and decentralized networks, they still cannot avoid the risk of collective malfeasance or non-responsiveness by wallet owners, leading to asset loss for participants.

DLCs offer a different approach to cross-chain transactions. Simply put, DLC must also be executed through a specific address, similar to a cross-chain bridge. However, the difference lies in the fact that the controller of the DLC is an oracle, not any participant of the assets. This is why many claim that DLCs can achieve trustless, decentralized asset cross-chain transactions. However, this assertion sounds somewhat peculiar because from the previous description, DLCs seem not much different from a multi-signature account. To understand this better, let’s consider a simple example: suppose Alice and Bob are betting on the weather outside the room, but since the room has no windows, they can only ask a third person, Charlie to referee their bet. Unfortunately, Charlie is actually Alice’s friend, so Bob must be very careful when asking.

Bob asks Charlie, “Alice and I are having a bet. If it rains, Alice wins, and if it’s sunny, I win. Please tell me the exact weather.” The result is obvious: regardless of the actual weather outside, Charlie might collude with Alice to influence the outcome.
Bob asks Charlie, “Please tell me what the weather is outside.” If Charlie doesn’t know anything about the bet, he will likely describe the actual situation.

Through this example, we can clearly understand the difference between oracles and typical asset participants. Oracles are responsible for providing accurate descriptions but do not necessarily understand the potential outcomes of these descriptions. While implementations may vary between projects, they generally follow a similar approach. In the case of DLCs bridges, when any participant adds assets, such as 1 BTC to the DLC, they receive 1 dlcBTC. When participants attempt to unlock their BTC, the oracle determines if they can provide assets equal to or greater than 1 dlcBTC. If they can, the oracle signs, allowing the participant to unlock their BTC. Compared to project parties, oracles are relatively more trustworthy. Firstly, because DLC addresses are created jointly by users and oracles, the oracle cannot steal these assets. Secondly, oracles are indifferent to specific actions and focus solely on real information, reducing potential conflicts of interest. Therefore, using DLCs to construct a novel cross-chain bridge model indeed offers unique advantages.

The Security Concern

Indeed, ideally, using DLCs could make the cross-chain process safer and give users more autonomy over their cross-chain assets. However, this is only in an ideal scenario. Given that current solutions based on DLCs are not yet very mature, we believe it is necessary to highlight some security concerns. We consider the most noteworthy aspects to be the reliability of oracles, the introduction of hash time locks, and the on-chain/off-chain deployment issue.

1. Reliability of Oracles

This issue can be considered the most important and challenging aspect of DLCs applications. As mentioned earlier, a perfect oracle should have zero knowledge of the state of the DLC and only respond to queries for information. However, in reality, since Bitcoin is completely transparent, oracles can actively gather information about the DLC and potentially collude with other participants. Meanwhile, oracles need to provide public keys for the DLC script, further increasing the possibility of oracle interference with the normal functioning of the DLC.

There are two different levels of this issue. The first level is relatively easier to address, namely that oracles should not participate in the creation process of the DLC. Specifically, participants should request oracles to generate a series of public keys, referred to as a public key box. Each public key would have a pre-negotiated rule, and if the conditions are met, the oracle would sign it. This way, participants can directly use these public keys to generate DLC without the direct involvement of oracles in the DLC creation process.

The second level is relatively more difficult to solve, namely that oracles should not be able to access a DLC information. This is very difficult to achieve but poses significant potential risks. There is one imperfect way to achieve this. The first method is to use Schnorr signatures, requiring multiple oracles to sign the same information. Because actively querying the DLC script and providing incorrect information is equivalent to being a malicious node, increasing the number of nodes in the network and using threshold signatures can greatly reduce the likelihood of success for malicious nodes. Before more reliable solutions emerge, this paper believes that the security of multi-signature oracles is essential.

2. Introduction of Hash Time Locks

Hash time locks (HTLCs) play a crucial role in ensuring the security and trustlessness of cross-chain transactions. These cryptographic constructs enable conditional payments between parties, where funds are released only when certain conditions, such as a pre-image of a hash, are met within a specified time frame. The use of traditional hash time locks to manage DLC scripts in lending-related DLC scenarios encourages users to engage in fast transactions. However, by incorporating HTLCs into DLC protocols, it adds an extra layer of security by enforcing time-bound commitments and preventing participants from unfairly locking or accessing funds. As mentioned earlier, oracles provide a series of public keys as conditions for unlocking DLC. It’s important to note that since each public key corresponds to specific information (such as the rise or fall of Bitcoin), the same public key may be used in multiple DLCs. Therefore, when setting hash time locks, it’s crucial not to use content related to oracle’s public keys for construction.

Furthermore, since DLCs often involve conditional judgments, careful attention is needed to ensure that DLCs do not unfairly impact the unlocking process for both parties. For example, while Party A may be able to unlock assets, Party B may face restrictions due to certain DLC limitations, leading to unjust outcomes. Therefore, thorough consideration of these factors is essential to mitigate potential security vulnerabilities in lending-related DLC transactions.

3. User’s Involvement

User involvement in DLCs introduces a key security feature by making the original asset holders trusted, essential participants in any transfer of assets. By requiring the asset holder’s signature for any movement of funds, this approach ensures that assets can only be transferred with the user’s explicit authorization, significantly enhancing security.

This method leverages the concept of user-controlled security, where the user is the final authority in validating and approving transactions. In practice, this means that any transaction attempt that lacks the direct consent of the user, evidenced through their unique digital signature, is automatically rejected. This reduces the risk of unauthorized access and asset transfer, as malicious actors would need to compromise the user’s private keys to initiate a transaction, a significantly more challenging feat.

Furthermore, incorporating user signatures into the transaction process not only mitigates risks related to external threats but also enhances the accountability of all parties involved in the DLC. It provides a transparent mechanism for tracking asset movements, ensuring that each step of the transaction is recorded and verifiable.

By implementing such a security measure, DLC protocols can foster a higher degree of trust and reliability in cross-chain transactions, thereby encouraging broader adoption and utilization of these technologies in various financial sectors.

Conclusion

Although DLCs have been around for some time and have become more flexible and powerful with the Taproot upgrade, their security has not undergone extensive testing. We are pleased to see DLC technology regain attention and spark a technical frenzy, but the potential security issues cannot be ignored. We will continue to monitor the development of DLCs and provide ongoing insights and analysis.