Provide a receipt for payments

[hackaugusto]

Problem

Our current approach is to let the payer choose the secret instead of the payee, this means that a secret reveal cannot be used as a proof of payment, since the payee may say "I never received the secret".

Shifting the task of secret generation from the payer to the payee is a sufficient way to produce the receipt (the secret itself is a prove that the payment happened), but we lose the ability to retry the payment with different routes under timeouts.

Proposed solution

We can add a different composed lock to Raiden, built from these parts:

• A payer retry hashlock, this hashlock may be regenerated at will by the payer, allowing him to try different routes as timeouts happen.
• A payee receipt hashlock, this hashlock encodes the receipt from the payee, initially a hash of random secret seems sufficient.
• A time lock, used for the lock expiration controlled by the payer.

To unlock the transfer both secrets are required. This ReceiptHashlock has additional protocol requirements:

• The payment must be initiated by the payee, the payee sends a payment request to the payer with the receipt hashlock
  • The payee doesn't need to choose the expiration time of the lock, as this is route dependent and the payee can discard the receipt secret without risk of losing tokens. Additionally the payee will need a method to decide when the secret should be discarded, I think it's sufficient to do health checks and use a configurable local expiration for the payee.
• The payer uses the receipt hashlock and it's own retry hashlock to create the mediated transfer, the retry hashlock may be regenerated as new routes are tried.
• Once the payee receives the MediatedTransfer a SecretRequest is sent to the payer, the receipt secret is not revealed yet.
• The payer reveal it's secret, the end result is that the payee will have more information than the payer, but it's the payee interest to receive the tokens, so this disparity is no problem (whereas the opposite is not true, the payee may not reveal the receipt secret first, as that says "the payment happened" and the payer may just not reveal the retry secret).
• The payee reveals the receipt secret once the retry secret is learned.
• The secrets propagates from back to front as usual.

[hackaugusto]

Question: Can we have a receipt for an atomic swap operation?

[hackaugusto]

Alternative: Instead of having two hashlocks, we can build a lock with an unlock condition were both the secret is revealed and there is a signature of the target for the given secret.