[Lightning-dev] Proposal for Stuckless Payment

[ZmnSCPxj]

Good morning list,


> Another thought, is that this may also solve the "American Call Option" problem.
> In this case, the key at the final step is the sum of the payer key and the exchange key (`y0 + y1 + y2 + z` where payer knows `y0 + y1 + y2` and exchange knows `z`).
> Then intermediate nodes are unaware that a cross-currency exchange is involved.
> This thought, I will need to consider further for correctness.

I apologize for the noise, but after some thought, the free-premium American Call Option problem does not get helped by stuckless payments, at least by itself.
The general solution is for the exchange to require that it get paid the premium immediately, with the premium encumbered only by the exchange.

Below is a basic sketch.

* Payer requests the exchange for a public key `Z` such that `Z = z * G` where `z` is known only by the exchange.
  This should be done anonymously over Tor.
* Payer routes a payment via the exchange.
  * Payer provides a proof (somehow) to the exchange that the payee has to claim `P + Z + (y0 + y1 + y2) * G`, where payee knows `p` such that `P = p * G`, payer knows `(y0 + y1 + y2)`.
    * Invoice payment points must include a proof-of-knowledge (i.e. a signature using `P` must be included in the invoice, not just a payee signature attesting to the invoice details --- we do not want to give the invoice details and the payee pubkey to the exchange, lest it censor).
    * Payer can provide a signature with `(y0 + y1 + y2) * G`.
    * As signatures are involved, should we worry about key cancellation attacks on `Z`?
      I am not a mathematician.
    * Exchange should be able to identify the `Z` it released.
* Exchange validates, then performs the exchange.
* Payee sends `ACK` message.
* Payer pays the premium to the exchange, using `Z` as the payee key.
  It can use stuckless protocol (or not).
* Exchange claims the premium, making the American Call Option have a premium and thus rational for the exchange to accept.
  Payee learns `z`.
* Payer can now provide `key` message to payee, containing `(y0 + y1 + y2) + z`.

In effect, the proof-of-payment-of-premium is enough to let the exchange issue an American Call Option.

Payer and payee can still lock the exchange funds by not paying the option premium, but it is not an "option" since the payee cannot cause the cross-currency swap to push through without the exchange getting paid the premium.
The exchange can force a timeout on the premium payment `Z`, such that if it is not paid, the exchange will permanently delete `z`.
Alternately (and maybe better...) the exchange can force that the premium is paid *before* it performs the swap and propagates the payment onward.

(a detail, but I suspect the payer can also send a `cancel` message instead of `key` in response to `ACK`, for example if multiple parallel attempts are made and one of the other attempts has already completed; in which case if the exchange times out, an honest payee can just send thsi `cancel` message)

Regards,
ZmnSCPxj