From jochemin at gmail.com Thu Jan 24 18:00:51 2019 From: jochemin at gmail.com (Jose Manuel Arenillas) Date: Thu, 24 Jan 2019 19:00:51 +0100 Subject: [Lightning-dev] Reuse of payment_hash in lightning invoices In-Reply-To: References: Message-ID: >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 () 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 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- Un saludo, Josema -------------- next part -------------- An HTML attachment was scrubbed... URL: