Discreet Log Contracts Part 4: Security and Trust Model
So far in our Discrete Log Contracts series, we’ve covered what they are, how they work, and why they’re great. In this final post, we will enter into a practical discussion of the security and trust considerations involved when dealing with DLCs.
Part 1 — What is a Discreet Log Contract
Part 2 — How do Discreet Log Contracts Work
Part 3 — Why Discreet Log Contracts are Great
The DLC (user) security model is quite simple and there are only three keys involved. The first key owns your half of the multisignature funding transaction, let’s call this the setup key. The second key is used in the (off-chain) contract execution transactions (CETs), let’s call this the dispute key. The third key gets paid to — should you receive any money out of this DLC — through cooperative close, unilateral close initiated by your counterparty, or unilateral close initiated by you followed by a CET spend, let’s call this the payout key. All three keys can be generated for this DLC and never used again.
The setup key is the least cold key. It needs to be available during setup because it is used to sign all of the CETs. It is also used during cooperative contract execution since the funding transaction is spent in cooperative close. Note that cooperative contract execution has no time limits and can be put off indefinitely. That is, in terms of security — your counterparty can always choose to unilaterally execute the DLC if you take too long and this can have minor privacy implications. This means that the setup key can be kept in cold storage for the entire life of the contract, which is very feasible for long-term contracts.
Both the dispute key and the payout key can be indefinitely cold! The payout key is never used here since it is not spent as part of the DLC. The dispute key on the other hand can be necessary should you decide to unilaterally execute the contract by publishing a CET to the blockchain. In this case, the dispute key must be used in conjunction with the oracle’s signature to spend your CET output. However, you can delay unilaterally broadcasting a CET indefinitely. Thus, I would argue that the dispute key should also be kept cold.
And that’s it as far as keys are concerned. All DLC keys can be kept in cold storage pretty much all of the time! It is important to remember that if your DLC private keys be compromised, all funds tied to those keys are vulnerable.
A slightly more subtle yet important implementation detail is that you should never sign your own CETs except for the case where you sign exactly one which you plan on publishing as a unilateral contract execution. This is important because if an adversary gets a hold of a fully signed CET for any event that has not occurred, they can publish it to the blockchain which will give all of your funds to your counterparty (because you don’t have the oracle signature required for spending that CET).
One last security consideration to keep in mind is that you should be using a secure channel when communicating with your counterparty. Note that you do not need a secure channel with the oracle since they are publicly broadcasting their signatures — which self-authenticate.
As the entire point of DLCs is to execute contracts based on “real-world” (i.e. not internal to the blockchain) information, trust is required and unavoidable. What is great about DLCs when it comes to trust is that they provide what I believe to be a pretty idyllic trust model given that we must put trust somewhere in order to have this functionality.
To start, you are not required to place any trust in your counterparty! At no point does contract execution depend on your counterparty once the DLC is setup (which also requires no counterparty trust).
Like any oracle scheme, we are going to need some trust in our oracle. However, the DLC scheme provides us with a lot of nice, often built-in, trust mitigation. Firstly, the oracle does not know that you or your contract exists. Second, you can (and should) add a time-locked refund CET in case the oracle becomes unresponsive.
Third, every oracle lie will come in the form of a signature tying the oracle’s public key to a false message. This acts as a disincentive to lying as an oracle’s business model is partially based on reputation. A lie provides extremely compact (64 bytes) cryptographic proof of misbehavior. Taking this a step further, I believe that oracles of the future will stake their funds using trusted escrow services in order to gain trustworthiness and cryptographic proof of misbehavior is all that is needed to enforce retribution (and possibly user recompensation).
Fourth, users can (and should) use multiple DLC oracles at once to protect themselves from a disappearing and/or lying minority. Not only this, but it also multiplies the cost of oracle bribery n-fold (where n is the number of oracles required for unilateral execution). Note that DLC’s provide for really natural oracle aggregation via schnorr key aggregation.
Lastly, perhaps the most powerful property of the DLC scheme is that oracles cannot equivocate. This means that they cannot tell different users different things have happened. If an oracle signs two different messages with the same keys (which are pre-committed as part of the DLC scheme), then anyone who sees both signatures can compute the oracle’s private keys! Should this happen, any user can now sign for the oracle in any situation, as well as take any bitcoin tied to the key. And similar to what I mentioned with escrows earlier, I believe that DLC oracles will publicly stake funds by holding bitcoin with their signing key so that they lose these funds to users should they equivocate.
Thus, we can see that in its fully mature form, a DLC involves distributing some soft version of trust amongst many oracles, all of whom remain oblivious to your contract and have a lot to lose should they attempt lying.
Not only is lying punishable, but it should be noted that telling the truth is rewarded since oracle’s can be anonymously paid for their services, making them sustainable to run without sacrificing privacy or trust.
One last practical consideration that DLC users should have in mind is that you must take care when setting fees on CETs, since a fee that is too low can delay or even erase your ability to turstlessly (unilaterally) execute the DLC.
This wraps up our discussion of Discreet Log Contracts. I hope that you now understand how they work, why they’re great, and how they provide us with a solid solution to the oracle problem by allowing users to privately distribute minimal trust amongst trustworthy oracles!
Contact us @Suredbits
Contact Nadav @Nadav_Kohen
All of our API services, for both Cryptocurrency APIs as well as Sports APIs, are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
https://suredbits.com/discreet-log-contracts-part-4-security-and-trust-model/
To learn more about how our Lightning APIs work please visit our API documentation or checkout our Websocket Playground to start exploring fully customized data feeds.
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at sales@suredbits.com.
Originally published at https://suredbits.com on September 26, 2019.
