Andrea RASPITZU [ARCHIVE] on Nostr: š Original date posted:2019-01-03 š Original message: Okay so the knowledge of ...
š
Original date posted:2019-01-03
š Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190103/ce268371/attachment.html>;
š Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190103/ce268371/attachment.html>;