Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-24 📝 Original message: Hi Mats, Yes, I agree ...
📅 Original date posted:2015-09-24
📝 Original message:
Hi Mats,
Yes, I agree whole heartedly! See my related comment here:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000018.html
Two hashes are necessary for this type of invalidation.
On Thu, Sep 24, 2015 at 03:26:30PM +0930, Rusty Russell wrote:
> 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.
Yes, seems like something to tack on later.
--
Joseph Poon
📝 Original message:
Hi Mats,
Yes, I agree whole heartedly! See my related comment here:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000018.html
Two hashes are necessary for this type of invalidation.
On Thu, Sep 24, 2015 at 03:26:30PM +0930, Rusty Russell wrote:
> 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.
Yes, seems like something to tack on later.
--
Joseph Poon