[dlc-dev] Solving the Free Option Problem for Onchain DLCs Inbox

[Sachin Meier]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20230313/a26656bd/attachment.htm>