📅 Original date posted:2015-06-27
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> Stephen <stephencalebmorse at gmail.com> writes:
>> Quick question on the security of the Lightning Network when rerouting payments.
>
> Hi Stephen,
>
> This is a good question!
>
>> Say A wants to make a payment to E, and they find a payment channel route through A->B->C->E. The payment is done in increments of 0.01 BTC until the full 1 BTC has been paid. However, part way through the payments, C becomes unresponsive. The contract has already been given to C that guarantees payment if C can produce the pre-image of a certain hash, and C does receive the pre-image from E. They do not share that pre-image with B, though. C must reveal the pre-image, either to B directly or on the blockchain, before B's contract times out, which guarantees B will receive payment.
>>
>> But A has not paid the full amount to E yet when C became unresponsive. A wants to re-route her payment to avoid delays, so she re-routes the rest of the payments through A->B->D->E. A finishes the payments through this alternate route. But now, can't C reveal the pre-image to B, who then reveals it to A? Which, will effectively steal an extra 0.01 BTC from Alice and give it to E. (C and E could have been colluding to do this, splitting the profits).
>
> Each of the messages needs a separate preimage.
Oops, sorry. Scrap my dumb non-answer, I read your post properly now.
Yes, C can just get the preimage from E and collude to steal the funds,
which is a nasty failure mode.
Delaying the entire payment is a poor option; can anyone see a better
one?
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:43:28
in reply to nevent1q…37u9
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:43:28Event JSON
{
"id": "0af712f77542553b004ba36bc6dc8349767fd9c444416018f3094e532e717672",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314608,
"kind": 1,
"tags": [
[
"e",
"b5a4560f419282095ad57f2a9ac310cd40add3b1559ac3db1c3f177ce7bbed7c",
"",
"root"
],
[
"e",
"3c0adca195de90d81642cc5db76167e6acd2b40265924877e31e8b0c12d7512b",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-06-27\n📝 Original message:\nRusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e Stephen \u003cstephencalebmorse at gmail.com\u003e writes:\n\u003e\u003e Quick question on the security of the Lightning Network when rerouting payments. \n\u003e\n\u003e Hi Stephen,\n\u003e\n\u003e This is a good question!\n\u003e\n\u003e\u003e Say A wants to make a payment to E, and they find a payment channel route through A-\u003eB-\u003eC-\u003eE. The payment is done in increments of 0.01 BTC until the full 1 BTC has been paid. However, part way through the payments, C becomes unresponsive. The contract has already been given to C that guarantees payment if C can produce the pre-image of a certain hash, and C does receive the pre-image from E. They do not share that pre-image with B, though. C must reveal the pre-image, either to B directly or on the blockchain, before B's contract times out, which guarantees B will receive payment. \n\u003e\u003e\n\u003e\u003e But A has not paid the full amount to E yet when C became unresponsive. A wants to re-route her payment to avoid delays, so she re-routes the rest of the payments through A-\u003eB-\u003eD-\u003eE. A finishes the payments through this alternate route. But now, can't C reveal the pre-image to B, who then reveals it to A? Which, will effectively steal an extra 0.01 BTC from Alice and give it to E. (C and E could have been colluding to do this, splitting the profits). \n\u003e\n\u003e Each of the messages needs a separate preimage.\n\nOops, sorry. Scrap my dumb non-answer, I read your post properly now.\n\nYes, C can just get the preimage from E and collude to steal the funds,\nwhich is a nasty failure mode.\n\nDelaying the entire payment is a poor option; can anyone see a better\none?\n\nCheers,\nRusty.",
"sig": "fe7743dc6a9d5a30add6e1a8f420b10626b4daea654677188ee23cd3e15e201dcf0a565947c1d3bb32a898c4c02c9efcf051604ea13da0c70e0b7560621ae3e9"
}