Re: [Lightning-dev] Reuse of payment_hash in lightning invoices
>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@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
Re: [Lightning-dev] Reuse of payment_hash in lightning invoices
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reuse of payment_hash in lightning invoices
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
