Original title: "Bitlayer Core Technology: DLC and Its Optimization Considerations"
Written by: lynndell & mutourend, Bitlayer Research Group
1 Introduction
Discreet Log Contract (DLC) is a set of oracle-based contract execution solutions proposed by Tadge Dryja of MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. Each party determines and pre-signs possible outcomes, and uses these pre-signatures to execute the payment when an oracle signs the results. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.
Compared with the Lightning Network, DLC has the following significant advantages:
Privacy: DLC is superior to the Lightning Network in terms of privacy protection. Contract details are only shared between the parties and are not stored on the blockchain. In contrast, Lightning Network transactions are routed through public channels and nodes, and their information is public and transparent;
Complexity and flexibility of financial contracts: DLC can create and execute complex financial contracts such as derivatives, insurance and gambling directly on the Bitcoin network, while the Lightning Network is mainly used for fast small payments and cannot support complex applications;
Reduced counterparty risk: DLC funds are locked in a multi-signature contract and will only be released when the result of a predefined event occurs, reducing the risk of either party not complying with the contract. Although the Lightning Network reduces the need for trust, there is still a certain amount of counterparty risk in channel management and liquidity provision;
No need to manage payment channels: DLC operations do not require the creation or maintenance of payment channels, which is a core component of the Lightning Network. Channel management is complex and resource-intensive;
Scalability for specific use cases: The Lightning Network has improved Bitcoin’s transaction throughput to a certain extent, while DLC provides better scalability for complex contracts on Bitcoin.
Although DLC has great advantages in Bitcoin ecological applications, there are still some risks and problems, such as:
Key risk: The private key of the oracle and the promised random number are at risk of being leaked or lost, resulting in loss of user assets;
Centralized trust risk: The problem of oracle centralization can easily lead to denial of service attacks;
Decentralization makes key derivation impossible: If the oracle is decentralized, the oracle node only has the private key shard. However, the decentralized oracle node cannot directly use BIP32 for key derivation based on the private key shard;
Collusion risk: If the oracle nodes collude with each other or with the participants, the trust problem of the oracle is still not solved. A reliable supervision mechanism is needed to minimize the trust of the oracle;
Fixed denomination change problem: Conditional signatures require a deterministic set of enumerable events to construct transactions before building a contract. Therefore, there is a minimum amount limit for DLC to be used for asset redistribution, resulting in a fixed denomination change problem.
To this end, this article proposes some solutions and optimization ideas to address the risks and problems of DLC and improve the security of the Bitcoin ecosystem.
2.DLC Principle
Alice and Bob sign a betting agreement: betting on whether the hash value of the n+kth block is odd or even. If it is an odd number, Alice wins the game and can withdraw assets within time t; if it is an even number, Bob wins the game and can withdraw assets within time t. Using DLC, the oracle transmits the information of the n+kth block to construct a conditional signature so that the correct winner wins all assets.
Initialization: The elliptic curve generator is G and the order is q.
Key generation: The oracle, Alice, and Bob independently generate their own private and public keys.
The private key of the oracle is z, and the public key is Z, satisfying the relationship Z=z⋅G;
Alice's private key is x, and her public key is X, which satisfies the relationship X=x⋅G;
Bob's private key is y and his public key is Y, which satisfies the relationship Y=y⋅G.
Funding Transaction: Alice and Bob create a funding transaction together, each locking 1 BTC in a 2-of-2 multi-signature output (one public key X belongs to Alice, and one public key Y belongs to Bob).
Contract Execution Transaction: Alice and Bob create two Contract Execution Transactions (CET) to spend the funding transaction.
Oracle Computation Commitment
$R:=k ⋅ G$
Then, calculate S and S'
$S:=R-hash(OddNumber,R) ⋅ Z,$
$S':=R-hash(EvenNumber,R) ⋅ Z$
Broadcast (R, S, S').
Alice and Bob each calculate their corresponding new public keys
$PK^{Alice}:=X+ S,$
$PK^{Bob}:=Y+ S'.$
Settlement: When the n+kth block appears, the oracle generates the corresponding s or s' based on the hash value of the block.
If the hash value of the n+kth block is an odd number, the oracle calculates and broadcasts s
$s:=k-hash(OddNumber,R) ⋅ z$
If the hash value of the n+kth block is an even number, the oracle calculates and broadcasts s'
$s':=k-hash(EvenNumber,R) ⋅ z$
Withdrawal: Either Alice or Bob can withdraw assets based on the s or s' broadcast by the oracle.
If the oracle broadcasts s, Alice can calculate the new private key sk^{Alice} and withdraw the locked 2 BTC
$sk^{Alice}:= x + s.$
If the oracle broadcasts s', Bob can calculate the new private key sk^{Bob} and withdraw the locked 2 BTC
$sk^{Bob}:= y + s'.$
Analysis: Alice's new private key sk^{Alice} and the new public key PK^{Alice} satisfy the discrete logarithmic relationship
$sk^{Alice} ⋅ G= (x+s) ⋅ G=X+S=PK^{Alice}$
In this case, Alice's withdrawal will be successful.
Similarly, the new private key sk^{Bob} calculated by Bob and the new public key PK^{Bob} satisfy the discrete logarithmic relationship
$sk^{Bob} ⋅ G= (y+s') ⋅ G=Y+S'=PK^{Bob}$
In this case, Bob's withdrawal will be successful.
In addition, if the oracle broadcasts s, it is useful for Alice, but not for Bob. Because, Bob cannot use it to calculate the corresponding new private key sk^{Bob}. Similarly, if the oracle broadcasts s', it is useful for Bob, but not for Alice. Because, Alice cannot use it to calculate the corresponding new private key sk^{Alice}.
Finally, the above description omits the time lock. A time lock needs to be added so that one party can calculate a new private key and withdraw the currency within time t. Otherwise, if time t is exceeded, the other party can withdraw the assets using the original private key.
3.DLC Optimization
3.1 Key Management
In the DLC protocol, the oracle's private key and the promised random number are crucial. If the oracle's private key and the promised random number are leaked or lost, it is easy to cause the following four security issues:
(1) The oracle loses the private key z
If the oracle loses its private key, the DLC cannot be settled, resulting in the need to execute the DLC refund contract. Therefore, a refund transaction is set up in the DLC protocol to prevent the oracle from losing its private key.
(2) The oracle leaks the private key z
If the oracle's private key is leaked, all DLCs based on that private key are at risk of fraudulent settlement. An attacker who steals the private key can sign any message they want, achieving full control over all future contract results. In addition, the attacker is not limited to publishing a single signed message, but can also publish conflicting messages, such as signing the hash value of the n+kth block as an odd number and an even number at the same time.
(3) The oracle leaks or reuses the random number k
If the oracle leaks the random number k, then during the settlement phase, regardless of whether the oracle broadcasts s or s', the attacker can calculate the oracle's private key z as follows
$z:=(k-s)/hash(OddNumber, R)$
$z:=(k-s')/hash(EvenNumber, R)$
If the oracle reuses the random number k, then after two settlements, the attacker can solve the equations according to the signature broadcast by the oracle according to one of the following four situations to find the oracle's private key z:
Case 1:
$s_1=k-hash(OddNumber_1, R) ⋅ z$
$s_2=k-hash(OddNumber_2, R) ⋅ z$
Case 2:
$s_1'=k-hash(EvenNumber_1, R) ⋅ z$
$s_2'=k-hash(EvenNumber_2, R) ⋅ z$
Case 3:
$s_1=k-hash(OddNumber_1, R) ⋅ z$
$s_2'=k-hash(EvenNumber_2, R) ⋅ z$
Case 4:
$s_1'=k-hash(EvenNumber_1, R) ⋅ z$
$s_2=k-hash(OddNumber_2, R) ⋅ z$
(4) The oracle loses the random number k
If the oracle loses the random number k, the corresponding DLC cannot be settled and the DLC refund contract needs to be executed.
Therefore, to improve the security of the oracle private key, BIP32 should be used to derive a child key or grandchild key for signing. In addition, to improve the security of the random number, the hash value of the private key and the counter k:=hash(z, counter) should be used as the random number k to prevent the random number from being repeated or lost.
3.2 Decentralized Oracle
In DLC, oracles play a vital role, providing key external data that determines the outcome of the contract. To improve the security of these contracts, decentralized oracles are needed. Unlike centralized oracles, decentralized oracles distribute the responsibility for providing accurate and tamper-proof data to multiple independent nodes, which can reduce the risk of relying on a single point of failure and reduce the possibility of manipulation or targeted attacks. Through decentralized oracles, DLCs can achieve a higher degree of trustlessness and reliability, ensuring that contract execution relies entirely on the objectivity of predetermined conditions.
Schnorr threshold signature can realize decentralized oracle. Schnorr threshold signature has the following advantages:
Enhanced security: By decentralizing key management, threshold signatures reduce the risk of single point failure. Even if the keys of some participants are leaked or attacked, the entire system remains secure as long as it does not exceed the set threshold.
Distributed control: Threshold signatures enable distributed control of key management. No single entity holds all signing authority, thus reducing the risks of excessive concentration of power.
Improved availability: Signing can be completed with the consent of a certain number of oracle nodes, which improves the flexibility and availability of the system. Even if some nodes are unavailable, it will not affect the reliable operation of the overall system.
Flexibility and scalability: The threshold signature protocol can set different thresholds as needed to adapt to various security requirements and scenarios. In addition, it is also suitable for large-scale networks and has good scalability.
Accountability: Each oracle node generates a signature shard for the message based on the private key shard, and other participants can use the corresponding public key shard to verify the correctness of the signature shard to achieve accountability. If correct, the signature shards are accumulated to generate a complete signature.
Therefore, the Schnorr threshold signature protocol has significant advantages in decentralized oracles that improve security, reliability, flexibility, scalability, and accountability.
3.3 Coupling Decentralization and Key Management
In key management technology, the oracle has a complete key z. Based on the complete key z and the increment ω, using BIP32, it can derive a large number of child keys z+{ω }^{(1)} and grandchild keys z+ω ^{(1)}+ω ^{(2)}. For different events, the oracle can use different grandchild private keys z+ω ^{(1)}+ω ^{(2)} to generate the corresponding signature σ for the corresponding event msg.
In the decentralized oracle application scenario, there are n participants, and t+1 participants are required to perform threshold signatures. Among them, t. Each of the n oracle nodes has a private key shard z_i, i=1,...,n. These n private key shards z_i correspond to a complete private key z, but the complete private key z does not appear from beginning to end. Under the premise that the complete private key z does not appear, t+1 oracle nodes use private key shards z_i, i=1,...,t+1 to generate signature shards σ_i' for message msg', and the signature shards σ_i' are merged into a complete signature σ '. The verifier can verify the correctness of the message signature pair (msg',σ ') using the complete public key Z. Since t+1 oracle nodes are required to jointly generate the threshold signature, it has higher security.
However, in the decentralized oracle application scenario, the complete private key z does not appear, and BIP32 cannot be used directly for key derivation. In other words, the oracle decentralization technology and key management technology cannot be directly coupled.
The paper Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets proposes a distributed key derivation method in the threshold signature scenario. The core idea of the paper is that according to the Lagrange interpolation polynomial, the private key shard z_i and the complete private key z satisfy the following interpolation relationship
Adding the increment ω to both sides of the above equation, we get the following equation:
This equation shows that the private key shard z_i plus the increment ω still satisfies the interpolation relationship with the complete private key z plus the increment ω. In other words, the child private key shard z_i+ω satisfies the interpolation relationship with the child key z+ω. Therefore, each participant can use the private key shard z_i plus the increment ω to derive the child private key shard z_i+ω to generate the child signature shard, and the corresponding child public key Z+ω ⋅ G can be used to verify the validity.
However, it is necessary to consider enhanced and non-enhanced BIP32. Enhanced BIP32 takes private key, chain code and path as input, calculates SHA512, and outputs increment and sub-chain code. Non-enhanced BIP32 takes public key, chain code and path as input, calculates SHA512, and outputs increment and sub-chain code. In the case of threshold signature, the private key does not exist, so only non-enhanced BIP32 can be used. Or if homomorphic hash function is used, there is enhanced BIP32. However, homomorphic hash function is different from SHA512 and is incompatible with original BIP32.
3.4 OP-DLC: Minimizing Oracle Trust
In DLC, the contract between Alice and Bob is executed based on the result of the oracle signature, so the oracle needs to be trusted to a certain extent. Therefore, the correct behavior of the oracle is a major prerequisite for the operation of DLC.
To de-trust oracles, existing studies have implemented DLC based on the results of n oracles to reduce reliance on a single oracle.
The "n-of-n" model means that n oracles are used to sign the contract, and the contract is executed based on the results of n oracles. This model requires that all n oracles sign online. If an oracle is offline or disagrees with the result, the execution of the DLC contract will be affected. The trust assumption is that all n oracles are honest.
The "k-of-n" model means that n oracles are used to sign a contract, and the contract is executed based on the results of k oracles. If more than k oracles collude, the fair execution of the contract will be affected. In addition, when using the "k-of-n" model, the number of CETs required is C_n^k times that of a single oracle or the "n-of-n" model. The trust assumption is that at least k oracles out of n oracles are honest.
Increasing the number of oracles does not achieve trustlessness of oracles, because when an oracle does something malicious, the party that suffers the loss of the contract has no on-chain channel for complaints.
Therefore, this section proposes OP-DLC, which introduces an optimistic challenge mechanism in DLC. Before participating in the setting of DLC, n oracles need to pledge in advance to build a permisssionless on-chain OP game and promise not to do evil. If any oracle does evil, Alice or Bob or any other honest oracle or other third-party honest observer can initiate a challenge. If the challenger wins the game, the chain punishes the evil oracle and confiscates its deposit. In addition, OP-DLC can also be signed using the "k-of-n" model. The k value can even be 1. Therefore, the trust assumption is reduced to as long as there is an honest participant in the network, an OP challenge can be initiated to punish the evil oracle node.
When settling OP-DLC based on Layer 2 calculation results:
If the oracle uses the wrong result signature, causing Alice's interests to be damaged, Alice can use Layer2 to correctly calculate the result and challenge the permisssionless on-chain OP game that the oracle pledged in advance. Alice wins the game, punishes the malicious oracle, and makes up for the loss;
Similarly, Bob, other honest oracle nodes, and third-party honest observers can all initiate challenges. However, to prevent malicious challenges, the challenger also needs to pledge.
Therefore, OP-DLC enables mutual supervision between oracle nodes, minimizing the trust in the oracle. This mechanism only requires one honest participant, with a fault tolerance rate of 99%, which effectively solves the risk of oracle collusion.
3.5 OP-DLC + BitVM Dual Bridge
When DLC is used for cross-chain bridges, funds need to be allocated when the DLC contract is settled:
It needs to be pre-set through CET. This means that the granularity of DLC fund settlement is limited, such as the Bison network with a granularity of 0.1 BTC. There is a problem: the asset interaction of users in Layer2 should not be limited to the fund granularity of DLC CET.
When Alice wants to settle her Layer 2 assets, she will force user Bob's Layer 2 assets to be settled to Layer 1. Problem: Each Layer 2 user should be able to freely choose to deposit and withdraw funds without being affected by the deposits and withdrawals of other users.
Alice and Bob negotiate the cost. Problem: Both parties must be willing to cooperate.
Therefore, to solve the above problems, this section proposes OP-DLC + BitVM dual bridge. This solution allows users to deposit and withdraw funds through BitVM's permissionless bridge, and also through the OP-DLC mechanism, to achieve arbitrary granularity of change and improve fund liquidity.
In OP-DLC, the oracle is the BitVM Alliance, Alice is an ordinary user, and Bob is the BitVM Alliance. When setting up OP-DLC, in the constructed CET, the output given to user Alice can be spent immediately on Layer1, and a "DLC game in which Alice can participate in the challenge" is constructed in the output given to Bob and a timelock lock period is set. When Alice wants to withdraw money:
If the BitVM Alliance acts as an oracle and signs correctly, Alice can withdraw funds at Layer 1. However, Bob can withdraw funds at Layer 1 after the lock-up period has passed.
If the BitVM alliance, as an oracle, cheats, Alice's interests will be damaged. However, Alice can challenge Bob's UTXO. If the challenge is successful, Bob's amount can be confiscated. Note: One of the other BitVM alliance members can also challenge, but Alice's interests are damaged, so she has the greatest motivation to challenge.
If the BitVM Alliance, as an oracle, cheats, causing damage to Bob's interests, however, an honest member of the BitVM Alliance can challenge the "BitVM Game" and punish the cheating oracle node.
In addition, when user Alice wants to withdraw funds from Layer2, but there is no matching amount of CET preset in the OP-DLC contract, Alice can choose the following methods:
Withdrawal through BitVM is paid by BitVM operator in Layer 1. BitVM bridge assumes that there is an honest participant in the BitVM alliance.
Withdraw funds through a CET in OP-DLC, and the remaining change will be paid by the BitVM operator in Layer1. OP-DLC withdrawal will close the DLC channel, but the remaining funds in the DLC channel will be transferred to the BitVM Layer1 fund pool without forcing other Layer2 users to withdraw funds. OP-DLC bridge trust assumes that there is an honest participant in the channel.
Alice and Bob negotiate the spending without the involvement of an oracle, requiring Bob's cooperation.
Therefore, the OP-DLC + BitVM dual bridge has the following advantages:
Using BitVM solves the DLC channel fund change problem, reduces the number of CET settings, and is not affected by the CET fund granularity;
Combining OP-DLC bridge and BitVM bridge to provide users with multiple deposit and withdrawal channels and arbitrary granularity of change;
Set the BitVM alliance to Bob and the oracle, and minimize the trust in the oracle through the OP mechanism;
Introduce the balance of DLC channel withdrawals into the BitVM bridge fund pool to improve fund utilization.
4 Conclusion
DLC appeared before the activation of Segwit v1 (Taproot), and has realized the integration of DLC channels and lightning networks, and expanded DLC to update and execute continuous contracts in the same DLC channel. With the help of technologies such as Taproot and BitVM, more complex off-chain contract verification and settlement can be achieved in DLC, and the OP challenge mechanism can be combined to minimize the trust of the oracle.
references
Specification for Discreet Log Contracts
Discreet Log Contracts
Scaling DLC Part1: Off-chain Discreet Log Contracts
Scaling DLC Part2: Free option problem with DLC
Scaling DLC Part3: How to avoid free option problem with DLC
Lightning Network
DLC on Lightning
DLC Private Key Management Part 1
DLC Private Key Management Part 2: The Oracle’s private keys
DLC Key Management Pt 3: Oracle Public Key Distribution
BitVM: Compute Anything on Bitcoin
BitVM 2: Permissionless Verification on Bitcoin
BitVM Off-chain Bitcoin Contracts
BIP32 BIP44
Schnorr signature
FROST: Flexible Round-Optimized Schnorr Threshold Signatures
A Survey of ECDSA Threshold Signing
Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets
Segregated Witness
Optimistic Rollup
Taproot
