📅 Original date posted:2015-06-27
📝 Original message:
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.
The simplest method is for E to simply provide A with (say) 100 hashes
to use as she wishes.
Though I think we can do better than this using crypto rather than
hashes, in practice producing 100 preimages is pretty easy (hash a
per-payment secret + counter).
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:43:28
in reply to nevent1q…9eah
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:43:28Event JSON
{
"id": "3c0adca195de90d81642cc5db76167e6acd2b40265924877e31e8b0c12d7512b",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314608,
"kind": 1,
"tags": [
[
"e",
"b5a4560f419282095ad57f2a9ac310cd40add3b1559ac3db1c3f177ce7bbed7c",
"",
"root"
],
[
"e",
"4960b2101701674d089b2988f30da202650120982bc7b5907826f81a6405b6d7",
"",
"reply"
],
[
"p",
"10238a6d0c6848c1acb963573a9db5f379583e293364361bd86476b496370490"
]
],
"content": "📅 Original date posted:2015-06-27\n📝 Original message:\nStephen \u003cstephencalebmorse at gmail.com\u003e writes:\n\u003e Quick question on the security of the Lightning Network when rerouting payments. \n\nHi Stephen,\n\n This is a good question!\n\n\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\n\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\nEach of the messages needs a separate preimage.\n\nThe simplest method is for E to simply provide A with (say) 100 hashes\nto use as she wishes.\n\nThough I think we can do better than this using crypto rather than\nhashes, in practice producing 100 preimages is pretty easy (hash a\nper-payment secret + counter).\n\nCheers,\nRusty.",
"sig": "195f53f09784b02c0eabb327dc52c76a4340116652bc47045fd66de1a57e123f3a712af64bc84372a255efda4ffe37c2299d4e495647f1126b211d256c056b4a"
}