Oracle Private Key Management
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 for the duration of their interaction with the protocol. This blog post focuses on key management from the oracle’s perspective.
The oracle in the DLC protocol plays a critical role in settlement of DLCs. When an event occurs, the oracle is responsible for signing a message that indicates what the state of the event is. For instance, when the United States presidential election occurs, an oracle (outcome observer for instance) would be responsible for signing “Democrat_win” or “Republican_win”. Users of the DLC can then take that digital signature from the oracle, and use it to settle their individual DLCs on the bitcoin blockchain.
The important thing to remember is that the oracle must commit to their private key and nonce before the event occurs. In the case of the election bet, an oracle can make their public key and nonce known months before the election occurs. Since the public key and nonce is committed to in advance, there are a few scenarios we need to worry about
- An oracle loses the private key corresponding to an event
- An oracle has their private key stolen
- An oracle leaked their private key by nonce reuse
Case 1: An oracle loses their private key
This is a relatively simple case. If the oracle loses the private key, the DLCs cannot settle. This means users will need to exercise the refund clause in their DLC. The current DLC spec has a refund transaction built into the protocol to protect against an oracle losing their private key. It is worth noting that this case is equivalent to the case where the oracle hasn’t lost their private key, but is refusing to publish a signed message.
Case 2: An oracle’s private key is compromised
When the oracle’s private key is stolen, all DLC’s predicated on this private key are at risk for fraudulent settlement. The entity that stole the private key can now sign any message it would like. As an example, the attacker could sign a message “Republican_win” when in reality the democrats won the United States election. This would mean the attacker has lied to all users of the oracle.
The attacker isn’t limited to just publishing a single signed message. The attacker can also publish conflicting messages. With our example, the attacker could simultaneously sign the message “Democrat_win” and “Republican_win”. Now users of the DLC can take the message that pays them the most money, and try to publish the bitcoin transaction that settles the DLC. This devolves to a race condition on the bitcoin blockchain.
This is why it is crucial that oracles take private key management seriously when dealing with DLCs.
Case 3: Leaking Private Key via Nonce Usage
DLCs take advantage of a unique property of digital signatures. If you sign multiple unique messages with the same nonce, you will leak your private key. This compromise is slightly different than the hypothetical we posed above. Above we assumed that the private key was stolen, and an attacker published conflicting messages. Unfortunately, it is not possible to cryptographically verify that an attacker or the oracle itself is publishing conflicting messages. An oracle may claim that an attacker has compromised the key and is publishing signed messages, but in reality it could be the oracle itself that is publishing these messages.
There is another form of nonce reuse which results from incompetence by the oracle. When an oracle creates an event, they must commit to two things upfront
- The private key
- The nonce
We’ve talked at length about the private key, but we have not talked much about the nonce yet. We assume that an oracle is likely to publish signatures for multiple events. For the sake of example, let’s assume that an oracle is attesting to the 2020 & 2024 United States presidential elections.
It is absolutely critical that the nonces for the 2020 & 2024 elections are independent from one another. There can exist no computable relationship between those two nonces. If there exists a computable relationship, it may be possible to reverse engineer the private key from two signatures. This is a problem as deterministic nonce generation is desirable to securely backup your oracle.
As an example, a popular standard in Bitcoin is BIP32 which is called “Hierarchical Deterministic Keychains”. This standard defines a tree structured derivation between keys in bitcoin. This standard must be used VERY carefully (only use hardened paths that involve hash functions) for deterministically selecting nonces.
It will be clear to users that a key is leaked slowly via bias nonces. The digital signatures published by the oracle can be used as evidence of this. Some oracles may even stake funds on the blockchain that are secured by the same public key that the oracle is using to sign for DLCs. This means if the private key is leaked, the funds will be moved, and users of the DLC can use this as a signal that the oracle’s key has been compromised.
If the oracle is using the same private key for many events, a DLC user can assume that the oracle has to access the private key to attest to each event. This means the likelihood of private key compromise is increased.
Similar to bitcoin addresses, if an oracle is using private keys for only a small number of events, the likelihood of key compromise is reduced. It’s also a good heuristic that the oracle takes private key management seriously. Using unique private keys for only a few events gives the oracle the ability to only access the private key when one of these events is completed. This allows the oracle to keep the private key in cold storage for the duration of the events reducing the likelihood of key compromise. It also means that some users are protected in the case where only some keys are compromised.
For the sake of argument, let’s assume that an oracle uses the same private key for every event it’s attesting to. Continuing on our example, let’s assume our oracle is attesting to the 2020, 2024, 2028,…,2100 United States Presidential elections. The oracle has said it will use the same private key to sign each of these outcomes.
Let us assume that the oracle’s private key was compromised in the year 2021. This means all DLCs for the 2024, 2028, …, 2100 elections are compromised. Conversely, if an oracle had used unique private keys for each of the elections, if one key is compromised, the damage is contained to that single event — the 2024 election — rather than propagating to other events.
In the future, industrial grade oracles will likely use technologies such as HSMs paired with proactive threshold secret sharing schemes to make their keys extra secure while still providing high availability to their keys so that they can rapidly sign events. To learn more about threshold signatures check out our FROST blog post [link] and to learn more about proactive secret sharing, see here. These schemes allow oracles to distribute their key material across multiple machines.
In this blog post we discussed oracle’s securing private keys for in flight DLCs. In the next blog post in this series we will talk about how to verify the authenticity of the private key you received from the oracle. Our goal is to architect a safe protocol that allows for speculation directly on top of bitcoin. If you want to read more DLCs please see
- Our previous blog post series
- The open source specification