repository·master·Indexed 42 days ago
https://github.com/discreetlogcontracts/dlcspecsSpecifications for Discreet Log Contracts (DLCs), a framework for on-chain/off-chain stateful Bitcoin contracts. Includes technical details on ECDSA adaptor signatures, DLEQ (Discrete Logarithm Equality) proofs, secp256k1 operations, and the role of Oracles in contract execution and funding transactions.
To understand the theoretical foundations, implementation details, and community discussions surrounding Discreet Log Contracts (DLC), refer to the following curated resources:
As of the July 2021 meeting, the following implementation statuses were reported for core components:
secp256k1-zkp version.bitcoind are required.node-dlc: Handles message serialization/structure and chain monitoring.chainabstractionlayer-finance: Used for wallet building; supports single-oracle and is adding disjoint union support.cfd-dlc: Currently serves as the backend; recently added serial ID support.Discreet Log Contracts (DLC) are negotiated through a three-step peer-to-peer messaging process between an offerer (initiator) and an accepter (responder):
offer_dlc message containing contract terms and funding details.accept_dlc message, which includes its signatures for the Contract Execution Transactions (CETs) and the refund transaction.sign_dlc message containing its signatures for all CETs, the refund transaction, and the funding transaction.Final Step: Once the accepter receives the valid sign_dlc message, it must broadcast the funding transaction to the Bitcoin network.
Multiple contracts can run in parallel. They are identified by a temporary_contract_id during negotiation, which is replaced by a contract_id (derived from the funding transaction) once the contract is established.
+-------+ +-------+
| | | |
| |---- (1) offer --->| |
| | | |
| |<--- (2) accept ----| |
| A | | B |
| |---- (3) sign --->| |
| | | (4) broadcast fund-tx|
| | | |
+-------+ +-------+
- where node A is 'offerer' and node B is 'accepter'The negotiation_fields type contains preferences from the DLC accepter used during contract construction.
Implementations:
single_negotiation_fields (type 0): Contains rounding_intervals, representing the maximum allowed rounding at any oracle outcome in a numeric DLC.disjoint_negotiation_fields (type 1): Used in dlc_accept messages responding to contract_info_v1 offers. It contains num_disjoint_events and a list of nested negotiation_fields (must be version 0 or 1).If an oracle attests to a fraudulent outcome, the combination of their original announcement and the fraudulent attestation serves as a fraud proof.
In scenarios where a user cannot obtain a full individual attestation (e.g., due to multi-oracle aggregation), a fraud proof can still be generated:
An Oracle is an entity that signs messages in response to real-world events to decide the outcome of a DLC.
Workflow:
Security Note: An oracle cannot equivocate (create two different signatures for two different outcomes of a single event) without revealing its private key. However, the current specification does not protect against a party colluding with an oracle.
DLCs use Adaptor Signatures to link the oracle's signature to the contract execution.
S): A point computed using only public information (the R-value, public key, and message) prior to the creation of the actual signature. For Schnorr signatures, it is calculated as:
S = R + H(R || P || m) * P (where P is the public key and m is the message).s'): An encryption of a signature s over a message m. The signature s is for a given CET and is encrypted using a Signature Point of an oracle.s' can be decrypted to reveal the valid signature s, which is then used to create the validly signed CET.S = R + H(R || P || m) * PNumeric Outcome Compression is a technique used to reduce the number of adaptor signatures required for a contract when an interval of numeric outcomes [start, end] results in constant payouts for all parties.
Instead of requiring $O(L)$ signatures (where $L$ is the interval length), compression reduces this to $O(\log(L))$. This is achieved by using 'digit prefixes'—arrays of integers representing a base-$B$ number where certain digits are omitted (ignored). An omitted digit in a prefix means that any value in that digit's position is covered by that single adaptor signature.
Key Concepts:
_ in documentation) acts as a wildcard.Discreet Log Contracts (DLCs) are a framework for on-chain/off-chain stateful Bitcoin contracts. They allow two parties to set up contracts directly on the Bitcoin blockchain using an Oracle to determine the contract outcome.
Key characteristics include: