It might be worth mentioning here that the wormhole attack can also just be considered a more efficient way of routing a payment over fewer hops, freeing funds in channels that have been skipped by failing them even though the overall payment has not been completed.
This is why I hesitate to even call it an attack in the first place: if the skipped hops free the HTLCs, which the skipping entity that controls both endpoints of the shortcut is encouraged to in order to free its own reserved funds, we are increasing the efficiency of the network. As ZmnSCPxj correctly points out this requires the attacker to be able to collate HTLCs, which goes away with PTLCs. However even today we're not worse off by nodes exploiting this. Cheers, Christian ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > 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.gang...@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@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
