Deep dive into Cryptographic Oracle-Based Conditional Payments
chapter1:Using Bitcoin-compatible BLS signatures for DLCs
chapter2:Study of Pairing based cryptography BLS signatures, ID based encryption
chapter3:Deep dive into Cryptographic Oracle-Based Conditional Payments(this post)
In the previous chapter, we learned the pre-requisites for “Cryptographic Oracle-Based Conditional Payments” and the basics of pairing based cryptography.
This chapter describes the technical details. We first recall adaptor signature based DLC.
Adaptor signature based DLC
Adaptor signatures are encrypted signatures σ’. The decryption key is y_m, while the encryption key is Y_m(y_m×G).
DLC users encrypt their signatures with Y_m(y_m×G), and decrypt it with y_m as follows:
Please see the blog below for details of calculation and verification of signature of DLC transaction σ_m.
・Adaptor signature on Schnorr
・DLC Transaction
ID based encryption revisited
ID-based encryption and Adaptor signatures based DLC have common properties;
- A trust point exists
ID-based encryption requires a private key generator, DLC requires an oracle. - The Encryption key is created from public data
ID-based encryption key requires an ID (e.g. a mail address), DLC adaptor encryption key requires an event (e.g. BTC/USD Spot) - The decryption key is created from a trust point
ID-based decryption key uses BLS signatures of a private key generator, adaptor signature in DLC uses an oracle attestation.
So let’s replace each element in the ID-based encryption as follows;
・Private key generator → Oracle
・ID → event（e.g. BTC/USD Spot）
・ID-based Decryption key → Oracle attestation(BLS signature on event)
Now we have a new oracle signing scheme as follows:
oracle setup
1. oracle generates a key-pair
Contract execution
2. Alice and Bob agree on the DLC terms and oracle’s public key and then create the “ID based encryption keys” QID_m which are based on conditions of the event m (e.g. BTC/USD Spot)
3. Alice(Bob) creates adaptor signatures and Bob(Alice) verifies them
4. Alice(Bob) encrypts “Adaptor signature decryption key” y_m with ID based encryption scheme (encryption key is QID_m and decryption key is oracle BLS signature dID_m)
5. Bob(Alice) verifies cipher text
6.Both lock their funds on the blockchain
Settlement at maturity
7.Alice or Bob requests the oracle to attest to the event m and the oracle creates a BLS signature dID_m
8.Alice or Bob decrypts a ciphertext with dID_m and gets the “Adaptor signature decryption key” y_m, with which they can decrypt an adaptor signature and broadcast a settlement transaction.
In 4. above, Alice(Bob) has no way to prove that a ciphertext c_m is created correctly without the knowledge of “Adaptor signature decryption key” y_m , so she(he) creates other ciphertexts, “Sym-cipher” and “BF-cipher” for each m instead of ciphertext c_m.
Alice (Bob) creates n versions of “Sym-cipher” and “BF-cipher” for a particular m. Note that the following is written for a specific m.
Sym-cipher and BF-cipher
Sym-cipher and BF-cipher are cipher texts that enable Bob(Alice) to extract the “Adaptor signature decryption key” y with oracle BLS signature dID
Sym-cipher
Sym-cipher s is the encrypted y. The encryption scheme is a simple addition and the encryption and decryption keys are the same r.
BF-cipher
BF-cipher B is encrypted r.The encryption scheme is ID based encryption and encryption key is QID which are based on conditions of the event m (e.g. BTC/USD Spot), decryption key is oracle BLS signature dID.
When Bob(Alice) gets the oracle BLS signature dID, he decrypts BF-cipher and extracts r, then decrypts sym-cipher and gets y as below.
*Details of the ID encryption scheme (IDEnc/IDDec) can be found in “Study of Pairing based cryptography BLS signatures, ID based encryption”
We learned that Bob (Alice) can extract y with the oracle attestation by receiving the sym-cipher and BF-cipher from Alice(Bob) instead of receiving encrypted y with ID based encryption.
Note that Bob(Alice) has no way to verify if the ciphertext is created correctly with ID based encryption scheme without knowing the original message, so “cut-and-choose technique” is used for verification.
Cut-and-choose technique
The basic idea of cut-and-choose technique is that one party constructs n versions of a message in a protocol (n version of sym-cipher and BF-cipher instead of encrypted y in this case it is ); the other party randomly checks some of them and uses the rest of them in the protocol. Each cipher text is verified as follow:
1.Alice (Bob) creates n versions of sym-cipher s_i and BF-cipher B_i for a particular m.
2.Alice(Bob) sends B_i to Bob(Alice) and Bob(Alice) randomly chooses some of them.
3.For all selected j, Alice(Bob) pass r_j , u_j and Bob(Alice) create B_j as follows
4.For all non-selected k, Alice(Bob) pass sym-cipher s_k and Bob(Alice) verifies as follows:
If all of s_k is correct, Alice convince Bob that he will be able to get y with BF-cipher B_k and oracle attestation dID as follows:
We learned that we can encrypt an Adaptor signature decryption key using verifiable identity-based encryption and decrypt it with oracle attestation(BLS signature).
Key generation, encryption and decryption are performed as follows.
Cryptographic Oracle-Based Conditional Payments Scheme
Based on the above, the flow of the BLS-based DLC process is described below.
*Details of the ID encryption scheme (IDEnc/IDDec) can be found in “Chapter2:Study of Pairing based cryptography”
Further development
The paper also mentions how to perform cut and choose non-interactively using Fiat-Shamir heuristic, and also how to create a multi oracle signature scheme using Shamir’s Secret Sharing and batching verification.
Conclusion
The BLS based DLC does not require oracle commitment to a specific event, so oracle work is simple and stateless.
We need to be careful about its implementation, because pairing functions are complicated and there is no de facto standard.
Anway, we are very excited about this unique and powerful proposal. We hope these will be actively discussed and considered for application to the DLC.
Acknowledgements
Thanks to Lloyd Fournier, Thibaut Le Guilly for helping me understanding this proposal.
