feat(relay): report double payment

[gregdhill]

Signed-off-by: Gregory Hill gregorydhill@outlook.com

See: https://spec.interlay.io/spec/relay.html#reportvaultdoublepayment

[gregdhill]

It might be cleaner to store the Bitcoin txId on redeem / replace / refund execution and remove this new function. What are your thoughts @sander2 @nud3l?

[sander2]

It might be cleaner to store the Bitcoin txId on redeem / replace / refund execution and remove this new function. What are your thoughts @sander2 @nud3l?

As mentioned on discord, if a vault makes 2 payments, and then uses the second payment for execute, the first block must be checked and reported by the clients after the execute.

[gregdhill]

Either way this will be difficult to implement client-side, but the advantage of the alternate approach is that the data model is cleaner, each request is strongly linked to a single transaction ID and we would only require one function call to report theft.

[sander2]

Either way this will be difficult to implement client-side, but the advantage of the alternate approach is that the data model is cleaner, each request is strongly linked to a single transaction ID and we would only require one function call to report theft.

But it wouldn't be able to catch everything. What if the vault just makes multiple payments without ever executing the redeem?

[gregdhill]

Either way this will be difficult to implement client-side, but the advantage of the alternate approach is that the data model is cleaner, each request is strongly linked to a single transaction ID and we would only require one function call to report theft.

But it wouldn't be able to catch everything. What if the vault just makes multiple payments without ever executing the redeem?

Good point, it would need to be executed before we could mark it for theft which isn't ideal - perhaps this is the optimal solution.

[nud3l]

I like this approach. You could use the storing of the BTC tx id on redeem in combination flagging it as theft if it has not been executed after the redeem period expired. But I think this is cleaner since it does not introduce extra logic in redeem and kind of shifts complexity to the clients.