Naively usingN HTLCs introduces an inadvertent American Call Option

This is some early feedback from a potential auditor for OmniBOLT:

I saw in the https://omnilaboratory.github.io/obd/# that you advertise as feature the ability to swap different token types.

Note that if this is implemented naively using HTLCs, you introduce an inadvertent American Call Option.

See here https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

There may be mitigations against this, though I have not kept track on the state-of-the-art on this problem; I hope you have?

Looking at https://github.com/omnilaboratory/OmniBOLT-spec/blob/master/OmniBOLT-05-Atomic-Swap-among-Channels.md#hashed-timelock-swap-contract

It seems you do use the naive form, the one that is susceptible to the American Call Option problem I pointed out about.

This is fine for an initial implementation when you have no serious activity yet, but note that you should at least think of how to upgrade to a later mechanism that is safe against the American Call Option problem.

Barrier Escrows (which become feasible once we implement PTLCs on Lightning Network) are a good solution, I believe: https://suredbits.com/payment-points-and-barrier-escrows/

So all you need now is to ensure some kind of upgrade mechanism that lets you switch to using Barrier Escrows later and deprecate the current mechanism.

omnilaboratory / obd

Naively usingN HTLCs introduces an inadvertent American Call Option #43