đź“… Original date posted:2018-02-08
đź“ť Original message:
Yeah, that is true, it would only give you the atomicity, not the decorrelation. I don’t see how you could get all the same properties using only one hash though. I guess the sender has no incentive to claim any of the payments before all of them have arrived, but you get no guarantee that partial payments cannot be made. Seems hard to do without introducing new primitives.
- Johan
On Thu, Feb 8, 2018 at 12:44, Jim Posen <jim.posen at gmail.com> wrote:
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 [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 [rusty at rustcorp.com.au] > wrote:
Olaoluwa Osuntokun < laolu32 at gmail.com [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 [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]
______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [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/edbfbd41/attachment-0001.html>;
Johan TorĂĄs Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:49:01
in reply to nevent1q…wdly
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:49:01Event JSON
{
"id": "6c652af4298a4237836529d13fdd75fae5a8df401d4855c65037814b425ac05b",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686314941,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"17de929494d19e8b31bcc92aaf144b05e5d84f10b1531da33f41eeb2449a0441",
"",
"reply"
],
[
"p",
"9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1"
]
],
"content": "📅 Original date posted:2018-02-08\n📝 Original message:\nYeah, that is true, it would only give you the atomicity, not the decorrelation. I don’t see how you could get all the same properties using only one hash though. I guess the sender has no incentive to claim any of the payments before all of them have arrived, but you get no guarantee that partial payments cannot be made. Seems hard to do without introducing new primitives.\n- Johan\n\nOn Thu, Feb 8, 2018 at 12:44, Jim Posen \u003cjim.posen at gmail.com\u003e wrote:\nIf 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.\n\nOn Thu, Feb 8, 2018 at 8:41 AM, Johan Torås Halseth \u003c johanth at gmail.com [johanth at gmail.com] \u003e wrote:\nAn 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.\nWith Schnorr/EC operations this could probably be made more elegant, as mentioned.\n\n- Johan\nOn Wed, Feb 7, 2018 at 18:21, Rusty Russell \u003c rusty at rustcorp.com.au [rusty at rustcorp.com.au] \u003e wrote:\nOlaoluwa Osuntokun \u003c laolu32 at gmail.com [laolu32 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 receiver\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 [Lightning-dev at lists.linuxfoundation.org]\nhttps://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]\n\n______________________________ _________________\nLightning-dev mailing list\nLightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]\nhttps://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://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/edbfbd41/attachment-0001.html\u003e",
"sig": "0d4e905e62be8ac33546c5c76dc1b3abd413e8420d0d010fbc072c20a41a528381cbb8012bd939233f2dee52200af98526ccf69b3531a2c03b0cd4f314e27032"
}