📅 Original date posted:2018-02-08
📝 Original message:
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 <johanth at 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 <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
>
>
> _______________________________________________
> 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/31041639/attachment.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-09 12:49:00
in reply to nevent1q…xk0t
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-09 12:49:00Event JSON
{
"id": "17de929494d19e8b31bcc92aaf144b05e5d84f10b1531da33f41eeb2449a0441",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686314940,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"7b70aea7dbacfbfa1c1fbdb45597f63a44deab883115e05eb60000a605154a2b",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "📅 Original date posted:2018-02-08\n📝 Original message:\nIf using two hashes to deliver the payment while still getting a proof, I'm\nnot sure what that provides above just sending regular lightning payments\nover multiple routes with one hash. Firstly, if there is a second hash, it\nwould presumably be the same for all routes, making them linkable again,\nwhich AMP tries to solve. And secondly, the receiver has no incentive to\nclaim any of the HTLCs before all of them are locked in, because in that\ncase they are releasing the transaction receipt before fully being paid.\n\nOn Thu, Feb 8, 2018 at 8:41 AM, Johan Torås Halseth \u003cjohanth at gmail.com\u003e\nwrote:\n\n\u003e An obvious way to make this compatible with proof-of-payment would be to\n\u003e require two hashes to claim the HTLC: the presage from the invoice payment\n\u003e hash (as today) + the new hash introduced here. This would give the sender\n\u003e a receipt after only one of the HTLCs was claimed. Would require changes to\n\u003e the scripts of course.\n\u003e\n\u003e With Schnorr/EC operations this could probably be made more elegant, as\n\u003e mentioned.\n\u003e\n\u003e - Johan\n\u003e On Wed, Feb 7, 2018 at 18:21, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\n\u003e Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e \u003e Hi Y'all,\n\u003e \u003e\n\u003e \u003e A common question I've seen concerning Lightning is: \"I have five $2\n\u003e \u003e channels, is it possible for me to *atomically* send $6 to fulfill a\n\u003e \u003e payment?\". The answer to this question is \"yes\", provided that the\n\u003e receiver\n\u003e\n\u003e This is awesome! I'm kicking myself for not proposing it :)\n\u003e\n\u003e Unfortunately, your proposal defines a way to make multipath donations,\n\u003e not multipath payments :(\n\u003e\n\u003e In other words, you've lost proof of payment, which IMHO is critical.\n\u003e\n\u003e Fortunately, this can be fairly trivially fixed when we go to scriptless\n\u003e scripts or other equivalent decorrelation mechanism, when I think this\n\u003e mechanism becomes extremely powerful.\n\u003e\n\u003e \u003e - Potential fee savings for larger payments, contingent on there being a\n\u003e \u003e super-linear component to routed fees. It's possible that with\n\u003e \u003e modifications to the fee schedule, it's actually *cheaper* to send\n\u003e \u003e payments over multiple flows rather than one giant flow.\n\u003e\n\u003e This is a stretch. I'd stick with the increased reliability/privacy\n\u003e arguments which are overwhelmingly compelling IMHO.\n\u003e\n\u003e If I have any important feedback on deeper reading (and after a sccond\n\u003e coffee), I'll send a separate email.\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180208/31041639/attachment.html\u003e",
"sig": "c2ae7f344cb7a7578e7808b13fbdce9c712314a0815d9a8a6c3a03b96862fa3523b1d0f3ac2aa68df01916fd11ea2e0401a049ce91c2749697641911ad10fc56"
}