Author: mutourend & lynndell, Bitlayer Research Group
Introduction
Discreet Log Contract (DLC) is a contract execution framework based on oracles proposed by Tadge Dryja from the Massachusetts Institute of Technology in 2018. DLC allows two parties to make conditional payments based on predefined conditions. Both parties agree on possible outcomes in advance and pre-sign, using these signatures to execute payments when the oracle signs the result. Therefore, DLC ensures the security of Bitcoin deposits while enabling new decentralized financial applications.
Previous Article
“DLC Principles Analysis and Optimization Considerations” summarized the advantages of DLC in privacy protection, complex contracts, and low asset risk. It also analyzed issues such as key risks, decentralized trust risks, and collusion risks in DLC, and introduced decentralized oracles, threshold signatures, and optimistic challenge mechanisms to address various challenges. With the involvement of oracles, Alice, and Bob in DLC, the exhaustive collusion attack between different participants is relatively complex, leading to the complexity of preventive strategies. Complex defense strategies are not perfect, do not adhere to simplicity, lack elegance.
In Bitcoin, any action by any participant needs to be implemented through UTXO. Therefore, ensuring the correctness of UTXO through a consensus mechanism can resist any attack. Similarly, in DLC, any action by any participant needs to be implemented through CET (Contract Execution Transaction). Therefore, using the optimistic challenge mechanism to ensure the correctness of CET can resist any attack. Specifically, after pledging 2BTC by the oracle, CET can be signed. An optimistic challenge mechanism is added to CET. If CET is not challenged or successfully responds to the challenge, CET is correct, the settlement can be completed, the oracle releases the pledge, and receives a fee. If the oracle attempts malice, anyone can successfully challenge, the CET will not be settled, the oracle loses the pledge, and the oracle cannot sign the same CET again. Adhering to simplicity, it possesses elegance.
DLC Principles
Alice and Bob sign a betting agreement: betting on whether the hash value of the ξth block is odd or even. If it is odd, Alice wins the game and can withdraw assets; if it is even, Bob wins the game and can withdraw assets. Using DLC, the correct winning party wins all assets by constructing condition signatures based on the information of the ξth block passed by the oracle.
The elliptic curve generator is G, with an order of q. The oracle, Alice, and Bob each have their key pairs (z, Z), (x, X), (y, Y).
Funding transaction (on-chain): Alice and Bob together create a funding transaction, each locking 10BTC in a 2-of-2 multisig output (one public key X belongs to Alice, one public key Y belongs to Bob).
Building CET (off-chain): Alice and Bob create CET1 and CET2 to spend the funding transaction.
The oracle calculates commitment R = k · G, then calculates S and S’
S := R – hash(OddNumber, R) · Z
S’ := R – hash(EvenNumber, R) · Z
Then the new public keys for Alice and Bob are as follows:
PK^{Alice} := X + S
PK^{Bob} := Y + S’.
Settlement (off-chain to on-chain): When the ξth block is successfully generated, the oracle signs CET1 or CET2 corresponding to the hash of that block.
If the hash is odd, the oracle signs s as follows
s := k – hash(OddNumber, R) z
Broadcast CET1.
If the hash is even, the oracle signs s’
s’ := k – hash(EvenNumber, R) z
Broadcast CET2.
Withdrawal (on-chain): If the oracle broadcasts CET1, Alice can calculate the new private key and spend the locked 20BTC
sk^{Alice} = x + s
If the oracle broadcasts CET2, Bob can calculate the new private key and spend the locked 20BTC
sk^{Bob} = y + s’
Bitlayer Research Group found that in the above process, any action needs to be implemented through CET. Therefore, only using the optimistic challenge mechanism to ensure the correctness of CET can resist any attack. Incorrect CET will be challenged, not executed, while correct CET will be executed. In addition, the oracle needs to pay the price for malicious behavior.
If the challenge program is f(t), the CET should be constructed as follows
s = k – hash(f(t), R) z.
Assuming, in reality, the hash value of the ξth block is odd, i.e., f(ξ) = OddNumber, the oracle should sign CET1 as follows
s := k – hash(OddNumber, R) z.
However, if the oracle acts maliciously and changes the function value to Even, signing CET2:
s’ := k – hash(EvenNumber, R) z.
Therefore, any user can thwart this malicious behavior by showing f(ξ) ≠ OddNumber.
OP-DLC 2
OP-DLC includes the following 5 provisions:
The oracle is composed of a consortium with n participants, and any member can sign CET. The oracle can only release signatures and earn fees after pledging 2BTC. If a member acts maliciously, they lose the pledge. Other members can continue to sign CET to ensure users can withdraw funds. Alice and Bob can also become oracles, truly trusting only themselves, minimizing trust.
If the oracle acts maliciously, modifying the result, it will inevitably lead to situations where f1(ξ) ≠ z1, f2(z1) ≠ z2. Therefore, any participant can challenge, i.e., initiate Disprove-CET1 transactions.
If the oracle honestly signs CET, no participant can initiate effective Disprove transactions. After 1 week, CET can be settled correctly. In addition, the oracle receives a 0.05BTC reward as compensation for the 2BTC pledge and fees for honest CET signing.
Any participant can challenge Oracle_sign:
If Oracle_sign is honest, no Disprove-CET1 transactions can be initiated, and CET settlement is executed after 1 week. Additionally, the oracle’s pledge is unlocked, and they receive fees.
If Oracle_sign is dishonest, i.e., anyone successfully initiates a Disprove-CET1 transaction, spending the connector A output, then that signature of the oracle is invalid, losing the 2BTC pledge, and the oracle cannot sign the same result of the DLC contract in the future as Settle-CET1 relying on that connector A output would be permanently invalidated.
Challenges in OP-DLC are Permissionless, meaning any participant can supervise the correct execution of contracts within OP-DLC. This minimizes trust in oracles. Compared to the Lightning Network, Alice and Bob can also be offline. Since only honest oracle signatures will settle CET, and malicious oracles will be challenged and punished by anyone.
Advantages:
High control over assets, trust only oneself: Alice and Bob can both become oracles and sign CET. The optimistic challenge mechanism thwarts incorrect CET, preventing malice. Therefore, OP-DLC allows users to trust only themselves. In BitVM, users need to be Operators and must participate in all subsequent deposits to trust only themselves. If a user as an Operator only participates in a single UTXO deposit in BitVM, that UTXO can be legitimately reimbursed by any other (n-1) Operators, requiring the user to still trust other Operators for future withdrawals. The reimbursement authority of BitVM Operators is locked in individual deposit UTXOs.
High capital utilization: If users trust only themselves, the required amount of capital is different. In OP-DLC, users rely on themselves for withdrawals, without needing to provide an equal amount of funds as collateral; whereas in BitVM, users need to provide an equal amount of collateral, then reimburse. This brings greater financial pressure.
The oracle that can sign needs to be determined at the time of OP-DLC deposit, but the user can also become an oracle and sign for themselves.
Disadvantages:
Withdrawal time takes 1 week: Essentially, the capital time costs of OP-DLC and BitVM are present and equal. Withdrawals in OP-DLC require a challenge period to access funds; if BitVM relies on users providing collateral, an equal amount of collateral funds also need to pass a challenge period to be successfully reimbursed. If BitVM depends on other Operators for quick withdrawals, it means that the capital time cost of providing Operators with an equal amount of funds serves as a fee.
The number of signatures that need to be pre-signed grows rapidly and is linearly related to the number of CETs. More CETs are needed to enumerate all withdrawal results.
Conclusion
OP-DLC introduces the optimistic challenge mechanism into CET, ensuring incorrect CETs are not settled, and malicious oracles lose their pledges; ensuring correct CETs are executed, unlocking the oracle’s pledge, and receiving fees. This method can resist any attack, possessing simplicity and elegance.
References
Specification for Discreet Log Contracts
Discreet Log Contracts
DLC Principles Analysis and Optimization Considerations
Optimistic Rollup
BitVM 2: Permissionless Verification on Bitcoin.
