Conditional payments on “Bitcoin” using Discreet Log Contracts

Conditional Payments on Bitcoin using Discreet Log Contracts

Discreet log contract is a conditional payment mechanism invented by Tadge Dryja, co-author of the Bitcoin Lightning Network paper and a member of MIT’s Digital Currency Initiative team. The paper was written in 2017.

Overview

Currently conditional payments on blockchains like Bitcoin and Ethereum are done through “smart contracts” where the conditions are coded in limiting language like Bitcoin’s Script or a turing complete language like Solidity and this code is deployed on chain. The chain will later execute this code along with other inputs provided and then transfer the funds to one of the participants. This requires the chain to know the conditions, hence anyone in the world can learn the conditions. Also the chain has to execute these conditions, thus spend resources. Discreet log contracts aim to solve these problems by not putting these conditions on the chain but only require a signature from a pre-decided public key to decide where to transfer the funds. This pre-decided key can be of an oracle which is expected to act honestly and publish a signature on the correct message. The oracle does not have to be privy to the details of the contract. Nor does it have to publish its signature on the blockchain.

Discreet log contracts are suitable in cases where 2 mutually distrusting parties bet on the results of a public event like a sporting event, election or price of a commodity or currency. Here the sporting event’s broadcast channel or a news channel or the stock market feed will act as an oracle. The signature published by the oracle will be on the message which will be the result of the event.

Discreet log contracts require Schnorr signature but the Schnorr signature does not happen on chain, thus they can be used with Bitcoin today. The signature is generated off-chain and the signature reveals a secret that will be used to create a private key that will end up controlling funds.

Preliminaries

1. 
   

   
   

   
   

   
   

   
   

   
   

   Schnorr signatures. The key idea of discreet log contracts is based on Schnorr signatures. This is how it works (using ellpitic currves):(i) G and h are protocol parameters (hence known to everyone). G is generator of the group and h is a hash function.(ii) The signer chooses a secret key x and computes public key X. X = xG.(iii) To sign a message m, the signer generates a secret nonce k and publishes a commitment to the nonce, say R. Here R = kG. R is called the commitment.(iv) The signer hashes together the message and the public nonce to create a challenge c. c = h(m||R)(v) The signer then calculates s = k - cx. The signature on m is (R, s). s is called the response (to the challenge)(vi) To verify the signature, compute sG and check whether it is equal to R - cX. This works since sG = (k - cx)G = kG - cxG = R - cX.

2. Multi-signature output. A Bitcoin transaction creates outputs and spends inputs (previously unspent outputs) where each output is usually controlled by one private key. Multi-signature outputs are outputs that are controlled by more than 1 private key hence to spend such an output both private keys are required. (Not entirely true, there are different combinations possible like 1-of-2 which requires 1 out of the 2 private keys controlling the output to spend it, 2-of-3 which requires 2 out of the 3 private keys, and many more.
3. Time-locked outputs: Bitcoin scripting allows to create transactions in which the outputs cannot be spent until a certain time (certain block height to be precise). Such a timelock can be combined with other conditions like this output can only be spent by address A anytime or by address B after a certain time.

Discreet Log Contract

In Discreet Log Contracts, the oracle uses the Schnorr signature but in a different way. Rather than publishing the commitment to the nonce, R in the signature, the oracle publishes it before it even decides what message to sign. Say the oracle intends to publish its signature on the outcome of an event that will happen in future. It has a long term public key X, it chooses a nonce secret nonce k, computes a commitment to the nonce as R(=kG) and publishes R. (X, R) is a one time public key. Now if someone knew the signature, he could create a “special public key”, Y (hence a Bitcoin address) involving the signature whose private key only he knows. Thus if someone expected the oracle to publish a signature on message b, he can take his private-public keys p and P(=pG) and create Y as(i) sG = R - h(b, R)X(ii) Y = P + sGWhen the oracle publishes signature s, the owner of P will create know the private key of Y, since Y = P + sG = pG + sG = (p + s)G. Any funds transferred to Y before the oracle published the signature can be claimed by the owner of P. This is the key idea of discreet log contracts.

Example

1. Alice with public key A and Bob with public key B decide to place a bet on an event (like a boxing match between Mayweather & Pacquiao) whose outcome can be a (Mayweather wins) or b (Pacquiao wins), Alice chooses a, Bob chooses b. In practice, a and b should be randomized to avoid replay attacks (there might be multiple fights between Mayweather & Pacquiao, it should be clear which fight is being bet on).
2. Alice and Bob agree on an oracle that will at some later point of time publish a signature over either a or b. The oracle has a long term key pair and a one-time keypair (used for this event only). The one-time keypair is the commitment step in Schnorr signatures.
3. The oracle publishes the commitment R.
4. Alice and Bob create (but not yet write on the blockchain) a multi-sig transaction, say F which is funded by both of them and creates a 2-of-2 multi-sig output. They exchange the transaction id (without signatures). This transaction is called the contract funding transaction.

5. 
   

   
   

   
   

   
   

   
   

   
   

   
   

   Alice and Bob now both create a transaction each where they transfer the money from funding transaction F to their “special public key”. This “special public key” is generated assuming that the oracle with publish the signature on their preferred outcome. So Alice’s special public key Aₐ will assume that oracle will publish signature on a and Bob’s special public key B_b will assume that oracle will publish signature on b.Note there were more than 2 possible outcomes, Alice and Bob will create more of these transactions. These transactions are called contract execution transactions._Alice creates “special public key” A_ₐ(i) s_ₐ_G = R - h(a, R)X(ii) _A_ₐ = A + s_aGBob creates “special public key” B_b(i) s_bG = R - h(b, R)X(ii) B_b = B + s_bG

6. Both Alice and Bob will create their contract execution transactions such that the output is a script which allows the creator of the transaction to get paid immediately if he knows the private key but after a timelock the other party can take it. So Alice will create a transaction such that his special key A_a can get spend the output if he knows the private key but if he does not spend it under a certain time, Bob can. Vice-versa for Bob. This is done to prevent any party from submitting a transaction with an invalid output and locking the funds. eg If the oracle published a signature on a so Bob lost, now Bob can still spend funding transaction F to an ouptut B_b. In this case Bob cannot spend the output but neither can Alice. To prevent such situations, output of the contract execution transaction has an optional timelock.
7. Alice and Bob now exchange their contract execution transactions and signatures over them.
8. Alice and Bob now exchange signatures over the funding transaction F and then publish F on the blockchain. It is crucial that Alice and Bob sign and exchange their contract execution transactions before they sign F.
9. Now when the oracle publishes the signed outcome, the winner can claim the funds by publishing the corresponding contract execution transaction on the blockchain and immediately spending the output of his contract execution transaction to an address fully controlled by him.

Discreet log contracts are an interesting idea. Though the need to trust an oracle sounds like a limitation, this trust can be diffused among several oracles. This can be done by not demanding just one oracle to publish a signature, but several. Alice and Bob can decide on, say, 3 news channels (as oracles) and agree that 2 out of 3 news channels agree on an outcome for that outcome to be considered acceptable. Schnorr signatures help here as they can be used to construct threshold signatures. Each oracle will have its own private-public keypair. The oracles will then engage in an interactive protocol to publish the commitment and later the signature.

Here is the spec for Discreet Log Contracts from DCI’s github.