Discreet Log Contracts: Scalable Smart Contracts for 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. When the election is finalised, the @OutcomeObserver will broadcast a signature that either Chris or Nicolas can use to settle the bet.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.