I. Introduction
Once upon a time, bitcoin-native decentralized finance didn't seem possible. Bitcoin's ledger lacks room for scores of complicated financial contracts. And its simple language — designed for security — lacks the ability to encode them in single transactions.
So bitcoin holders had to look elsewhere for returns and compromise on principle. Bitcoin banks require both your private keys and your private information. And "wrapping" bitcoin onto a network like Ethereum usually involves bitcoin banks behind the scenes, adding counterparty risk to smart contract risk. On top of all this, services often deploy new altcoins to juice returns artificially. Through 2017, it seemed that bitcoin holders could earn a return only by compromising their self-sovereignty, privacy, or security — core principles of the bitcoin ethos.
Then, Thaddeus (Tadge) Dryja posted a whitepaper on discreet log contracts.1 The whitepaper outlines bitcoin-native smart contracts with a small on-chain footprint, compatible with bitcoin's simple language. Above all, discreet log contracts permit users to retain their private keys and their financial sovereignty.
In late 2020, Atomic.Finance saw the potential in discreet log contracts (or DLCs) and pivoted from an Ethereum DeFi company to a bitcoin-only, bitcoin-native company running on DLCs. By encoding financial contracts into DLCs, we are bringing sound finance to sound money.
We want everyone who uses Atomic to understand how it all works, if they're curious. Even though DLCs are both new and complex, you don't need a background in mathematics or computer science to understand them. Here, we simplify the technical details for the interested layperson. A little patience and perseverance will reap rewards in understanding.
II. The Road to DLCs
Suppose Alice and Bob want to bet each other in bitcoin about the outcome of an election. They have a number of ways to do it.
They could bet off-chain. But then the winner would have to trust the loser to pony up. This isn't ideal, since some losers fail to honor their agreements.
Or they could bet with a 2-of-2 multisig. This means that Alice and Bob use a transaction to lock up the winnings in escrow so that unlocking the winnings with another transaction requires both of them to sign with their private keys. But this could go worse than the previous case. If the loser refuses to cooperate, the winner receives nothing — not even his or her original wager.
Or they could bet with a 2-of-3 multisig. This means that Alice and Bob use a transaction to lock up the winnings in escrow so that, in addition to a third party, at least one of them signs a new transaction that pays the winner. Alice and Bob could pick a trusted third party to intervene in case the loser fails to cooperate. However, the third party would know the details of the contract in virtue of having signed it. So not only would Alice and Bob lose privacy, the third party could also collude with the loser to split the winnings.
Alternatively, Alice and Bob could use a network like Ethereum, wrap their bitcoin, and enlist the help of a third party. The third party would bring data from the external world about the election onto the blockchain and function as an oracle. In this case, the oracle would be automated. Alice and Bob could encode the bet into a single transaction that invokes the oracle. Then, when the automated oracle provides the result, the contract executes the payout. In addition to smart contract risk, and the risks that come with wrapping, the entire contract would appear in the blockchain for all the world to see. Information-dense contracts more quickly clog the blockchain, leading to higher transaction fees and less privacy. This financial voyeuerism also enables MEV (miner-extractable value) — value that accrues to those who leverage their positions in the network to frontrun and exploit users for profit.2
Perhaps Alice and Bob should use DLCs.
III. How to Bet with DLCs
DLCs help solve a range of problems we've encountered thus far. In one fell swoop, they preserve privacy, limit users’ on-chain footprint, and help prevent MEV, the value culled from exploiting information-dense smart contracts. And they involve no third party custodians. They sound like magic. And DLCs do involve some complicated mathematics. But the main ideas are simple.
First, instead of putting the entirety of a complex contract into a single on-chain transaction, as Ethereum does, we can spread the logic of a contract over several smaller transactions, only a small fraction of which ever appear on-chain.
Second, the contract invokes one or more oracles incentivized to behave honestly and which help ensure the contract executes successfully.
DLCs have three main steps. We’ll examine each of these steps by tracking a bitcoin bet between Alice and Bob. It will work a lot like the bets that Atomic has already run.
Step 1. Fund the Contract
Alice and Bob each wager 1 BTC. The winner will receive both his or her original 1 BTC and the loser's 1 BTC.
To fund the bet, Alice and Bob jointly construct a transaction that locks their 2 BTC to a new address. They each sign the transaction with their private keys and then submit the transaction to appear in bitcoin's ledger. This is known as the funding transaction.
The new address is linked to both of their private keys. Both Alice and Bob will have to use their keys to sign another transaction to unlock the 2 BTC. So the funding transaction is a 2-of-2 multisig.
Once the transaction appears in bitcoin's ledger, the funds are held in Alice and Bob's joint custody.
Step 2. Write the Contract
Smart contracts contain a logic which says what should happen under various conditions. In Ethereum, the entire logic of a financial contract fits into a single transaction. But DLCs spread the logic over several transactions. These are known as contract execution transactions (CETs). Roughly speaking, each possible outcome gets its own CET. For Alice and Bob's bet, each and every one of the CETs spends the 2 BTC locked in the output of their funding transaction. But only one of them will appear in the ledger when the bet ends.
Let’s look more closely at Alice and Bob’s CETs. Suppose Alice and Bob bet about whether, say, Dorian wins the election. Alice bets that Dorian wins, and Bob bets that he doesn't. So, ahead of the election, they construct four CETs:
- one for a Dorian win that sends 2 BTC to Alice
- one for a Dorian loss that sends 2 BTC to Bob
- one for a Dorian tie that sends 1 BTC to Alice and 1 BTC Bob
- one for other unlikely scenarios, where, again, Alice and Bob each get 1 BTC back
At this point, you might raise two challenges for CETs.
Cheating. Since Alice and Bob sign the CETs before the election, what stops either from submitting one beforehand to claim the 2 BTC?
Truth. How do Alice and Bob ensure that the election result leads to the correct payout?
These challenges have a common solution — oracles.
Things get a bit dicey at this point because we need to take a little detour through oracles. But if you stick with me here, you'll soon have a solid idea of how DLCs work under the hood.
IV. Interlude on Oracles
Alice and Bob need an oracle they both trust to report the election result. So they consult the Suredbits Oracle Explorer. They agree on an oracle with a trustworthy record who has already publicly committed to tweet the result of the election. Importantly, the oracle needn't ever know that they've been chosen.
The oracle's public commitment to announce the result contains two important pieces of information.
First, the commitment says what the oracle would announce for each result.
- If Dorian wins, we will tweet 'Dorian_wins'.
- If Dorian loses, we will tweet 'Dorian_loses'.
- If Dorian ties, we will tweet 'Dorian_ties'.
Second, the public commitment contains a chunk of cryptographic data partially
derived from the oracle's own private key.
This data pairs with each of the above messages to form three tools. For reasons you'll see shortly, we'll call them encrypters.
- The ‘Dorian_wins’ encrypter
- The ‘Dorian_loses’ encrypter
- The 'Dorian_ties' encrypter
We call them encrypters because that's what they do — they encrypt. In doing so, they help overcome the above challenges related to cheating and truth. The hardest part is almost done, so hang with me here.
How Oracles Solve the Cheating Problem
Alice and Bob construct the CETs before the outcome of the bet. They sign CETs with their private keys and wait until the election is over to submit the CET that rewards the winner. But what stops either person from rewarding themselves with 2 BTC beforehand by submitting a transaction early?
Enter the encrypters. When Alice and Bob construct the CET in which Alice receives 2 BTC, Bob signs with his private key. At this point, Bob's signature is valid. So if Alice were to receive the CET with Bob's valid signature, she could sign it, too, and then submit the transaction to cheat Bob. To prevent Alice from cheating, Bob encrypts his signature with the 'Dorian_wins' encrypter. This renders his signature and the whole transaction invalid. As a result, Alice can't claim the 2 BTC prematurely.
This first CET isn't quite done, though. Alice also signs and encrypts her signature with with the same 'Dorian_wins' encrypter. They both use this encrypter because this is the CET that awards Alice for betting that Dorian wins. We'll see why this is important shortly. The doubly signed CET sits off-chain — and invalid.
They repeat this process for the CET in which Bob receives 2 BTC. They encrypt their signatures in turn but this time use the 'Dorian_loses' encrypter.
And they repeat once more for the CET in which they each receive 1 BTC for a tie. This time, they encrypt their signatures with the 'Dorian_ties' encrypter.
Since the CETs have no valid signatures, neither Alice nor Bob can send the CETs to the network for a premature payout. When the oracle announces the result, however, we can make one of them valid. And this is how the oracle help solves the truth problem.
How Oracles Solve the Truth Problem
After the election, the oracle will use its private key to provide a cryptographic signature over either 'Dorian_wins' or 'Dorian_loses' or 'Dorian_ties' and announce this information. Any of these announcements would decrypt the signatures of the CET whose payout corresponds to the announced result. So we will call each of these possible announcements decrypters:
- The 'Dorian_wins' decrypter unveils the valid signatures hidden by the 'Dorian_wins' encrypter
- The 'Dorian_loses' decrypter unveils the valid signatures hidden by the 'Dorian_loses' encrypter
- The 'Dorian_ties' decrypter unveils the valid signatures hidden by the 'Dorian_ties' encrypter
Alice and Bob can't know beforehand what any of these decrypters look like. But once the oracle announces one, the winner can transform a single CET's signatures from invalid to valid.
How does this help resolve the Truth Problem? As long as the oracle correctly reports a result, the lone CET for that result can be rendered valid.
The worst is over. If you've made it this far, it's smooth sailing from here.
V. Payout and Payoffs
Suppose Dorian wins the election, and Alice wins the bet. One third and final step remains.
Execute the Contract
The oracle announces the result and provides the relevant decrypter. Alice then decrypts both signatures in the CET where she receives 2 BTC.
She submits the newly valid transaction to the network. And, soon after, the ledger shows that she’s received 2 BTC from the original funding transaction. Well done, Alice.
Let's review some noteworthy points.
- Alice didn't need Bob to cooperate after the election. He had already signed the CET, and verifiably so.
- The other CETs remain invalid and never appear on-chain. This limits the on-chain footprint of DLCs, especially more complex contracts with thousands of possible outcomes.
- Bitcoin's public ledger provides users like Alice and Bob full transparency — and peace of mind — about the location of their coins.
- DLCs simultaneously grant users a high degree of privacy from those who monitor on-chain activity. In the ledger, a DLC looks no different than any other 2-of-2 multisig. Miners and on-chain analysts see none of the contract's logic except for the payout. So the financial voyeurism that enables MEV in Ethereum is not possible in bitcoin with DLCs.
- DLCs allow users to retain their private keys. No third-party custodians required.
Fortunately, you don't have to take my word for it. Since Atomic.Finance values transparency so highly, we're happy to report that we use the open source DLC protocol. In fact, we encourage you to examine the protocol on GitHub as ability allows.
Risks remain, though, and DLC oracles have a unique risk profile. Let's take a look.
VI. Oracle Risks
DLCs rely on oracles to report real-world events to the bitcoin network. As trusted-third parties, they look like security holes. How big of a security hole are they?
The risks surrounding oracles deserve an entire article. For a survey of these risks, I recommend this Suredbits post. But we'll briefly cover the main issues.
Instead of relying on a sole oracle to report the truth, a DLC can invoke multiple oracles so that the contract executes when a certain number of them report the same event. This greatly mitigates the risks of relying on a single oracle reporting falsely, reporting multiple outcomes, or failing to report at all.
The DLC protocol also refunds participants in cases where oracles fail to report, or fail to achieve the number of reports required to execute a payout.
Oracles are incentivized to tell the truth. At this point, failure would bring a severe reputational hit. And since some might leverage their reputations to build successful oracle businesses, a hit to the reputation is a potential hit to future earning potential. Additionally, if oracles report multiple outcomes for a single event, they leak their private key. To gain user trust, then, an oracle could hold funds with that private key. This would signal that they have skin in the game, and verifiably so. Users would know that reporting multiple outcomes would heavily penalize the oracle in the short-term.
Unlike automated oracles on other smart contract networks, oracles needn't know that they're invoked in any given DLC. Users simply use information that oracles have reported publicly. So although an oracle could know that they serve in a given DLC (e.g., by being a party in the DLC), no oracle can know that they know all the DLCs in which they serve. So the downside of misreporting is unknowable. Hence, for all the oracle knows, being dishonest isn't worth the benefit.
VII. Conclusion
DLCs can encode financial contracts beyond simple bets. Atomic.Finance encodes options contracts, including contracts like covered calls which allow users to earn a return on bitcoin they already own. These contracts are more complex, but they work essentially the same as Alice and Bob's bet. For more on how Atomic uses DLCs, our piece on subscription DLCs explains how we use DLCs to create a more passive non-custodial investing experience with Recurring Strategies. With subscription DLCs, users can enjoy a return on bitcoin, in bitcoin, while keeping their private keys.
We believe that DLCs will become increasingly important as Sound Finance grows and matures, in much the same way that the lightning network has become increasingly important for payments. These developments and others will interact and compound in exciting and unexpected ways. The future is truly bright. Bright orange, anyway.
Join the Sound Finance Movement
Atomic Finance builds sound finance products for sound money.
Our first Sound Finance product is a mobile app that provides self-sovereign Bitcoiners a way to earn a return on their bitcoin with full transparency. Without having to give up custody of their coins to a third-party custodian.
1. Thaddeus Dryja (2017), "Discreet Log Contracts."
2. Daian et al. (2019), "Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges."
