📅 Original date posted:2020-07-17
📝 Original message:
Good morning Ankit,
I believe what you describe is a specific form of what is called the Wormhole attack.
In the general form, the Wormhole attack has two forwarding nodes in a path that are coordinating with each other, and they can "teleport" the preimage from one to the other, skipping intermediate forwarding nodes.
The case you describe is the specific case where one of the nodes performing this attack on a path is the payee itself.
What is stolen here is not the payment amount, but the fees that the "skipped" forwarding nodes should have earned for honestly forwarding.
On the other hand, in that case, it is simply a form of the griefing attack: C and E are able to cause D to lock its funds into HTLCs without earning fees, but C and E can mount that attack at any time regardless of A or B anyway, so it is not an additional attack surface on D.
At a high level, this attack is not a concern.
As long as A is able to acquire the preimage, it has proof of payment, and it is immaterial *how* A managed to get the preimage, as Rene describes.
Even if E claims that it did not deliberately give the preimage and that it was hacked by C, then it is C who is liable, in which case C and E, being a cooperating team, have gained nothing at all (and just made C angry at E for throwing C under the bus).
Basically, the preimage *is* the proof.
There are only two things you need to do:
* Ensure that invoices are signed by E (meaning E agreed to perform some service if the preimage is revealed by anyone).
BOLT11 already requires this.
* Ensure that invoices indicate *who exactly* is going to get the service or product.
Since the preimage is learned by every intermediate hop, it cannot be a bearer certificate, so it must indicate specifically that the beneficiary of the product or service will be A.
With the above, A can be sure that paying in exchange for getting the preimage, is a binding contract on the service indicated by the invoice.
The preimage and the invoice (that has a signature from E), are sufficient to show that E has an obligation to provide a service or product to A.
The wormhole attack (which steals fees from D) is fixed by using PTLCs and blinding factors.
E learns the total of all blinding factors, and knows the final scalar, but does not know the blinding factor delta from C to E, and thus cannot give C any information on how to claim the funds.
Regards,
ZmnSCPxj
> Hey Ankit,
>
> The lightning network sees the possession of a preimage as a proof of payment. And I believe everyone agrees that a court should rule in favor of A forcing E to deliver the good or reimburse A. The reason is that possession of the preimage matching the signed payment hash from E is a much stronger evidence of A actually having paid than E claiming to not have received anything.
> This is also due to the fact that guessing the preimage can practically be considered impossible (though there is a tiny likelihood)
>
> If E breaches the protocol by giving the preimage to C (for free) instead of claiming the money from D (and thus settling the Htlc) it will be considered E's problem, that E did not get reimbursed but just gave out the preimage for free. (actually E's so called "partner in crime" did get reimbursed). Even if D would testify that E never settled the Htlc one would wonder why E never settled the incoming htlc as they should only have created a payment hash for which they know the preimage. Since A can actually provide one it is again unlikely if E for example claims they just used a random hash for which they didn't know the preimage because they wanted to just see if A has enough liquidity.
>
> With kind regards Rene
>
> Ankit Gangwal <A.Gangwal at tudelft.nl> schrieb am Fr., 17. Juli 2020, 08:43:
>
> > Consider A wants to send some funds to E.
> >
> > They don’t have a direct payment channel among them. So, they use a following path A-B-C-D-E. A is the sender of payment and E is final recipient.
> >
> > E sends the hash of a secret r to A, A passes on the hash to B, B to C, C to D, and D to E.
> >
> > E discloses the secret to C (a partner in crime with E) and E do not respond to D. C gives the secret to B (settling the HTLC between them). Then, B gives the secret to A (settling the HTLC between them).
> >
> > A sent (and lost) the money, as E denies receiving the money (and the promised service/good).
> >
> > How the lightening network sees this? Out of their control?
> >
> > --
> >
> > A_G
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:00:35
in reply to nevent1q…qy02
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:00:35Event JSON
{
"id": "b6bce29c6476e0748b83bfa7be761a85e75b1710ca1ddba463d121a252ea5a84",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315635,
"kind": 1,
"tags": [
[
"e",
"1b703a25bc1b8e070a3f73e93f34071db1983e86f16ae618583f85f25e1a38d0",
"",
"root"
],
[
"e",
"798b1bb442b57c11e00680e74ed43fb1decbf4cdea13ebf66d18d93b362f2dc0",
"",
"reply"
],
[
"p",
"17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99"
]
],
"content": "📅 Original date posted:2020-07-17\n📝 Original message:\nGood morning Ankit,\n\nI believe what you describe is a specific form of what is called the Wormhole attack.\nIn the general form, the Wormhole attack has two forwarding nodes in a path that are coordinating with each other, and they can \"teleport\" the preimage from one to the other, skipping intermediate forwarding nodes.\n\nThe case you describe is the specific case where one of the nodes performing this attack on a path is the payee itself.\n\nWhat is stolen here is not the payment amount, but the fees that the \"skipped\" forwarding nodes should have earned for honestly forwarding.\nOn the other hand, in that case, it is simply a form of the griefing attack: C and E are able to cause D to lock its funds into HTLCs without earning fees, but C and E can mount that attack at any time regardless of A or B anyway, so it is not an additional attack surface on D.\n\nAt a high level, this attack is not a concern.\nAs long as A is able to acquire the preimage, it has proof of payment, and it is immaterial *how* A managed to get the preimage, as Rene describes.\nEven if E claims that it did not deliberately give the preimage and that it was hacked by C, then it is C who is liable, in which case C and E, being a cooperating team, have gained nothing at all (and just made C angry at E for throwing C under the bus).\n\nBasically, the preimage *is* the proof.\nThere are only two things you need to do:\n\n* Ensure that invoices are signed by E (meaning E agreed to perform some service if the preimage is revealed by anyone).\n BOLT11 already requires this.\n* Ensure that invoices indicate *who exactly* is going to get the service or product.\n Since the preimage is learned by every intermediate hop, it cannot be a bearer certificate, so it must indicate specifically that the beneficiary of the product or service will be A.\n\nWith the above, A can be sure that paying in exchange for getting the preimage, is a binding contract on the service indicated by the invoice.\nThe preimage and the invoice (that has a signature from E), are sufficient to show that E has an obligation to provide a service or product to A.\n\nThe wormhole attack (which steals fees from D) is fixed by using PTLCs and blinding factors.\nE learns the total of all blinding factors, and knows the final scalar, but does not know the blinding factor delta from C to E, and thus cannot give C any information on how to claim the funds.\n\nRegards,\nZmnSCPxj\n\n\n\u003e Hey Ankit, \n\u003e\n\u003e The lightning network sees the possession of a preimage as a proof of payment. And I believe everyone agrees that a court should rule in favor of A forcing E to deliver the good or reimburse A. The reason is that possession of the preimage matching the signed payment hash from E is a much stronger evidence of A actually having paid than E claiming to not have received anything. \n\u003e This is also due to the fact that guessing the preimage can practically be considered impossible (though there is a tiny likelihood) \n\u003e\n\u003e If E breaches the protocol by giving the preimage to C (for free) instead of claiming the money from D (and thus settling the Htlc) it will be considered E's problem, that E did not get reimbursed but just gave out the preimage for free. (actually E's so called \"partner in crime\" did get reimbursed). Even if D would testify that E never settled the Htlc one would wonder why E never settled the incoming htlc as they should only have created a payment hash for which they know the preimage. Since A can actually provide one it is again unlikely if E for example claims they just used a random hash for which they didn't know the preimage because they wanted to just see if A has enough liquidity. \n\u003e\n\u003e With kind regards Rene\n\u003e\n\u003e Ankit Gangwal \u003cA.Gangwal at tudelft.nl\u003e schrieb am Fr., 17. Juli 2020, 08:43:\n\u003e\n\u003e \u003e Consider A wants to send some funds to E.\n\u003e \u003e\n\u003e \u003e They don’t have a direct payment channel among them. So, they use a following path A-B-C-D-E. A is the sender of payment and E is final recipient.\n\u003e \u003e\n\u003e \u003e E sends the hash of a secret r to A, A passes on the hash to B, B to C, C to D, and D to E.\n\u003e \u003e\n\u003e \u003e E discloses the secret to C (a partner in crime with E) and E do not respond to D. C gives the secret to B (settling the HTLC between them). Then, B gives the secret to A (settling the HTLC between them).\n\u003e \u003e\n\u003e \u003e A sent (and lost) the money, as E denies receiving the money (and the promised service/good).\n\u003e \u003e\n\u003e \u003e How the lightening network sees this? Out of their control?\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e\n\u003e \u003e A_G\n\u003e \u003e\n\u003e \u003e \n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "5a2089b1d54090aacf7417e292602f8928140154e5051253273ef3c38ecbbbb7fcc9d7a79bf33bc96f53baad2d7ecd1b79ca74ec8cb18242fbf7a56662256e0a"
}