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

[Nadav Kohen]

Hey Sachin,

It seems you have joined the select few who have discovered the barrier
escrow!

https://suredbits.com/payment-points-and-barrier-escrows/

My favorite use case has been
https://suredbits.com/updating-and-transferring-lightning-payments/
although I think there are others too that have come up which is exciting
because using barrier escrows across use cases improves privacy!

That said, I hadn't thought to apply them here! And it certainly seems like
a good option when a fast confirmation is important or double spending
funding isn't considered acceptable :) it likely has the downside of
introducing a little bit of added latency in the average setup, but could
definitely still be worth it.

I'll note that a particularly nice implementation of a barrier escrow that
comes with built in privacy issue mitigation is via Lightning once we have
PTLCs instead of HTLCs (though there is a more trusted version using HTLCs)
where the parties involved pay an AMP to the barrier escrow who then can
only accept all the payments once all have been set up. The payment
preimage can then be used to decrypt.

More details here:
https://suredbits.com/payment-points-implementing-barrier-escrows/

Best,
Nadav


On Mon, Mar 13, 2023, 11:43 AM Sachin Meier via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> 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
>
>
> dlc-dev mailing list
> dlc-dev at mailmanlists.org
> https://mailmanlists.org/mailman/listinfo/dlc-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20230313/b4b72505/attachment-0001.htm>