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 distribution of oracle keys from the oracle to users.
For reference, here are links to our previous blog posts
In the previous blog post we detailed the two pieces of information we need to receive from the oracle to enter into a DLC.
- The oracle’s public key
- The oracle’s nonce
These pieces of information are contained in something called an oracle event descriptor.
The problem is this:
After an oracle issues a valid event descriptor, how do we distribute the event descriptor in a secure way. This information is susceptible to man in the middle attacks (MITM). The attacker could replace the oracle’s public key with their own and now have complete control over the settlement of your DLC.
DLCs today use centralized venues like twitter to distribute oracle event descriptor. If you look at the OutcomeObservers twitter page, you will see his public key for all events, and the nonce for the election bet.
Recently twitter was hacked where the hackers solicited bitcoin payments through high profile accounts. The hackers could also theoretically replace the oracle’s public keys with their own without it being easy to tell.
This problem is exacerbated by distributed venues to propagate oracle’s key such as a peer-to-peer network. If I receive an oracle’s public key from a potential counterparty in a DLC, how do I verify they aren’t scamming me by replacing the real oracle key with an oracle key that they control?
Let’s go through an exercise and show how some ‘solutions’ could have some serious foot-guns.
The oracle could publish their non-hardened BIP32 extended public key. Now every oracle announcement they publish could have a public key that is a child of their extended public key. Now to verify that the oracle actually owns the public key users could derive the oracle announcement’s public key itself. If the derivation succeeds, the oracle owns the public key, if the derivation fails, the oracle does not own the public key. Simple enough.
However BIP32 has a caveat to it, quoting from BIP32
“One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.”
So our design goals of this BIP32 scheme are:
- We are proposing using BIP32 so we can have independent private keys
- We said in our previous blog post users should care that private keys are independent so their DLCs have a higher probability of being safe in flight.
We are actually undermining (2) by using BIP32 because of the quoted weakness above. If a child private key is leaked accidentally from the keychain, an attacker can trivially reverse engineer the master private key. This means the attacker has compromised all DLCs that are associated with this BIP32 keychain which violates (1).
There is also the more simple case of an attacker just outright compromising the BIP32 master xpriv, which allows them to derive all child private keys.
Non Automated Communication with the Oracle
This solution is also relatively simple. This involves authenticating with the oracle itself that it did issue this public key. This is not automated and relies on human judgement to verify the authenticity of the oracle’s key. This could mean talking with the oracle or manually checking the oracle’s website.
Public Key Infrastructure (PKI)
The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. As stated in the “Problem” section, we need to securely distribute oracle event descriptors.
To reduce the problem of validating many oracle keys for every oracle, oracles can make use of a special identity public key. This key is not used for signing oracle events but rather the oracle uses this key to sign all of its other public keys to assert that they belong to that oracle. This way, validation of oracle public keys reduces to the validation of a single public key per oracle followed by the validation of signatures by that key which we already trust.
There are various types of PKI. One prolific example on the internet is a Certificate Authority (CA). This is how https is implemented on the modern internet. A CA attests to the fact that the public key you are encrypting your web data with is actually owned by the website you are visiting. In our case, a CA could attest to the fact that the public key associated with an event is actually owned by the oracle. It is important to note that you are introducing more trust with this scheme, you are trusting the certificate authority.
Another option is the Web of Trust concept. This is the technique PGP key exchanges use. This involves users or other oracles you trust producing signatures indicating that an oracle’s key is authentic. This means you do not need direct communication with the oracle, rather you are trusting this set of users and their ability to verify the authenticity of the public key associated with this oracle event.
There are other types of PKI such as Decentralized Public Key Infrastructure (DPKI). This avoids having a centralized certificate repository by using a blockchain to issue and store the certificate. This solution could be attractive for DLCs as users are already interacting with the bitcoin network.
Most rigorous PKI solutions should be sufficient for bootstrapping a DLC oracle ecosystem, although special care should be taken in choosing a PKI solution. The overall goal of such a choice should be to minimize the amount of added trust beyond standard DLC oracle trust. This makes schemes which allow us to re-use oracle trust appealing. That said, Public Key Infrastructure solves many problems in many areas of the internet so there are a large number of schemes to choose from, including those detailed in this post.
In this series of blog posts we detailed private keys that are involved in a Discreet Log Contract. We’ve also documented how oracle private keys could be compromised, and how that then could be used to fraudulently settle DLCs. Finally in this blog post we detailed the problem of oracle public key distribution.
For more information on DLCs you browse the specification repo here or by asking questions in our Suredbits slack.