10 things to know about Discreet Log Contracts

Alt-coins enthusiasts have claimed that Bitcoin’s Script language has severe limitations in terms of smart-contracts. The recent surge of so-called DeFi (Decentralized Finance) applications built on top of Ethereum has shown a large demand for complex smart contracts. Now, bitcoin developers have started building new kinds of smart contracts that could have similar applications as some of the recent DeFi ones – see our overview of the space here.

One type of smart contract has gained particular traction: Discreet Log Contracts, or DLCs. In its introduction to the whitepaper, the MIT Digital Currency Initiative explains that, with a DLC, “two parties can form a monetary contract redistributing their funds to each other, based on preset conditions, without revealing any details of those conditions to the blockchain”.

Here are 10 basic points to know about DLCs. Further resources are indicated at the end of this article:

DLCs have been theoretically known since Thaddeus Dryja’s whitepaper in 2017 but they have become practically possible with Loyd Fournier’s work on adaptor signatures, which allow for scripts that don’t rely on Bitcoin’s Script language (“scriptless scripts”).
Scriptless scripts, and therefore DLCs, are greatly facilitated by Schnoor signatures, which will hopefully be soon implemented in Bitcoin Core.
DLCs are pretty straightforward: two parties send money to a multi signature address, and an oracle signs it with a hash that corresponds to the outcome; the party that has the hash of the outcome gets to withdraw the money. The image at the start of this article is a simplified overview by InterDax of how DLCs function.
DLCs look like traditional multi-signature transactions since only the funding and spending transactions appear on the blockchain. The conditions of the contract stay off-chain. Blockchain analysis firms can’t tell if a certain multi-signature transaction is a DLC nor what its content is. This is why they are called “Discreet”.
Oracles themselves don’t know if they are used for a DLC nor what its terms are, to mitigate the extent of the so-called “Oracle Problem”: the Oracle acts as a trusted third party, which comes with security risks (the Oracle could collude with one of the parties, insert a subjective element in its appreciation of a real-world event, etc.).
DLCs are also a way to address the scalability issues that most smart contracts raise: because they occur off-chain, they have a limited impact on the blockchain size.
DLC schemes can be implemented on any blockchain, not only Bitcoin’s.
The main use-case for now is betting on a real-world outcome. The first DLC bet was between Nicolas Dorier, the founder of BTC Pay Server, and Chris Stewart, co-founder of Suredbits, on the outcome of the 2020 US Election. Another use case would also be forward contracts, either on a currency or a commodity. More complex tools could follow.
The main implementations of DLC schemes in Bitcoin are: Bitcoin-S, NDLC, Rust-DCL et CFD-DLC, written respectively in Scala, C#, Rust and Python.
The main companies working on DLCs are Suredbits, Crypto Garage and Atomic Finance.