Bitlayer Research: OP-DLC 2: Simple is the Way

Author: 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 possible outcomes and pre-sign them, and use these pre-signatures to execute payments when the oracle signs the outcome. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.

The previous article 《Analysis of DLC Principles and Its 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 behavior 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 behavior of any participant needs to be implemented through CET (Contract Execution Transaction). Therefore, using the 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 can complete the settlement. 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 bet agreement: bet on whether the hash value of the ξth block is odd or even. If it is an odd number, Alice wins the game and can withdraw assets; if it is an even number, Bob wins the game and can withdraw assets. Using DLC, the ξth block information is passed through the oracle to construct a conditional signature so that the correct winner wins all assets.

The elliptic curve generator is G and the order is q. The oracle, Alice and Bob’s key pairs are (z, Z), (x, X), (y, Y) respectively.

Funding transaction (on-chain): Alice and Bob create a funding transaction together, each locking 10BTC in a 2-of-2 multi-signature output (a public key X belongs to Alice and a public key Y belongs to Bob).

Construct 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 corresponding to 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

and broadcasts CET1.

If the hash is even, the oracle signs s'

s' := k - hash(EvenNumber, R) z

and broadcasts CET2.

Withdrawal (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, which can resist any attack. The wrong CET will be challenged and not executed, while the 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 actual situation is that the hash value of the ξ-th block is an odd number odd, that is, f(ξ) = OddNumber, the oracle should sign CET1

s := k - hash(OddNumber, R) z.

However, the oracle acted maliciously, modified the function value to Even, and signed CET2:

s' := k - hash(EvenNumber, R) z.

Therefore, any user can thwart this malicious behavior based on f(ξ) ≠ OddNumber.

3.OP-DLC 2

OP-DLC includes the following 5 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 evil, the pledge 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 can truly trust only themselves and minimize trust.

• If the oracle does evil 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.05BTC reward as the 1-week capital occupation of its pledged 2BTC 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 signature of the oracle is invalid, and the 2BTC staked is lost. In the future, the oracle cannot initiate the same signature for the DLC contract again, 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 supervise whether the contract in OP-DLC is correctly executed. Therefore, the trust in the oracle is minimized. Compared with the Lightning Network, Alice and Bob can also be offline. Because the oracle will settle CET only if it signs honestly, and the oracle that does evil will be challenged and punished by anyone.

Advantages:

• High control over assets, only trust yourself: Alice and Bob can both become oracles and sign CET. The optimistic challenge mechanism will thwart the wrong CET, so it is impossible to do evil. Therefore, OP-DLC allows users to only trust themselves. In BitVM, users need to act as Operators and must participate in all subsequent deposits in order to only trust themselves. If a user, as an Operator, only participates in a single UTXO deposit in BitVM, and the UTXO can be legally reimbursed by any other (n-1) Operators, then the user's future withdrawals will still need to trust other Operators to advance payment. The reimbursement authority of the BitVM Operator is locked on each single deposit UTXO.

• High fund utilization: If the user only trusts himself, the amount of funds required is different. In OP-DLC, users rely on themselves to withdraw funds and do not need to advance the same amount of funds; while in BitVM, users need to advance the same amount of funds and then reimburse. This brings greater financial pressure.

• The oracle that can sign must be determined when the OP-DLC is deposited, but the user can also become an oracle and sign for himself.

Disadvantages:

• Withdrawal time takes 1 week: In essence, the funding time cost of OP-DLC and BitVM exists and is equal. OP-DLC withdrawals require a challenge period before the funds can be obtained; if BitVM relies on users to advance their own funds, 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 fast withdrawals, it means that the funding time cost of the same amount of funds must be paid to the Operator 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 to ensure that the wrong CET is not settled and the corresponding malicious oracle loses the stake; ensures 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

1. Specification for Discreet Log Contracts

2. Discreet Log Contracts

3. Analysis of DLC Principles and Its Optimization Thinking

4. Optimistic Rollup

5. BitVM 2: Permissionless Verification on Bitcoin