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.
On Thu, Feb 8, 2018 at 8:41 AM, Johan Torås Halseth <joha...@gmail.com> wrote: > An obvious way to make this compatible with proof-of-payment would be to > require two hashes to claim the HTLC: the presage from the invoice payment > hash (as today) + the new hash introduced here. This would give the sender > a receipt after only one of the HTLCs was claimed. Would require changes to > the scripts of course. > > With Schnorr/EC operations this could probably be made more elegant, as > mentioned. > > - Johan > On Wed, Feb 7, 2018 at 18:21, Rusty Russell <ru...@rustcorp.com.au> wrote: > > Olaoluwa Osuntokun <laol...@gmail.com> writes: > > Hi Y'all, > > > > A common question I've seen concerning Lightning is: "I have five $2 > > channels, is it possible for me to *atomically* send $6 to fulfill a > > payment?". The answer to this question is "yes", provided that the > receiver > > This is awesome! I'm kicking myself for not proposing it :) > > Unfortunately, your proposal defines a way to make multipath donations, > not multipath payments :( > > In other words, you've lost proof of payment, which IMHO is critical. > > Fortunately, this can be fairly trivially fixed when we go to scriptless > scripts or other equivalent decorrelation mechanism, when I think this > mechanism becomes extremely powerful. > > > - Potential fee savings for larger payments, contingent on there being a > > super-linear component to routed fees. It's possible that with > > modifications to the fee schedule, it's actually *cheaper* to send > > payments over multiple flows rather than one giant flow. > > This is a stretch. I'd stick with the increased reliability/privacy > arguments which are overwhelmingly compelling IMHO. > > If I have any important feedback on deeper reading (and after a sccond > coffee), I'll send a separate email. > > Thanks! > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
