Possible counterparty risk with timelocks

[fedsten]

To mitigate counterparty risk in the scenarios N2 and N3 as described in the protocol overview, timelocked conditions are used in the outputs of the funding transaction and of the HTLC settlement transaction, one to protect Bob in the case Alice is unresponsive and one to protect Alice in case Bob is unresponsive. The problem I see with the current scheme is that if Alice's timelock expires first, Alice can avoid paying Bob (assuming she is not interested in the service anymore) and redeem the reward before Bob can redeem with his timelock. Similarly, if Bob's timelock is the first to expire, he can just redeem the reward without providing any service before Alice is able to do anything with the HTLC's timelocked output.

Probably, the only solution to this problem is to implement lightning based payments so that Bob can receive frequent micropayments while providing probabilistic proofs that he is still storing the data. In this way, as soon as Alice stops paying for the service, he can stop storing the data.

[fiatjaf]

That doesn't prevent him from

1. faking the proofs until he gets caught, getting some free profits in the meantime;
2. withholding the data when Alice asks for it.

[fedsten]

From my understanding:

1. Faking proof is very difficult as Alice can ask for random pieces of the data Bob is storing, being able to verify that they are part of the Merkle tree representing the whole stored data set.
2. If Bob doesn't provide the data when asked by Alice, he will not get the final reward, which should be a consistent part of his total compensation.

[fiatjaf]

1. Ok, yeah, that could be very difficult.
2. That's what you just said: the one who has the timelock on its size can just do nothing, ignore the other's requests and just wait to get its money back. I was assuming it was Bob, but the README isn't very clear about this. It says both parties are protected which is impossible.

[fedsten]

Here I am assuming that Alice has the timelock on her side in case Bob never provides the decryption key, Bob receives regularly micropayments via LN from Alice to make sure that Alice is still interested in the data and committed to have them back eventually. This should also mitigate the risks of spam attack, with people asking to store large amount of data, and then just wait for their timelock to expire to get the money back.

[fiatjaf]

I think that's an improvement, but doesn't solve the fundamental problem.

Since Bob has to deposit a stake Alice can just do nothing and gain that.