July 27, 2022
What Are DLCs and DLC Attestors?
An Introduction to Discreet Log Contracts
What are Discreet Log Contracts?
Discreet Log Contracts (DLC) are cryptographic structures invented at MIT by Tadge Dryja, co-inventor of the Lighting network. In short, DLCs enable conditional payments between two parties. The parties can be users, institutions, smart contracts – any entity with a Bitcoin address. The DLC uses discrete log contracts and the parties’ information is kept private, so it is a pun in that it's both "discrete" and "discreet."
In practice, DLCs function similar to multisig wallets in that two signatures are required to execute a transaction. However, unlike a wallet, the DLC itself does not track balances – so by analogy it is more apt to describe it as a "special multisig keychain”. In any case, the DLC is created with two parties and an attestor. The attestor (which can be a single attestor or an attestation layer) attests to observed reality and essentially referees the transaction.
The key to a DLC is the attestor itself. Unlike a data feed oracle such as Chainlink’s that serves prices or other external data, the DLC attestor only has two functions:
- When the DLC is created, the DLC attestor generates pre-signatures using the users’ keys, its own private key, and its nonce. One pre-signature is built for each potential contract outcome. For example, a binary outcome (win/lose) will generate two pre-signatures, whereas a more complex outcome will generate multiple pre-signatures and may even generate a formula for computing pre-signatures (for example, following a continuous distribution).
- When the DLC is closed, the DLC attestor views the observed outcome and attests to the signature corresponding with that result. This completed signature lets the winning party execute the contract.
Why Now?
DLCs have been used over the years, but they’ve just become more feasible for practical use. Last fall, Bitcoin received a major update (called Taproot) that added support for Point Time Locked Contracts (PTLCs) and Schnorr Signatures, both of which enable more powerful and streamlined DLCs. An improvement from their predecessor Hash Time Locked Contracts (HTLCs), PTLCs lock Bitcoin to a public key (a point on its elliptical curve) and are unlocked by providing a signature from a satisfied signature adaptor. HTLCs can unwittingly create a link between multiple payments whereas PTLCs can use different keys and signatures, which eliminate the risk of correlation and improves safety. The addition of Schnorr signatures also allows PTLCs to take zero bytes of block space, which significant reduce its footprint and improves its real-world applicability.
What do DLCs enable?
Using our parlance, DLCs enable “Bitcoin escrow contracts” held directly in user’s wallets. Bitcoin is powerful collateral but due to its lack of smart contract interface, it can’t directly be used on other chains. All predominant solutions require using a third-party custodian which presents inherent risks. To use Bitcoin in Ethereum, for example, the Bitcoin has to either be sent to a bridge (which then becomes a high-profile target for hackers) or it is “wrapped”, meaning that it is sent to a trust that then gains control over it. Either solution is unsatisfactory in that the use of a third-party custodian eliminates the decentralized nature of Bitcoin.
Instead, DLCs can be used to lock Bitcoin in escrow and enable their use elsewhere. Instead of sending Bitcoin to a protocol or an app, the user can enter into a contract within their own wallet with the application, moving their Bitcoin into an escrow account. The existence of the escrow provides a “proof of collateral” or a guarantee that the Bitcoin reserve exists and is locked.
To initialize the DLC, the user accepts a contract with the application as its counterparty. This contract represents the terms and conditions that the user accepts, including the amount of Bitcoin, the time duration and liquidation terms. The contract may include real-world data such as token prices provided by a price feed oracle such as Chainlink’s or RedStone's, or it may be a simpler contract denominated only in Bitcoin, such as an auction bid.
What is the difference between a data oracle and a DLC attestor?
Oracles are entities that provide data external to a blockchain. Although DLCs governing BTC-to-BTC interactions might not require outside data, many real-world applications require a price pair (e.g. BTC-USD) or other data. We refer to data oracles to any external data source whereas a DLC attestor is an entity that is involved in opening or closing DLCs.
To provide a well-known example of a data oracle, Chainlink is a top-tier solution that provides tamper-proof price data, enabling smart contracts on any blockchain to leverage extensive off-chain (real-world events) resources. Chainlink aggregates price feeds from various data sources and publishes a reference price that is broadly relied on as a source of truth within the crypto industry. At the time of this writing, Chainlink is reputed to have over 90% market share in the price feed oracle market.
As mentioned above, more complex DLC structures often require a price feed to validate conditional outcomes. For example, for a loan that is backed by Bitcoin but denominated in USD, the BTC-USD price pair would govern liquidation. A sharp dropoff in the value of the Bitcoin collateral may trigger a partial or full liquidation. The use of Chainlink oracles ensure that the reference price is tamper-proof price data instead of a centralized data source that would serve as a single point of failure.
In December 2021, DLC.link received a Chainlink Community Grant to bridge oracle data to DLCs on Bitcoin. As Aki Balogh, CEO of DLC.Link, said: "We're thrilled to have received a Chainlink Community Grant to build out the infrastructure required for connecting discreet log contracts on the Bitcoin network to Chainlink's highly reliable and secure network of oracles. This will enable developers in the Bitcoin ecosystem to offer users advanced decentralized applications that were previously impossible to achieve."
