TeachMeBitcoin

Simplified Taproot DLC structure

From TeachMeBitcoin, the free encyclopedia Reading time: 3 min

16. Discreet Log Contracts (DLC) Script Basics

Overview

Discreet Log Contracts (DLCs), introduced by Tadge Dryja in 2018, are a mechanism for executing oracle-based contracts on Bitcoin without the oracle or any on-chain observer knowing about the contract. They use adaptor signatures and the mathematical properties of Schnorr/ECDSA to keep contracts private while remaining trustless.

Core Concept

A DLC relies on an oracle announcing the outcome of an event using a cryptographic commitment scheme:

Oracle setup:
  1. Oracle publishes: R = k·G  (nonce point for the event)
  2. Oracle publishes: V = v·G  (oracle public key)

For each outcome o_i, the oracle will reveal:
  s_i = k + hash(R || o_i) · v   (scalar announcement)

This reveals a point: s_i·G = R + hash(R || o_i)·V

Adaptor Signatures

DLCs use adaptor signatures to bind contract execution to oracle outcomes:

Adaptor signature: an incomplete signature that becomes valid
when combined with a secret scalar (the oracle's outcome scalar)

Creating an adaptor signature for outcome o_i:
  1. Compute anticipated oracle point: S_i = R + hash(R || o_i)·V
  2. Create adaptor signature: σ' = sign(tx_i, privkey) adapted to S_i
  3. σ' is verifiable but not yet a valid Bitcoin signature

When oracle announces s_i:
  Complete signature: σ = σ' + s_i
  This signature is valid for spending CET (Contract Execution Transaction)

DLC Script Structure

The funding output uses a standard 2-of-2 multisig (or P2TR aggregate key):

Funding output script:
OP_2 <alice_pubkey> <bob_pubkey> OP_2 OP_CHECKMULTISIG

or in Taproot (preferred):
OP_1 <MuSig2(alice, bob)>  <- aggregated key

Contract Execution Transactions (CETs):
  One CET per possible outcome
  Each CET pays Alice and Bob according to that outcome

Refund transaction:
  Timelocked fallback if oracle never announces
  NSEQUENCE or CHECKLOCKTIMEVERIFY

Full Flow


1. Alice and Bob agree on contract terms and outcomes

2. They create and sign all CETs (one per outcome)

3. They fund the multisig output on-chain

4. Oracle observes the real-world event

5. Oracle publishes s_i for outcome o_i

6. Alice (or Bob) uses s_i to complete their adaptor sig on CET_i

7. CET_i becomes broadcastable; funds distributed per outcome

8. Oracle never sees the funding transaction or CETs

Privacy properties:
  - Oracle cannot link its announcement to any specific contract
  - Blockchain shows only a 2-of-2 multisig spend
  - Contract terms are off-chain

Taproot DLCs

With Taproot and MuSig2, DLCs become even more private:

# Simplified Taproot DLC structure
internal_key = musig2_aggregate(alice_key, bob_key)
# Each CET output is also a Taproot key path spend
# The signature on each CET uses adaptor technique with Schnorr
# On-chain: indistinguishable from any ordinary Taproot spend
☕ Help support TeachMeBitcoin

TeachMeBitcoin is an ad-free, open-source educational repository curated by a passionate team of Bitcoin researchers and educators for public benefit. If you found our articles helpful, please consider supporting our hosting and ongoing content updates with a clean donation:

Ethereum: 0x578417C51783663D8A6A811B3544E1f779D39A85
Bitcoin: bc1q77k9e95rn669kpzyjr8ke9w95zhk7pa5s63qzz
Solana: 4ycT2ayqeMucixj3wS8Ay8Tq9NRDYRPKYbj3UGESyQ4J
Address copied to clipboard!