Discreet Log Contracts enable non-custodial speculation directly on top of the bitcoin blockchain. When protocols are non-custodial, it’s important for users to understand how private keys are handled in the protocol. With DLCs, there is the potential for millions of dollars to be sent to the winner. This blog post takes a rigorous look at the private keys involved in a Discreet Log Contract.
The funding process for a DLC is interactive. You need to collaborate with your counterparty to generate a multisig address that is shared. Here is a diagram of the message flow to set up a DLC.
The keys involved are as follows:
- funding_pubkey – this is the key in the shared multisig address for the DLC
- payout_address – this is the address where funds are sent if you win a DLC
- change_address – this is the address where the change from the funding output is sent
Both the “payout_address” and “change_address” can be cold for the duration of the DLC. They are “receive-only” addresses in the DLC protocol. The payout address and change address should not be the same and not reused in the future so you can preserve your privacy.
The “funding_pubkey” is required to be hot during the setup process of the DLC, but can be moved to cool or cold storage after the setup process is done. Since this key is 1 of the 2 public keys in a multisig output, if it is solely compromised, an attacker cannot steal funds without colluding with your counterparty.
The winner of the DLC also does not need to have easy access to “funding_pubkey” in order to settle their bet. This is because the user already produces adaptor signatures for all cases of the bet for their counterparty. Once he has created and stored these adaptor signatures, the “funding_pubkey” can be moved to cold storage.
When it comes time to claim the winnings of the DLC, the user will adapt both their signature and their counterparty’s signatures to produce two valid digital signatures that can be used to spend the multisig funding output. We do not recommend this, but you could even delete the private key that corresponds to the “funding_pubkey” and settle the contract after both adaptor signatures have been produced.
For a 3rd party attacker to steal funds from your DLC — given a trustworthy oracle — they must collaborate with your counterparty. If you win the bet, and your funding_pubkey is compromised, but your “payout_address” is NOT compromised, the attacker cannot steal your funds. The attacker needs collaboration with your counterparty in the DLC to steal funds.
In the case that your attacker is the same as your counterparty, there is nothing you can do to mitigate loss of funds if the attacker gets access to your “funding_pubkey”. This is because they can then trivially spend from the 2 of 2 multisig that funds the DLC.
There is another private key users of a DLC must be concerned about. This private key is used by the oracle to sign the winning outcome of the event. For instance, he might sign the message “Democrat_win” in the case the democrats win the 2020 United States Presidential election.
A signal the DLC user can use to determine how serious the oracle is taking key management is how many events is the oracle signing with the same private key? Is it just 1 event? Or is it hundreds of events? This is easy to detect by looking to see if the oracle’s public key is static across events. If the oracle’s private key is compromised, and that private/public key is static across hundreds of events, all users of those events have to worry about the oracle publishing incorrect results that may cause loss of funds.
In this blog post we have covered what private keys are involved in a DLC, and what key management policies can be applied to these private keys. Our goal is to architect a safe protocol that allows for speculation directly on top of bitcoin. Next week we will be writing about private key management from the oracle’s perspective. If you want to read more DLCs please see
- Our previous blog post series
- The open source specification