Discussion on DLC Technical Principles and Optimization Solutions

1. Introduction

The Discrete Logarithm Contract ( DLC ) is a Bitcoin contract execution scheme based on oracles, proposed by Tadge Dryja from MIT in 2018. DLC allows both parties to make conditional payments based on predefined conditions, where participants pre-sign potential outcomes and execute payments when the oracle signs the result. This enables DLC to realize new decentralized financial applications on Bitcoin while ensuring the safety of deposits.

Compared to the Lightning Network, DLC has the following advantages:

• Better privacy protection, contract details are shared only between the participating parties.
• Supports complex and flexible financial contracts, such as derivatives, insurance, etc.
• Reduce counterparty risk, funds locked in a multi-signature contract.
• No need to manage payment channels
• Provide better scalability in complex contracts

However, there are still some issues and risks with DLC:

• Risk of oracle key leakage or loss
• Centralized issues of oracle
• Decentralized oracles cannot perform key derivation
• Oracle Conspiracy Risk
• Fixed denomination change problem

This article will explore the principles of DLC and propose some optimization solutions to address the aforementioned issues.

2. DLC Principle

Taking the example of Alice and Bob signing a betting agreement, the wager is the parity of the hash value of the n+k block. If odd, Alice wins; if even, Bob wins.

Initialization:

• Elliptic curve generator G, order q
• Oracle private key z, public key Z=z·G
• Alice's private key x, public key X = x·G
• Bob's private key y, public key Y = y·G

Funding Transaction: Alice and Bob each lock 1 BTC into a 2-of-2 multisig output.

Contract Execution Transaction: Create two CET for spending capital injection transaction.

Oracle promises: R := k·G S := R - hash(OddNumber,R)·Z S' := R - hash(EvenNumber,R)·Z Broadcast (R,S,S')

Alice and Bob calculate the new public key: PK^Alice := X + S PK^Bob := Y + S'

Settlement: Odd result: s := k - hash(OddNumber,R)·z Even result: s' := k - hash(EvenNumber,R)·z

Withdraw Alice's new private key: sk^Alice := x + s Bob's new private key: sk^Bob := y + s'

3. DLC Optimization Plan

3.1 Key Management

The oracle key management faces the following risks:

1. Lost private key z: Unable to settle, executing refund
2. Leakage of private key z: may be abused to sign any message
3. Leakage or reuse of the random number k: the private key z can be calculated.
4. Lost random number k: corresponding DLC cannot be settled

Suggestion:

• Derive child keys using BIP32
• Use private key and counter hash as random number

3.2 Decentralized Oracle

Implementing decentralized oracles using Schnorr threshold signatures has the following advantages:

• Enhanced security, decentralized key management
• Distributed control, reducing the risk of power concentration
• Improve availability, partial node failures do not affect the overall system.
• Flexible and scalable, with different thresholds that can be set.
• Accountability, signature sharding is verifiable

3.3 Decentralization and Key Management Coupling

Decentralized oracles cannot directly use BIP32 to derive keys. A distributed key derivation method can be employed:

The private key shard z_i and the complete private key z satisfy the Lagrange interpolation relationship: z = Σ(z_i · λ_i)

The interpolation relation is still satisfied after increasing the derived increment ω: z + ω = Σ((z_i + ω) · λ_i)

Each participant can derive a child private key shard z_i + ω.

But the difference between enhanced and non-enhanced BIP32 needs to be considered.

3.4 OP-DLC: Trust Minimization of Oracles

Propose OP-DLC solution:

• Oracle pre-staking builds on-chain OP games
• Any honest participant can initiate a challenge.
• Successfully challenging punishes the evil oracle.
• Can be used in conjunction with the "k-of-n" model

Advantages:

• Oracle nodes supervise each other
• Only one honest participant is needed, fault tolerance rate 99%
• Address the risk of oracle collusion

3.5 OP-DLC + BitVM Dual Bridge

Combine OP-DLC with BitVM:

• Use BitVM to solve the change problem
• Provide multiple deposit and withdrawal channels
• The BitVM Alliance acts as an oracle, achieving minimum trust.
• Improve capital utilization

4. Conclusion

DLC combines technologies such as Taproot and BitVM to enable more complex off-chain contract verification and settlement. The OP challenge mechanism allows for minimal trust in oracles, providing new possibilities for the development of DLC.