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 <> wrote:
Olaoluwa Osuntokun <> 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.

Lightning-dev mailing list
Lightning-dev mailing list

Reply via email to