[Open Research Question] Free Options Problem

[kilrau]

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: https://github.com/ExchangeUnion/xud/pull/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]

In the meanwhile @renepickhardt described a way how to do away with the Free Option with a CFD on LN and having an Oracle constantly providing rates for which the swap would settle. Meaning if I start a swap at t0, but settle only at t1, I will get the rate from t1, not t0.

https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC

[kilrau]

Update:

• short-term approach is to add reputation scores for a peer's nodekey (which can assumed to be permanent) based on experience we gather during a trade.
• mid-term approach could be to split trades into small trades accross different peers to reduce free option assuming the majority of peers is well-behaved
• long-term approach still open

[sangaman]

Replying to https://github.com/ExchangeUnion/xud/issues/1558#issuecomment-629139258

Breaking swaps into smaller swaps with different peers to reduce free option exposure is an entirely different topic indeed. It's a viable approach though and I left a comment mentioning this approach here - let's move the discussion there. TL,DR: it's not trivial, since xud would need to decide when to prefer worse pricing for the sake of spreading trades across multiple peers, but we can consider it mid-term (after June). Let's continue discussing it in the coming weeks.

I don't think there's any need to deal with different peers or to accept worse prices. If we match an order for 100,000 satoshis, instead of a single 100k sat swap, we could do 100 1k sat swaps sequentially. It would likely mean slower execution, or possibly partial execution (which generally speaking is fine and preferable to zero execution), but not worse pricing (except for potentially slightly higher fees since there's a fixed forwarding fee in addition to a percentage fee)

The size of each swap could also increase gradually for a certain order and/or be tied into reputation scores - in other words you're willing to risk larger HTLCs with nodes you know and have swapped successfully with previously.

breaking HTLCs into smaller ones to increase routing/payment success is only relevant on lightning for now since connext will be "one channel with the same node" for the coming months
and even on lightning we are optimizing for a "one channel with one LSP" experience in the short term too, in line with the connext experience. So the above "balance in multiple channels" problem won't occur in the default setup and since it's two hops with the LSP in the middle, payment should be fairly reliable.
for the power market makers who do have more than one lightning channel for the same currency, MPP will solve using balance of multiple channels, automatically breaking a trade into smaller multiple htlcs via different routes without us changing a thing (apart from maybe adding max_parts to the sendpayment calls on lnd)

These are fair points on the split balance/partial execution question but I don't believe they address the free options problem.

[michael1011]

It would likely mean slower execution, or possibly partial execution (which generally speaking is fine and preferable to zero execution)

That depends on what you are trying to do. There are cases in which you want the full order to go through or nothing at all.

[kilrau]

That depends on what you are trying to do.

Agree, in quite some cases sequential might not be wanted. If I am in a hurry to get the top of the order book best price with a peer I trust/have good experience with.

There are cases in which you want the full order to go through or nothing at all.

That's a new order type though (AoN), which we don't support as of now (but should at some point).

[kilrau]

Moved to https://github.com/opendexnetwork/opendex/issues/25. Closing here.