[Lightning-dev] Payment and Refund Stuck

Rusty Russell rusty at rustcorp.com.au
Thu Sep 24 05:56:30 UTC 2015

Mats Jerratsch <matsjj at gmail.com> writes:
> 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.

Yes, I think it was Joseph Poon who suggested it.  I'm keeping it in
reserve for the moment, in case this becomes common enough that we need
to code up a solution.

Your criticisms are valid, AFAICT.


More information about the Lightning-dev mailing list