📅 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>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:49:00
in reply to nevent1q…cdlf
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:49:00Event JSON
{
"id": "7b70aea7dbacfbfa1c1fbdb45597f63a44deab883115e05eb60000a605154a2b",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686314940,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"c311ec485bed69cf5c3f1c9b90556b9509f6eb02217ebf2053ffbed02f30b1f9",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-02-08\n📝 Original message:\nAn obvious way to make this compatible with proof-of-payment would be to \nrequire two hashes to claim the HTLC: the presage from the invoice payment \nhash (as today) + the new hash introduced here. This would give the sender \na receipt after only one of the HTLCs was claimed. Would require changes to \nthe scripts of course.\nWith Schnorr/EC operations this could probably be made more elegant, as \nmentioned.\n\n- Johan\nOn Wed, Feb 7, 2018 at 18:21, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n \u003e Hi Y'all,\n \u003e\n \u003e A common question I've seen concerning Lightning is: \"I have five $2\n \u003e channels, is it possible for me to *atomically* send $6 to fulfill a\n \u003e payment?\". The answer to this question is \"yes\", provided that the \nreceiver\n\nThis is awesome! I'm kicking myself for not proposing it :)\n\nUnfortunately, your proposal defines a way to make multipath donations,\nnot multipath payments :(\n\nIn other words, you've lost proof of payment, which IMHO is critical.\n\nFortunately, this can be fairly trivially fixed when we go to scriptless\nscripts or other equivalent decorrelation mechanism, when I think this\nmechanism becomes extremely powerful.\n\n \u003e - Potential fee savings for larger payments, contingent on there being a\n \u003e super-linear component to routed fees. It's possible that with\n \u003e modifications to the fee schedule, it's actually *cheaper* to send\n \u003e payments over multiple flows rather than one giant flow.\n\nThis is a stretch. I'd stick with the increased reliability/privacy\narguments which are overwhelmingly compelling IMHO.\n\nIf I have any important feedback on deeper reading (and after a sccond\ncoffee), I'll send a separate email.\n\nThanks!\nRusty.\n_______________________________________________\nLightning-dev mailing list\nLightning-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180208/ec4e6b34/attachment.html\u003e",
"sig": "13a6e1868581b4543075db0b9064a063317597f891db010c935c3eaad43967bd99216fe05b45afdb6ffb949a50ec21bc5a6a31f87a974934018c6e5e11d88d23"
}