Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Open Research Question] Free Options Problem: Enforce short Timeouts for Swaps #881

kilrau opened this Issue Apr 11, 2019 · 0 comments


None yet
1 participant
Copy link

commented Apr 11, 2019

Closed the previous issue since at that time our understanding of the Free Option Problem (FOP) was rather limited.

Motivation/Problem description: Read this or watch this, this for the full mailing list version.
In short: the preimage holder (in our case the taker) can delay the release of preimage from t0 to t1 and watch the market in the interval [t0, t1] and decide at t1 if the swap price is still better than the market or not. Release preimage if yes, fail the swap if no. This creates a free financial option for the preimage holder and is fatal for the non-preimage holder since her funds are locked up for the interval [t0, t1].

This issue is to collect discussion and research IF it is theoretically possible to enforce <block (e.g. 10 seconds) timeouts for payment channel atomic swaps and to enforce releasing amounts in the HTLCs of the swap. Enforcing means the protocol or honest party can enforce this timeout without the other party responding/cooperating. This doesn't include punishment/penalties and solves the FOP by rendering exploiting the option worthless through limiting the time to a couple of seconds.

  • Let's assume we have a timeout from accepting a dealRequest to preimage release of 10s.
  • Collaborative timeouts are already handled by xud: #786 implements collaboratively cancelling a trade and release order amounts in xud after timeout of 10s after accepting deal. After 30s if preimage is not released. This only works if both parties follow the protocol and don't hold onto the HTLC. This should only be triggered in some extreme conditions like network delay, but with both parties cooperating and following the protocol.
  • This issue is about unilaterally cancelling a trade (after reaching 10s timeout) from swap/HTLC perspective: the assumption is that the other party is not responsive/doesn't cooperate. Currently the non-preimage holder can decide between waiting for preimage holder to finalize the trade or cancel the trade by uncooperative channel close and a lengthy 7 days cltv waiting time to get funds back. Both not very nice options.

@kilrau kilrau self-assigned this Apr 11, 2019

@kilrau kilrau added this to the 1.0.0 milestone Apr 11, 2019

@kilrau kilrau added the swaps label Apr 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.