Onchain DLCs and their setup currently face a free option problem when signing the funding transaction. The typical flow for setting up a two party DLC is as follows: 

1. The Oracle publishes a nonce point and event info about an event to which it will later attest. 

2. An Offerer creates an offer with details about the bet and the coins it wants to use for the bet.

3. An Accepter accepts those terms and replies with encrypted-signed (using the Oracle's nonce point) CETs. These are adaptor signatures not valid Schnorr signatures. 

4. The Offerer responds with a partially signed funding transaction. Only the offerer's signatures are added to the transaction. These are real, valid signatures. 

5. The Accepter adds their signatures to the funding transaction and broadcasts it. 

The free option is available to the accepter after step 4, when the accepter has the offerer's signatures. The accepter can sit on the unbroadcast funding transaction and watch conditions for the bet change. 

It should be noted that there is a soft expiry on exercising the free option: The refund transaction locktime. Once the refund transaction is valid, the accepter no longer has a guaranteed ability to publish the funding transaction and a favorable CET. However, by this time, the Oracle should have published or failed permanently to publish their attestation, meaning the accepter would have had ample time to execute the contract favorably already. 

The root of the problem is that the two parties must learn one another's funding transaction signatures at the exact same time.  

One solution here is to use an ad hoc Oracle and adaptor signatures (just like the DLCs themselves). Here, the offerer and accepter will make authenticated requests to an oracle for a shared custom nonce point.

Each of them can then encrypted-sign the funding transaction and share the encrypted signatures with one another. Neither party is capable of broadcasting the transaction yet, since they cannot decrypt one another's signatures. 

Once a party has received their counterparty's adaptor signatures for the funding inputs, they submit another authenticated request to the custom Oracle to release the tweak. Once the Oracle has received both requests for release (one from the accepter and one from the offerer), the Oracle can share the tweak with the two parties, allowing them to decrypt their counterpartys signatures at the same time, or at least, without significant delays assuming both parties can maintain a connection to the Oracle and the Bitcoin network. 

Without in-depth analysis, I believe the security risks of a DoS on a party attempting to receive the Oracle tweak and decrypt the funding transaction signatures are insignificant. If an attacker has the ability to DoS a victim, it has access to a free option whether or not the funding transaction is broadcast, because it can DoS the victim to stop them from receiving the event attestation and  decrypting a CET signature. 

## Privacy viz-a-viz the Custom Oracle:

Like the DLC Oracle, the custom Oracle does not require any knowledge of the DLC contract or data being shared. It needs a method of authenticating the reveal request from both parties, but it doesn't need to know anything else. 

It most likely makes sense to use a different service for custom Oracles and the DLC Oracle in order to reduce the likelihood that an Oracle can use timing analysis to link the custom Oracle request to a DLC contract being built. 

Authentication to the custom Oracle should also avoid using any keys or other data related to the funding tx, CETs, or refund tx as this would link the request with a later-visible onchain footprint. 

## Future Work & Implementation

I plan on implementing this using a single use private key which will BIP340 sign some message for initial setup and reveal requests respectively.

I will call the initial request a Nonce request and the second request (made upon receipt of a counterparty's singatures) a Signature Request. 

## Other Use Cases

If needed, this same ad hoc Oracle concept can be reused for other situations in which two parties must atomically swap signatures and where significant differences in when the two parties receive the signatures can have a financial impact. For Lightning-Lightning swaps, this might be useful, for example, if a stablecoin and Bitcoin need to be swapped on parallel channels with minimal free option time. 

Any feedback on this idea is very welcome. I have not seen other proposed solutions to the free option problem for onchain DLCs, and if I missed some would love to be made aware of them. 

Sincerely,

Sachin Meier