Discreet Log Contract (DLC)

A Discreet Log Contract (DLC) is a form of Bitcoin transaction which uses an oracle to execute a smart contract. Essentially, DLCs allow parties to place bets using the Bitcoin blockchain. In order to construct a DLC, two parties lock funds in a multisig address. These funds are only able to be spent when the oracle releases the specified information at a specified time. An oracle for a DLC can be any form of data feed, such as a website’s publication of the result of a sports match, or an exchange’s listing of an asset price.

The word discreet is technically a misspelling of discrete. However, since the inception of DLCs, this is the spelling that has been used.

Discreet Log Contracts offer an improvement over other types of smart contracts in that their on-chain footprint is no different than a regular multisig transaction. They thus do not require any special changes to the Bitcoin protocol other than the introduction of Schnorr signatures, which will be introduced in the Taproot upgrade. However, DLCs do not fully solve the Oracle Problem, the inability to incorporate real-world data into a smart contract in a trustless manner, as they still rely on a trustworthy oracle to release true data.

A DLC works by using an oracle’s signature of a certain message as a private key, which allows the winner of the bet to sign a transaction spending the funds the two counterparties committed to the contract at the beginning.

For example, if Alice and Bob wish to set up a DLC to bet on the outcome of a coin toss, they first create a funding transaction, where both parties send bitcoin, say 1 BTC each, to a 2-of-2 multisig. Next, Alice and Bob obtain public keys whose private keys are newly created from the oracle’s signature of both events—heads or tails in the case of a coin toss. Note that these private keys are not the private key used to create the event signatures. A signature can not be used to derive the private key that created it.

With these public keys, Alice and Bob create two commitment transactions, called Contract Execution Transactions (CET), one of which spends the 2 BTC from the funding transaction to the “heads” public key and the other which spends it to the “tails” public key. Both of these transactions require signatures from Alice, Bob, and the “heads” or “tails” key. Since neither Alice nor Bob have the “heads” or “tails” private key, these transactions have only 2 of 3 required signatures, and remain unpublished to the blockchain for now.

After the oracle determines the result of the coin toss, say “heads”, the oracle publishes the corresponding “heads” signature, and Alice or Bob use this signature to derive the “heads” private key. Alice and Bob can now sign only the CET sending the bitcoin to the person who chose “heads”. The signed CET is published to the blockchain, and the winner of the bet receives the 2 BTC. The CET which required the “tails” signature is obsolete and discarded.

In order to incentivize the loser of the bet to sign and publish the transaction, extra bitcoin is added to the funding transaction by both counterparties. If the bet is 1 BTC, each counterparty might stake 1.5 BTC. The winner will then receive 2.5 BTC, and the loser will have their 0.5 BTC returned. This allows a time lock condition to be implemented, wherein, if the loser has not signed and published the transaction by a certain time, the winner may additionally claim the loser’s 0.5 BTC of collateral.