In our last Discreet Log Contract post, we explored the problems faced by most existing smart contracts as well as what Discrete Log Contracts (DLCs) are at a high level. In this post we will detail what exactly what it takes to execute a DLC as well as the many benefits we reap for doing so.

Part 1 – What Is A Discreet Log Contract

Part 3 – Why Discreet Log Contracts Are Great

Part 4 – Security and Trust Model

As the name suggests, DLCs are based on the Discrete Log Problem (DLP). In this context, we are specifically interested in the Elliptic Curve DLP which is used by the Bitcoin protocol. This means we can be sure we aren’t adding to our set of cryptographic assumptions.

See our Cryptography Appendix for details on how we use the DLP to generate public keys from private keys, and how we sign messages with private keys in such a way that only require public keys for validation.

As discussed in the appendix, a Schnorr signature of a message is just a number which requires a private key, a private secret and the message to compute. However, verifying this signature only requires the public key, the public key associated with the secret (usually denoted as R) and the message.

In particular, it is possible to compute a public key P_m, whose private key is the signature of m, from just the signer’s public key and R value! Thus, we can create our simple oracle contracts by creating multi-signature addresses for each of the possible messages an oracle might sign.

Suppose that Alice and Bob wish to enter into a DLC using the SuredBits oracle which signs the message “MOON” or “CRASH” every 24 hours if the price of BTC goes up or down at the end of that 24 hours interval.

1. Like any good contract, the first step is for them to construct a Funding Transaction. This is a transaction with collateral input and a simple 2-of-2 multisignature output (with one key from Alice and one from Bob). Say that each of Alice and Bob put in 1 BTC and that Alice gets 1.5 BTC while Bob gets 0.5 BTC in the MOON case and Bob wins 1.5 BTC and Alice gets 0.5 BTC in the CRASH case.
2. They now compute the two public keys P_MOON and P_CRASH whose private keys are the Schnorr signatures that the SuredBits oracle might broadcast. They do this using the oracle’s public key, P, along with the R-value for this event, which is broadcast daily.
3. They each create and sign two more transactions, one for each possible event, both of which spend the Funding Transaction. We call these Contract Execution Transactions (CETs). In Alice’s case, the first one will output 1.5 BTC to Alice if she can sign for the P_MOON key. The second will output 0.5 BTC to Alice if she can sign for the P_CRASH key. Both CETs also have a case where after a timeout, the person who didn’t publish the transaction to the blockchain gets the BTC.
4. They now sign and publish the Funding Transaction to the blockchain.
5. Now they wait 24 hours. Say that the price goes up so that the SuredBits oracle signs the message “MOON”.  Alice can now publish her CET and she gets 1.5 BTC.
1. What is even better is that rather than Alice using her CET, if Bob were to cooperate – say because this will result in better privacy for him – then Alice and Bob can spend the funding transaction directly to themselves, saving on fees and improving their privacy.

Note that it is very easy to extend this scenario to arbitrarily many outcomes.  There happen to be some clever schemes to do so.  It is also relatively straightforward to extend this scheme to more parties.

We now have a more in-depth understanding of what Discreet Log Contracts are and how they work. In the next post, we will discuss why we bother with DLCs, discuss their privacy, composability and scalability benefits.