Discreet Log Contracts (DLCs), sometimes referred to as smart contracts on Bitcoin, are a technique that allows Bitcoin payments to be conditioned on real-world data. Typical use cases include sports betting, conditioned on the result of a match, or futures contracts conditioned on the price of a certain asset. This real-world data is provided by so-called oracles.

Unlike on Ethereum and similar blockchains, oracles and real-world data in DLCs are off-chain. Bitcoin's scripting capabilities are limited. It is not possible to directly bring real-world data to the Bitcoin blockchain and work with it in the Bitcoin script. So in DLCs, the execution of the contract is not handled by the blockchain itself. It requires taking the cryptographically confirmed data from the oracle and using it to finalize and broadcast the transaction that settles the contract.

Why DLCs

When conditioning Bitcoin payments on external data, one might consider using a 2-of-3 multisig, with the oracle holding one key and working as an arbitrator. Such a setup works, but the oracle must interact with every contract, knows details about each contract, and can equivocate, deciding the outcome of each contract individually, making potential fraud more feasible.

DLCs solve this by providing:

• Scalability: The oracle does not interact with any contract. It only attests to the outcome of an event and publishes the attestation in some public feed.

• Privacy: The oracle does not know any details about contracts conditioned on it. In fact, the oracle does not even know that the contract exists at all.

• Accountability: Any number of contracts can be conditioned on one event. The oracle cannot attest to two different outcomes of one event without compromising its private key.

How a DLC works

At a high level, the process works as follows.

• First, the oracle defines an event (date, its possible outcomes, and the event's public key). This is called an oracle announcement.

• Two parties, say Alice and Bob, then lock their Bitcoin into a 2-of-2 multisig address, each holding one key. This ensures no one can back out once the contract is set up, and Bitcoin cannot be stolen by any single party. This transaction is called a funding transaction.

• For each possible outcome of the event, Alice and Bob compute a special value called an anticipation point, using the event's and oracle's public keys. These anticipation points are used to construct Contract Execution Transactions (CETs). CETs, in this case, are Bitcoin transactions that spend from the 2-of-2 multisig address to Alice and Bob according to each possible outcome.)

• When the event happens, the oracle determines its outcome and publishes a confirmation called an oracle attestation, using the oracle's and event's secret keys. Alice and Bob use it to unlock precisely one CET and close the contract.

Note: What makes CETs special is that they are not valid transactions yet. A given CET will only be valid if the oracle confirms the outcome corresponding to that particular transaction. Unless the oracle misbehaves, only one CET will ever be valid.

Adaptor signatures

The cryptographic mechanism making this possible is called adaptor signatures.

Instead of signing a CET directly, Alice and Bob create pre-signatures using anticipation points as adaptor points. A pre-signature is not a valid signature. It can be seen as an encryption of a valid signature. It can only be transformed into a valid signature with knowledge of a so-called adaptor secret corresponding to the adaptor point used to create it.

When the oracle publishes its attestation, that attestation serves as the adaptor secret. It unlocks exactly one pre-signature, turning it into a valid signature for the CET corresponding to the actual outcome. The contract settles on-chain.

Multiple oracles

The security and practicality of DLCs heavily depend on the trustworthiness of the oracle. One cannot completely avoid the risk that the oracle becomes unresponsive or corrupted.

A natural mitigation is to rely on multiple independent oracles. In a 2-of-3 setup, for example, Alice and Bob require any two of three oracles to agree before a contract can settle. This eliminates the single point of failure and allows for one oracle to go idle or attest to a wrong outcome without breaking the contract.

Why it matters

DLCs allow Bitcoin payments to be conditioned on real-world data, privately, scalably, and without trusting any single party. The contract logic stays off-chain. The settlement lands on Bitcoin. Nothing about Bitcoin itself needs to change.

That is what makes DLCs a genuine extension of what Bitcoin can do, built entirely on its existing cryptographic foundations.

Read the full paper here.