rich1.0npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwhttps://nostr.ae/npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwnjumphttps://nostr.ae📅 Original date posted:2018-02-08 📝 Original message: 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 <rusty at rustcorp.com.au> wrote: Olaoluwa Osuntokun <laolu32 at 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 at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180208/ec4e6b34/attachment.html>