作者: mutourend & lynndell, Bitlayer Research Group
1 Introduction
Discreet Log Contract (DLC) is an oracle-based contract execution framework proposed by Tadge Dryja of MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. Both parties predetermine the possible results and pre-sign them, and use these pre-signatures to execute the payment when the oracle signs the results. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.
The previous article "Analysis of DLC Principles and Optimization Thinking" summarizes the advantages of DLC in privacy protection, complex contracts, and low asset risks. It also analyzes the key risks, decentralized trust risks, and collusion risks of DLC, and introduces decentralized oracles, threshold signatures, and optimistic challenge mechanisms into DLC to solve the various problems it should face. Since DLC involves three participants, namely, oracles, Alice, and Bob, the exhaustive enumeration of collusion attacks between different participants is relatively complex, resulting in relatively complex prevention strategies. Complex defense strategies are not perfect, do not conform to the principle of simplicity, and lack the beauty of simplicity.
In Bitcoin, any action of any participant needs to be implemented through UTXO. Therefore, using a consensus mechanism to ensure that UTXO is correct can resist any attack. Similarly, in DLC, any action of any participant needs to be implemented through CET (Contract Execution Transaction). Therefore, using an optimistic challenge mechanism to ensure that CET is correct can resist any attack. Specifically, after the oracle pledges 2BTC, it can sign CET. Add an optimistic challenge mechanism to CET. If CET is not challenged, or successfully responds to the challenge, CET is correct and settlement can be completed. The oracle releases the pledge and obtains the handling fee; if Oracle attempts to do evil, anyone can successfully challenge it, the CET will not be settled, the oracle loses the pledge, and the oracle can no longer sign the same CET. It conforms to the principle of simplicity and has the beauty of simplicity.
2.DLC Principle
Alice and Bob sign a betting agreement: betting on whether the hash value of the ξth block is an odd number or an even number. If it is an odd number, Alice wins the game and can withdraw the assets; if it is an even number, Bob wins the game and can withdraw the assets. Using DLC, the ξth block information is transmitted through the oracle to construct a conditional signature so that the correct winner wins all assets.
The generator of the elliptic curve is G, and the order is q. The key pairs of the oracle, Alice, and Bob are (z, Z), (x, X), (y, Y) respectively.
Funding Transaction (On-Chain): Alice and Bob create a funding transaction together, each locking 10 BTC in a 2-of-2 multi-signature output (one public key X belongs to Alice, and one public key Y belongs to Bob).
Building CET (off-chain): Alice and Bob create CET1 and CET2 to spend funding transactions.
The oracle calculates the commitment R = k · G, and then calculates S and S'
S := R - hash(OddNumber, R) · Z
S' := R - hash(EvenNumber, R) · Z
Then the new public keys of Alice and Bob are as follows:
PK^{Alice} := X + S
PK^{Bob} := Y + S'.
Settlement (off-chain -> on-chain): When the ξth block is successfully generated, the oracle signs the corresponding CET1 or CET2 based on the hash value of the 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
Broadcasts CET2.
Withdraw (on-chain): If the oracle broadcasts CET1, Alice can calculate the new private key and spend the locked 20 BTC
sk^{Alice} = x + s
If the oracle broadcasts CET2, Bob can calculate the new private key and spend the locked 20 BTC
sk^{Bob} = y + s'
The Bitlayer research team found that in the above process, any behavior needs to be implemented through CET. Therefore, it is only necessary to use an optimistic challenge mechanism to ensure that CET is correct, and it can resist any attack. Incorrect CET will be challenged and not executed, while correct CET will be executed. In addition, the oracle only needs to pay the price for malicious behavior.
When the challenge program is f(t), CET should be constructed as follows
s = k - hash(f(t), R) z.
Assume that the hash value of the ξth block is an odd number, that is, f(ξ) = OddNumber, and the oracle should sign CET1
s := k - hash(OddNumber, R) z.
However, the oracle acted maliciously, changed the function value to Even, and signed CET2:
s' := k - hash(EvenNumber, R) z.
Therefore, any user can thwart the malicious behavior based on f(ξ) ≠ OddNumber.
3.OP-DLC 2
OP-DLC includes the following five provisions:
The oracle is composed of a coalition with n participants, and any member can sign CET. Only by staking 2BTC can the oracle issue a signature and earn a handling fee. If a member does something malicious, the stake will be lost. Other members can continue to sign CET to ensure that users can withdraw funds. Alice and Bob can also become oracles, and they can truly trust only themselves and minimize trust.
If the oracle acts maliciously and modifies the result, it will inevitably lead to the situation where f1(ξ) ≠ z1, f2(z1) ≠ z2. Therefore, any participant can initiate a challenge, that is, conduct a Disprove-CET1 transaction.
If the oracle signs CET honestly, no participant can initiate a valid Disprove transaction. After 1 week, CET can be settled correctly. In addition, the oracle receives a 0.05 BTC reward as the 1-week capital occupation of the 2 BTC pledged and the handling fee for honestly signing CET.
Any participant can challenge Oracle_sign:
If Oracle_sign is honest, the Disprove-CET1 transaction cannot be initiated, and CET settlement will be executed after 1 week. In addition, the oracle stake is unlocked and the handling fee is obtained;
If Oracle_sign is dishonest, that is, anyone successfully initiates a Disprove-CET1 transaction and successfully spends the connector A output, the oracle's signature will be invalid, and the staked 2BTC will be lost. In the future, the oracle will no longer be able to initiate a signature with the same result for the DLC contract, because the Settle-CET1 that relies on the connector A output will be permanently invalid.
The challenge in OP-DLC is permissionless, that is, any participant can monitor whether the contract in OP-DLC is executed correctly. Therefore, the trust in the oracle is minimized. Compared with the Lightning Network, Alice and Bob can also be offline. Because the oracle will only settle CET with honest signatures, and the oracle that does evil will be challenged and punished by anyone.
advantage:
High control over assets, trust only yourself: Alice and Bob can both become oracles and sign CET. The optimistic challenge mechanism will defeat the wrong CET, so it cannot do evil. Therefore, OP-DLC allows users to trust only themselves. In BitVM, users need to act as operators and must participate in all subsequent deposits to trust only themselves. If a user only participates in a single UTXO deposit in BitVM as an operator, and the UTXO can be legally reimbursed by any other (n-1) operators, the user's future withdrawals will still need to trust other operators to advance the payment. The reimbursement authority of the BitVM Operator is locked on each single deposit UTXO.
High capital utilization: If users only trust themselves, the amount of capital required is different. In OP-DLC, users rely on themselves to withdraw funds and do not need to use an equal amount of funds to advance; while in BitVM, users need to advance an equal amount of funds and then be reimbursed. This brings greater financial pressure.
The oracle that can sign must be determined when the OP-DLC is deposited, but the user himself can also become an oracle and sign for himself.
shortcoming:
It takes 1 week to withdraw funds: In essence, the time cost of funds for OP-DLC and BitVM are both existent and equal. OP-DLC withdrawals require a challenge period before funds can be obtained; if BitVM relies on users to advance funds themselves, the same amount of advance funds also need to go through a challenge period before they can be successfully reimbursed. If BitVM relies on other operators to advance funds for quick withdrawals, it means that the operator must be paid the same amount of funds as a handling fee.
The number of signatures that need to be pre-signed increases rapidly, and is linearly related to the number of CETs. As many CETs as possible are needed to enumerate all withdrawal results.
4 Conclusion
OP-DLC introduces the optimistic challenge mechanism into CET, ensuring that the wrong CET is not settled and the corresponding malicious oracle loses the stake; ensuring that the correct CET is executed, and the oracle stake is unlocked and the handling fee is obtained. This method can resist any attack and has a simple beauty.
references
Specification for Discreet Log Contracts
Discreet Log Contracts
Analysis of DLC principles and its optimization considerations
Optimistic Rollup
BitVM 2: Permissionless Verification on Bitcoin
