📅 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
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:44:38
in reply to nevent1q…dwge
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:44:38Event JSON
{
"id": "6fb5371a1c42b55725aca017adb7c0f0c1e39a4458ef84e25e198eb240e68984",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314678,
"kind": 1,
"tags": [
[
"e",
"b5b57978740a799524f789c978ceee5f2bde61143922af5930a7f8658ef6ef76",
"",
"root"
],
[
"e",
"f4b4eb188c0b6bd974f149def4d64938058d2f5bc9724eb77e85bf514525384a",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-24\n📝 Original message:\nHi Mats,\n\nYes, I agree whole heartedly! See my related comment here:\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000018.html\n\nTwo hashes are necessary for this type of invalidation.\n\nOn Thu, Sep 24, 2015 at 03:26:30PM +0930, Rusty Russell wrote:\n\u003e Mats Jerratsch \u003cmatsjj at gmail.com\u003e writes:\n\u003e \u003e So far my impression was that an attacker that only stops one payment\n\u003e \u003e is just a nuisance, as the system can self-correct. The payer and\n\u003e \u003e payee can set a timeout. If the payment has not arrived after the\n\u003e \u003e timeout the payee can issue a refund back to the payer. The refund\n\u003e \u003e will pay to the same secret hash as the initial payment, and it will\n\u003e \u003e pay an amount that is sufficient such that the payer will receive his\n\u003e \u003e initial payment completely back. (That is, he might end up paying more\n\u003e \u003e refund than actual payment)\n\u003e \u003e\n\u003e \u003e When the payer does receive the refund in his channel, he can be sure\n\u003e \u003e that the payment got invalidated. The payee must not reveal the\n\u003e \u003e secret, and even if he does, the funds will just circle back again.\n\u003e \u003e (plus the payee will pay fees for both transactions as a disincentive)\n\u003e \u003e This concept has been around already, at least I read it somewhere.\n\u003e \n\u003e Yes, I think it was Joseph Poon who suggested it. I'm keeping it in\n\u003e reserve for the moment, in case this becomes common enough that we need\n\u003e to code up a solution.\n\nYes, seems like something to tack on later.\n\n-- \nJoseph Poon",
"sig": "26c27aebbc2fe20a6c25fd51213ec4f4765e85b9d5122376cae5ab8736cf0a2410298cb63feccf77a2493f3631594e928026bc2c207eb360478b30f1778c89b2"
}