Using Bitcoin-compatible BLS signatures for DLCs

chapter1:Using Bitcoin-compatible BLS signatures for DLCs(this post)
chapter2:Study of Pairing based cryptography BLS signatures, ID based encryption
chapter3:Deep dive into Cryptographic Oracle-Based Conditional Payments

Recently, Lloyd Fournier posted to the DLC-Dev mailing list about the benefits of having a oracles make their attestations using Boneh-Lynn-Shacham (BLS) signatures linking to a paper he co-authored.
In this blog, we will explain the abstract and benefits of this proposal.

What are DLC(Discreet Log Contracts)？

Discreet Log Contracts (DLC) were proposed by Tadge Dryja in 2017, a researcher at the MIT Digital Currency Initiative, and enable the establishment of derivatives and other types of contracts on the Bitcoin blockchain. The outcome of the event is attested by a third party entity called the oracle.

Simpler and stateless Oracles

The proposal is primarily a change to the oracle. The proposed oracle signature scheme is BLS signatures.This proposal involves the following changes for oracles;
1. Oracles no longer need to publish public nonces ahead of an event (e.g. BTC/USD)
2. Oracles can attest to events on demand, making it possible for clients to request oracles to attest to specific events.

1. No need for nonces published ahead of time
The current oracle attestation scheme is based on Schnorr signatures, which require a nonce pair in addition to a key pair . BLS signatures do not require such a nonce. Current DLC oracles publish a public nonce and pre-commit to specific events. With this new proposal they would just need to publish a public key.

2. Oracles can attest to events on demand
Using the proposed approach, oracles can attest to events upon receiving a request from a user. The request could be a program source code that gets and processes specific market data via an API(e.g. averages of BTC/USD Spot via https://ftx.com/api , https://www.bitmex.com/api).
An Oracle would run such a program and generate a BLS signature over the returned value. This approach also allows removing the use of an oracle in case of cooperative users. For example, users could run the program themselves and, if they agreed on the outcome, settle the contract cooperatively without involving the oracle at all. If they didn’t agree, any one of them could send the program to the oracle (perhaps with a small payment for its service) and receive back the attestation they need to close the contract.
This proposal could thus simplify the oracle work as “run the program and make an attestation for returned value”.

Next chapter, we will dive into the technical details.