>From  Anton Kumaigorodski (not in the list till now):

This already happens. Yesterday I was contacted by a user who claimed he
did not receive a payment while payer was able to provide a preimage.


Turns out he reused the same invoice twice which is this one:
lnbc100u1pwy03lupp5q004g320cfw6y93lfrv30sxvdfppysjvuqspln6mrzwcmfxzpv5qdq823jhxaqcqzysusu5zpfyqw5qetv3w2hsug7uact0hvpten83h7r57e7tz0gu6y78qv4dwh0z2ggxylnvcjcj55fdycj2dc2h599jf3vl5q2tzr4cw7sqq98vek


It's expired by now but if you try to fulfill it a routing node
02ee8c40b64c2bd14bba4a7a7a80b06065f3a683b2f02b9580be5e8bffe201beda will
return a preimage right away. I can say this for sure since I've obtained
user logs which show no incoming update_add_htlc while outgoing payment
gets fulfilled in my wallet.


This is definitely not what users would expect, I guess something should be
done about it. BLW already warns users about QR reuse yet this happened
anyway. Any ideas?


El jue., 3 ene. 2019 a las 17:42, Andrea RASPITZU (<andrea.raspi...@acinq.fr>)
escribió:

> Okay so the knowledge of a preimage for a certain payment_hash is the
> sufficient (and only) payment proof for the payer. But in any case the
> reuse of payment_hashes should be strongly discouraged, in the donations
> scenario 2 donors will send across the network a payment for the same
> preimage and if the routes overlap (as it's likely to happen getting close
> to the recipient) an intermediate routing node can effectively steal the
> payment from the recipient. Shouldn't we make this clear in BOLT11?
>
> Cheers, Andrea.
>
>
>
> On Thu, 3 Jan 2019 at 14:13, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
>
>> Good morning Andrea,
>>
>> > For example a malicious receiver can provide an invoice with assisted
>> routes where among those he/she controls a node and that node won't forward
>> to the htlc but steal the funds instead (the preimage is known to the
>> intermediate node as well), thus it will be claimed that the payment hasn't
>> been received. If the above is correct then there should be at least a
>> warning in the spec regarding the reuse of payment_hash in invoices.
>>
>> The fact that ultimate payer has received the payment preimage is
>> considered sufficient proof of payment.
>> Thus, in case of reuse, the fact that the ultimate payer has received the
>> payment preimage is sufficient proof of payment, and whatever the receiver
>> claims is to be ignored: the payment preimage in possession of the ultimate
>> payee is considered the whole of the proof of payment.
>>
>>
>> >a malicious receiver can provide an invoice with assisted routes where
>> among those he/she controls a node and that node won't forward to the htlc
>> but steal the funds instead
>>
>> Then the receiver has received it, not on the purported final node, but
>> on another node it controls, and the fact that the ultimate payer has
>> received the payment preimage is sufficient proof of that.
>>
>> Obviously, if the receiver knows it does not control the entire Lightning
>> Network, it should not reuse payment hashes, since intermediate nodes it
>> does not control could claim the payment and give the proof-of-payment to
>> the ultimate payer.
>> This can be clarified, but in the context of proofs, the attack you
>> described is not possible, since the possession of the payment preimage is
>> itself the entirety of the proof of the payment, regardless of what the
>> receiver claims.
>>
>> Regards,
>> ZmnSCPxj
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>


-- 
Un saludo,

Josema
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to