Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-12 📝 Original message: Jim Posen <jim.posen at ...
📅 Original date posted:2018-02-12
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> If using two hashes to deliver the payment while still getting a proof, I'm
> not sure what that provides above just sending regular lightning payments
> over multiple routes with one hash. Firstly, if there is a second hash, it
> would presumably be the same for all routes, making them linkable again,
> which AMP tries to solve. And secondly, the receiver has no incentive to
> claim any of the HTLCs before all of them are locked in, because in that
> case they are releasing the transaction receipt before fully being paid.
Arguably the second concern is not really an issue, if you allow partial
claims you'll end up in a whole lot of trouble. It should always be the
case that the payment as whole is atomic, i.e., either the entirety of
the payment goes through or none of it, independently of whether it was
a singlepath or a multipath payment. This is actually one of the really
nice features that was enforced using the simple "just reuse the
hash"-mechanism, you always had to wait for the complete payment or
you'd risk losing part of it.
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> If using two hashes to deliver the payment while still getting a proof, I'm
> not sure what that provides above just sending regular lightning payments
> over multiple routes with one hash. Firstly, if there is a second hash, it
> would presumably be the same for all routes, making them linkable again,
> which AMP tries to solve. And secondly, the receiver has no incentive to
> claim any of the HTLCs before all of them are locked in, because in that
> case they are releasing the transaction receipt before fully being paid.
Arguably the second concern is not really an issue, if you allow partial
claims you'll end up in a whole lot of trouble. It should always be the
case that the payment as whole is atomic, i.e., either the entirety of
the payment goes through or none of it, independently of whether it was
a singlepath or a multipath payment. This is actually one of the really
nice features that was enforced using the simple "just reuse the
hash"-mechanism, you always had to wait for the complete payment or
you'd risk losing part of it.