[Lightning-dev] Collaborated stealing. What happens when the final recipient discloses the pre-image

[Christian Decker]

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 at 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.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
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev