From matsjj at gmail.com  Tue Sep 22 17:55:26 2015
From: matsjj at gmail.com (Mats Jerratsch)
Date: Tue, 22 Sep 2015 18:55:26 +0100
Subject: [Lightning-dev] Payment and Refund Stuck
Message-ID: <CAE8CtVmYHJ0WG+Wk8waCnUo7P0P426zEh-eEDhhnmy6O-QohdA@mail.gmail.com>

So far my impression was that an attacker that only stops one payment
is just a nuisance, as the system can self-correct. The payer and
payee can set a timeout. If the payment has not arrived after the
timeout the payee can issue a refund back to the payer. The refund
will pay to the same secret hash as the initial payment, and it will
pay an amount that is sufficient such that the payer will receive his
initial payment completely back. (That is, he might end up paying more
refund than actual payment)

When the payer does receive the refund in his channel, he can be sure
that the payment got invalidated. The payee must not reveal the
secret, and even if he does, the funds will just circle back again.
(plus the payee will pay fees for both transactions as a disincentive)
This concept has been around already, at least I read it somewhere.
However, I recently thought about it and got a couple of unresolved
issues:

(1)
How do we resolve the complete chain to remove both, the refund and
the payment completely? Do we just wait until they timeout? This does
not seem very efficient and it would maximise the damage the attacker
would do to the network - that is, he is locking up the payment amount
for N1 nodes on the first route and N2 nodes on the refund route for
the maximum amount of time. I thought about letting the nodes resolve
this on their own, but this would need cooperation from the very node
that isn't relaying the payment in the first place.

Lets assume A wants to pay E, and it chose the route

A->B->C->D->E.

However, C is uncooperative in that he does accept the payment in the
channel he has with B, but he is not relaying it further to D. (for
whatever reason)
So we end up with
A->B->C

Now the timeout hits and E is making the refund payment

E->D->F->B->A

with the same secret hash.

A and B can resolve this, both payments are the same amount (as
described above), so the payments net-worth is zero for both parties.
Now B has a binding payment towards C for X-a bitcoin, and he receives
X+a bitcoin from F. (with some fees a)
>From the point of view of B, this is just a normal payment from F
towards C with 2a in fees. And while B can drop the payment he gets
from F (they can just update the channel and remove the payment if B
agrees), he still has a binding agreement towards the payment to C.
Without C agreeing to drop the payment as well, B isn't in the
position to drop the payment towards F, keeping up the complete chain.


(2)
How do we resolve the case, where the refund gets stuck as well? Let's
assume the same case as above, but this time F is uncooperative too.
We end up with two chains of payments, where both payees don't get the
payment:

A->B->C
E->D->F

where C and F are both uncooperative. From the point of view of A, he
has made a final payment that he cannot revoke on his own. He further
has made the payment due to some contract, to which he expects some
kind of service/good. Waiting out one day till the lightning timeout
might not be an option for A.
The same is true other way round, where E has issued the refund and is
awaiting a new payment. Both parties can not sufficiently prove to the
other party they haven't received the payment, and even if they could,
the initial payment could still route correctly after some delay while
the refund doesn't.

Thinking about it, I guess E could give out multiple refunds via other
routes, until one finally arrives at the payer. As he is obliged to
not reveal the secret anyways, these are just for resolving the issue
at hand. However, this would again maximise the damage, as all
additional refunds would need to timeout. Furthermore, a malicious
payer could just claim he never received any refund, locking up lots
of funds of the payee with very few efforts...