Discreet Log Contracts: Scalable Smart Contracts for Bitcoin
What is a Discreet Log Contract? In simple terms, Discreet Log Contracts (or DLCs for short) enable bets to be made on an outcome with trust-minimised execution using Bitcoin.
The main innovation behind DLCs is that smart contract are made scalable and private, while also allowing the parties to determine the outcome of a contract without involving the oracle, trusting a third-party or each other.
Most smart contracts that exist on blockchain networks today require on-chain interactions. Whenever the demand for block space is high, interacting with these smart contracts means high fees and/or long waiting times are involved. DLCs use a technique similar to the Lightning Network so that the contract and most of the activity is not published on the blockchain.
On-chain contracts bloat the size of the blockchain which also increases the requirements for running a node on top of higher fees or longer wait times. They are also public with any observer able to see all the interactions.
With DLCs, neither blockchain observers nor Oracles will not know the contract terms and the oracle will never know the transaction amounts. Only two transactions are published on chain in the cooperative case, where DLCs look like a normal multi-signature spend, such that no external observer can learn of the contract’s existence or details from the public ledger. Hence, why they are called Discreet Log Contracts.
In this article, we’ll provide an overview of Discreet Log Contracts, look at the game theoretics involved, and the potential applications.
Introducing Discreet Log Contracts
A Discreet Log Contract (DLC) is a simple oracle contract scheme proposed by Tadge Dryja of MIT in 2018. DLCs can be executed using almost any blockchain, including Bitcoin, opening up use cases such as peer-to-peer derivatives, prediction markets and sports betting.
More recently, DLCs have been redesigned to make them more scalable and private by using adaptor signatures, a special use case of Schnorr signatures. While Schnorr signatures not yet implemented in Bitcoin, the signatures happen off-chain which enables DLCs to be possible and serves to hide the contract details from the Oracle.
Adaptor signatures, which are enabled by Schnorr, make the adaptor point based on the oracle’s expected signature. What this means is that each party gives each other invalid transaction signatures that can only be made valid in conjunction with the Oracle signature.
DLCs use a similar model to the Lightning Network, i.e., the use of payment channels. But instead of generic payments, DLCs are used to process payments conditional on some external data.
An Oracle signature can commit to anything; for example, the US Presidential election or the outcome of a football match. Prediction markets or sports betting are not the only applications; DLCs can even be used to create peer-to-peer derivatives, such as the BTC-USD rate on a particular date (i.e., a forward contract).
Forward contracts for other assets such as gold, wheat, oil, and so on are all possible. As long as there is an Oracle that publishes a price, peer-to-peer derivative contracts can be built using DLCs.
A DLC scheme can be used for contracts on any blockchain, all that is needed is multi-signature contracts and timeouts, meaning it could replace oracle subcontracts for smart-contract platforms like Ethereum.
September saw Bitcoin’s First DLC on Mainnet
The first Discreet Log Contract on Bitcoin’s mainnet took place on September 8th. Simply, it is a bet between BTCPay server creator Nicolas Dorier and Suredbits founder Chris Stewart on who will win the upcoming US Presidential election.
Nicolas bet that Trump would win. If he’s right, he gets 1 BTC as a payout. Chris bet that Biden would win, and if he’s correct, he gets 1 BTC as his winnings. Once the result is announced, the Oracle ‘OutcomeObserver’ will publish the winner of the election.
Although some trust is required in the Oracle, the contract also includes a refund transaction that can be executed in March 2021 that will give their collateral back. Also, anyone can make the same bet without the Oracle knowing.
Several teams such as Crypto Garage, Suredbits, and the MIT Digital Currency Initiative, are actively developing DLC implementations. While the bet above was described as a manual process to set up, work on these DLC specifications will eventually lead to a common standard that any wallet can integrate. Suredbits’ implementation is expected to be available soon, where users can download a desktop app and enter into DLCs.
To examine how DLCs functions, we continue the example where two parties bet on whether Trump or Biden will win the US Presidential election. Depending on who wins, the payoff will be higher for whoever guessed the winner correctly with the Oracle attesting to the outcome.
Looking Under the Hood of DLCs
To explain how DLCs function, first let’s examine how a bet can be executed using Bitcoin without DLCs.
Betting with a 2-of-3 Multi-Signature Scheme
Instead of using DLCs, two parties can enter a contract using multi-signature technology, specifically a 2-of-3 multi-signature scheme. In this case, two participants fund a multi-signature output and use a third-party as the escrow agent. To claim the funds from this output, two signatures are required.
We can think of the escrow agent as the Oracle in this situation. Whoever correctly guesses the outcome signs the transaction, along with the escrow agent, so the winner can claim the funds from the multi-signature output. The Oracle can also see the contract: they also have knowledge of the contract address and the amount of BTC at stake.
If two parties agree on the outcome, then they can both sign the transaction and settle the bet without an Oracle. However, if there is a disagreement, then the Oracle in a 2-of-3 multi-signature setup decides the outcome. Here we run into the Oracle problem, as the escrow agent can be bribed or collude with one of the parties to lie about the outcome. This means that the other party would lose all of their money, even if they bet on the right outcome.
Now let’s look at how DLCs try to overcome the Oracle problem in the 2-of-3 multi-signature example.
The “Oracle Problem”
To overcome the Oracle problem, DLCs ensures that the Oracle cannot see the contract and cannot decide the winner.
Since the Oracle is simply signing a message that a certain outcome happened (and is not signing any transactions), it makes DLCs a lot more private. Another benefit is that these smart contracts are more scalable, since it does not require oracles to put their signature on the chain, or a contract on the chain at all.
How are Oracles Removed from Equivocating with DLCs?
In short, DLCs involve two participants that bet on an outcome by making off-chain transactions with each other, which are invalid transactions.
If we take the example of the US Presidential election, once the Oracle signs that Biden or Trump won the election, whoever made the correct prediction would add that signature to the transaction and take the funds, ending up as winner of the bet.
Oracles will not know what contracts they are dealing with and just testify which candidate wins the election. They know people will use the message in their contracts, but they don’t know who exactly. Oracle themselves cannot tell that their signature was used to validate the transaction.
With DLCs, a participant can use that part of the script to say they‘ve got the Oracle’s signature, which allows them to receive the BTC. If a participant does not have the Oracle’s signature and someone tries to broadcast an incorrect outcome, they wouldn’t be able to get the money at all, and the other party could take it all after a time delay.
Oracles are incentivised to be as truthful as possible. Below, we compare the Oracle’s payoff in a 2-of-3 multi-signature setup and a Discreet Log Contract (DLC). The payoffs are greater for the Oracle in DLCs if they are honest. The incentives are structured such that even if an Oracle places a low value on reputation (r) and receives a low tip (t), they are still better off by being honest.
Oracles will likely use one public key for most of their signatures, and we can expect some of them to stake BTC. For instance, an Oracle may put 50 BTC under their key as a sign of their trustworthiness. Contract participants may then trust this Oracle with contracts with collateral up to a maximum of 50 BTC. If the Oracle lies, their signature will tie their public key to a false message in such a way any party can prove they lied (and take the money).
This is possible since if the Oracle creates two different signatures on two different outcomes of a single event, they reveal their private key. This makes it possible to create a staking mechanism penalise Oracles for undesirable behaviour.
In the case of signing for the US Presidential election, if the Oracle provides two different signatures to different parties, any participant could combine them and steal the Oracle’s private key from their public key. Along with the privacy consideration explained above, this makes it more difficult to collude with an Oracle. However, staking funds is not a requirement, but it is expected to become a standard.
To address collusion, users can and should add multiple DLC Oracles which multiplies the cost of Oracle bribery. Via Schnorr key aggregation, contract participants can add the two Oracles’ keys for a certain outcome together to get an aggregate public key for a certain outcome, whose underlying private key is the sum of the two Oracles’ signatures.
Discreet Log Contracts Illustrated
Let’s walk through a Discreet Log Contract (DLC) to see how the contracts work. Suppose we have a two-party DLC with two counterparts (Alice and Bob) and an Oracle (who does not require any knowledge about Alice or Bob, or their plans for entering a contract).
The only interaction Alice and Bob have with the Oracle is receiving publicly broadcast signature of the event they are speculating on. This signature will give Alice and Bob the power to unilaterally execute the agreed upon contract, without trusting each other.
Figure 1 below gives a basic overview of a DLC on Bitcoin:
Figure 1. A simplified overview of a Discreet Log Contract on Bitcoin
There is a small on-chain footprint left by Alice and Bob in the cooperative execution case, that is a funding transaction and a spending transaction — neither of which reveals their contract. Almost all execution is done off-chain, making DLCs scalable, and the blockchain is used as a last resort for privately settling disputes. In the non-cooperative case, the on-chain footprint and privacy is slightly worsened as an additional contract goes on-chain with the same property.
Going through with a bet using DLCs on Bitcoin can be broken down into three main steps:
- Funding transaction,
- Contract Execution Transactions (CETs), and
- Settlement
1. Funding Transaction
As illustrated in Figure 1, Alice and Bob create a funding transaction. They agree on the payouts for each possible outcome beforehand, where the actual conditions of the contract do not go onto the blockchain (as they are enforced off-chain).
To create the contract, Alice and Bob construct a funding transaction, depositing their collateral into a 2-of-2 multi-signature output (one key from Alice and one key from Bob). Let’s assume they put 2 BTC each into the contract.
Alice wants to bet on a Trump presidency, while Bob thinks Biden will win the election. The payoffs are then as follows: if Trump wins, Alice gets 3 BTC while Bob gets 1 BTC. If Biden suceeds, Bob gets 3 BTC and Alice gets 1 BTC.
2. Contract Execution Transactions (CETs)
Alice and Bob each create and sign two more transactions (one for each possible outcome) which spend the funding transaction. We called these the Contract Execution Transactions (CETs). While the funding transaction happens on-chain, the Contract Execution Transactions are done off-chain and are an application of Payment Channels.
With the Lightning Network’s Payment Channels, transactions happen off-chain and balances are updated, tracked by something called the state. By revealing private keys, previous states can be invalidated or they can build new states. Both parties can reveal a key such that if either party tries to broadcast an old state to the blockchain, both will lose their funds.
DLCs work similarly, but all states are created beforehand and validity is determined by a non-interactive Oracle signature. Two public keys are computed: P_OracleSig(Trump) and P_OracleSig(Biden), of which the private keys are Schnorr signatures that the Oracle may broadcast. These public keys are used to create multi-signature addresses for each of the possible messages the Oracle may sign for.
Both CETs also have a case where, after a timeout and neither participant acts on the date of the outcome, the transaction is considered as delayed. Here, whichever party realises first can take out the entire collateral which ensures that either party sends a signature once the contract matures. So if Trump wins and Alice fails to sign, Bob can claim the 4 BTC collateral, which ensures that either party sends a signature once the outcome has been revealed.
In our example, where two parties want to bet on the US Presidential election with two possible outcomes (a win for Trump and a win for Biden), CETs are created for each outcome. For each outcome, there are two outputs: one that Alice can claim and one that Bob can claim.
Figure 2 illustrates the CET with a Trump win below:
Figure 2: CET for a Trump Win
With 4 BTC locked in the contract, once the Oracle signs the message ‘Trump’ with its public key, Alice and Bob can create valid transactions such that 3 BTC is paid to Alice and 1 BTC is paid to Bob. If Bob cooperates, then both parties can spend the funding transaction directly to themselves, saving on fees and improving their privacy.
If Bob doesn’t cooperate by publishing the wrong CET saying that Biden won, then he will forfeit his funds and after a time delay, Alice will claim her payout of 1 BTC. A time-locked refund CET can also be added in case the Oracle becomes unresponsive.
But what if the Oracle signs a message saying that Biden wins? The Contract Execution Transaction in the case of a Biden win is shown below by Figure 3:
Figure 3: CET for a Biden Win
Bob will take the Oracle’s signature, sign the CET for a Biden win and broadcasting the CET. Bob gets 3 BTC while Alice will get 1 BTC.
If Alice doesn’t cooperate and tries to publish the CET for a Trump win, then she will forfeit her funds and Bob will be able to claim the 1 BTC for himself after a time delay.
3. Settlement
After the Oracle has provided its signature and published the outcome of the event, the correct CET can be broadcast. With a Trump win, Alice can broadcast the CET where she will get a payout of 3 BTC. If both parties agree on the outcome, then the funds can be spent directly from the funding transaction.
However, if neither party claims the funds, there is a timelock on each of the two outputs. After a delay, the party that realises first can claim the entire collateral.
Therefore, the incentives of the contract are aligned in such a way, each party’s best response to the other party is to cooperate. For example, consider the payoff matrix with a Trump win below:
Figure 4: Contract Payoff Matrix in the Case of a Trump Win
No matter the outcome or actions of the other party, the best strategy is to cooperate.
The posted collateral is distributed according to the realised outcome and the entire process — from the funding transaction to settlement — is cryptographically secured. No party can receive BTC that they shouldn’t and therefore enable a host of applications that reduces counterparty risk.
Conclusion
DLCs have the potential to open up applications such as peer-to-peer derivative contracts, sports betting, prediction markets and insurance, expanding Decentralised Finance (DeFi) on the Bitcoin network. It’s also possible to implement DLCs on the Lightning Network, in which case no transactions touch the blockchain, improving privacy and scale even further.
One limitation of DLCs relates to order matching. In the example presented above, Alice and Bob have already found each other and set up a contract once agreeing to some terms. In reality, if people want to use DLCs, there will need to be a meeting place.
A natural meeting place would be centralised marketplaces, such as cryptocurrency exchanges, which could match individuals that want to use these sorts of contracts so they do not have to seek a counterparty themselves. The exchange will not have to keep custody of people’s funds or the exchange could be the counterparty take the other side of a contract bet.
Once Taproot has been activated on Bitcoin, multi-signature transactions look like typical, single-signature transactions. What this means for DLCs is an even smaller on-chain footprint and they will look like any other standard single-signature transaction — with the main advantage being lower fees and improved privacy.
To learn more about Discreet Log Contracts, check out this video.
If you have any feedback, please contact us or leave a comment below.
About Interdax:
Level-up your trading in our next-gen digital asset derivatives exchange.
