📅 Original date posted:2018-03-02
📝 Original message:
Good morning Rene,
Please consider the recent discussion about AMP, atomic multi-path. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
Note that only the source (payer) can split the payment into multiple smaller payments; we cannot safely let intermediaries split the payment as the intermediaries may very well decide to send it to a ridiculously high-fee channel. So the payer will make multiple payments that can only be merged at the destination, each sub-payment has a single route and itself cannot be split unless the payer decides to split.
> Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing.
The timeouts in particular would be impossible to handle. At any point the payment should reach the payee within some N blocks and each hop reduces that margin by a small amount (14 blocks for c-lightning if I remember correctly). It is likely that there will not be enough time if it goes through a detour, unless the detour has equal or smaller reduction (delay) than the original hop with insufficient monetary capacity.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 1, 2018 11:26 PM, René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hey everyone,
>
> disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a friendly way and I know I need to read more code and specs in order to participate.
>
> Reading about the described problem techniques like IP-Fragmentation ( https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting is a little bit different but in from my current understanding it should still be applicable and also be the favorable solution in comparison to the proposed ping:
>
> 1.) IP setting: In IP-Fragmentation one would obviously just split the IP-package in order to utilize a link layer protocol that doesn't have enough bandwidth for a bigger size package.
> 2.) Lightning case: When the capacity of a channel during routing is not high enough - which means that the channel balance on that side is somewhere between 0 and the size of the payment - one would have to to send the second part of the fragmented package on a different route. This is obvious since the insufficient channel balance cannot come out of thin air (as in IP-Routing).
>
> My first intuition was that this would become a problem for onion routing since the router in question does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. However I imagine one could just encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour (using different payment channels) to the original "next" hop und progresses from there as it was originally thought of.
>
> Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing.
>
> If possible the advantage in comparison to your proposed ping method is that fragmentation would be highly dynamic and still work if a channel runs out of funds while routing payment. In your ping scenario it could very well happen that you do a ping for a designated rout, everything looks great, you send a payment but while it is on its way a channel on that way could run dry.
>
> best Rene
>
> On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen <jim.posen at gmail.com> wrote:
>
>> My understanding is that the best strategy for choosing a route to send funds over is to determine all possible routes, rank them by estimated fees based on channel announcements and number of hops, then try them successively until one works.
>>
>> It seems inefficient to me to actually do a full HTLC commitment handshake on each hop just to find out that the last hop in the route didn't have sufficient remaining capacity in the first place. Depending on how many people are using the network, I could also forsee situations where this creates more payment failures because bandwidth is locked up in HTLCs that are about to fail anyway.
>>
>> One idea that would likely help is the ability to send a ping over an onion route asking "does every hop have capacity to send X msat?" Every hop would forward the onion request if the answer is yes, or immediately send the response back up the circuit if the answer is no. This should reveal no additional information about the channel capacities that the sender couldn't determine by sending a test payment to themself (assuming they could find a loop). Additionally, the hops could respond with the latest fee rate in case channel updates are slow to propagate.
>>
>> The main benefit is that this should make it quicker to send a successful payment because latency is lower than sending an actual payment and the sender could ping all possible routes in parallel, whereas they can't send multiple payments in parallel. The main downside I can think of is that, by the same token, it is faster and cheaper for someone to extract information about channel capacities on the network with a binary search.
>>
>> -jimpo
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
> Skype: rene.pickhardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180302/fed112ba/attachment-0001.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:49:18
in reply to nevent1q…ryx5
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:49:18Event JSON
{
"id": "e6d6e99abe6dcb2b2b5fa8a4fa90bf01c2178984d4b9fb9a19d474b63e090a9a",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686314958,
"kind": 1,
"tags": [
[
"e",
"e14f71851bdf13bc9acc4bfc84ad1e53fde8c4c681c41af89b8ecb4c22851359",
"",
"root"
],
[
"e",
"8ebda6dbd595430169a6b3265e9a6f780ab17d978feeb2f027414262e4a3cb09",
"",
"reply"
],
[
"p",
"17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99"
]
],
"content": "📅 Original date posted:2018-03-02\n📝 Original message:\nGood morning Rene,\n\nPlease consider the recent discussion about AMP, atomic multi-path. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html\n\nNote that only the source (payer) can split the payment into multiple smaller payments; we cannot safely let intermediaries split the payment as the intermediaries may very well decide to send it to a ridiculously high-fee channel. So the payer will make multiple payments that can only be merged at the destination, each sub-payment has a single route and itself cannot be split unless the payer decides to split.\n\n\u003e Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing.\n\nThe timeouts in particular would be impossible to handle. At any point the payment should reach the payee within some N blocks and each hop reduces that margin by a small amount (14 blocks for c-lightning if I remember correctly). It is likely that there will not be enough time if it goes through a detour, unless the detour has equal or smaller reduction (delay) than the original hop with insufficient monetary capacity.\n\nRegards,\nZmnSCPxj\n\nSent with [ProtonMail](https://protonmail.com) Secure Email.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nOn March 1, 2018 11:26 PM, René Pickhardt via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hey everyone,\n\u003e\n\u003e disclaimer I am new here and have not a full understanding of the complete specs yet - however since I decided to participate in lighting dev I will just be brave and try to add my ideas on the problem jimpo posed. So even in case by ideas are complete bs please just tell me in a friendly way and I know I need to read more code and specs in order to participate.\n\u003e\n\u003e Reading about the described problem techniques like IP-Fragmentation ( https://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The setting is a little bit different but in from my current understanding it should still be applicable and also be the favorable solution in comparison to the proposed ping:\n\u003e\n\u003e 1.) IP setting: In IP-Fragmentation one would obviously just split the IP-package in order to utilize a link layer protocol that doesn't have enough bandwidth for a bigger size package.\n\u003e 2.) Lightning case: When the capacity of a channel during routing is not high enough - which means that the channel balance on that side is somewhere between 0 and the size of the payment - one would have to to send the second part of the fragmented package on a different route. This is obvious since the insufficient channel balance cannot come out of thin air (as in IP-Routing).\n\u003e\n\u003e My first intuition was that this would become a problem for onion routing since the router in question does not know the final destination but only knows the next hop which can't be utilized as the channel doesn't have enough funds. However I imagine one could just encapsulate the second part of the fragmented payment in a new onion routed package that goes on a detour (using different payment channels) to the original \"next\" hop und progresses from there as it was originally thought of.\n\u003e\n\u003e Not sure however how the impacts to the HTLC would be and if it would actually be possible to fragment a payment that is encapsulated within the onion routing.\n\u003e\n\u003e If possible the advantage in comparison to your proposed ping method is that fragmentation would be highly dynamic and still work if a channel runs out of funds while routing payment. In your ping scenario it could very well happen that you do a ping for a designated rout, everything looks great, you send a payment but while it is on its way a channel on that way could run dry.\n\u003e\n\u003e best Rene\n\u003e\n\u003e On Thu, Mar 1, 2018 at 3:45 PM, Jim Posen \u003cjim.posen at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e My understanding is that the best strategy for choosing a route to send funds over is to determine all possible routes, rank them by estimated fees based on channel announcements and number of hops, then try them successively until one works.\n\u003e\u003e\n\u003e\u003e It seems inefficient to me to actually do a full HTLC commitment handshake on each hop just to find out that the last hop in the route didn't have sufficient remaining capacity in the first place. Depending on how many people are using the network, I could also forsee situations where this creates more payment failures because bandwidth is locked up in HTLCs that are about to fail anyway.\n\u003e\u003e\n\u003e\u003e One idea that would likely help is the ability to send a ping over an onion route asking \"does every hop have capacity to send X msat?\" Every hop would forward the onion request if the answer is yes, or immediately send the response back up the circuit if the answer is no. This should reveal no additional information about the channel capacities that the sender couldn't determine by sending a test payment to themself (assuming they could find a loop). Additionally, the hops could respond with the latest fee rate in case channel updates are slow to propagate.\n\u003e\u003e\n\u003e\u003e The main benefit is that this should make it quicker to send a successful payment because latency is lower than sending an actual payment and the sender could ping all possible routes in parallel, whereas they can't send multiple payments in parallel. The main downside I can think of is that, by the same token, it is faster and cheaper for someone to extract information about channel capacities on the network with a binary search.\n\u003e\u003e\n\u003e\u003e -jimpo\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e --\n\u003e Skype: rene.pickhardt\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180302/fed112ba/attachment-0001.html\u003e",
"sig": "920eee3aad53279a1740cd686f50900becfd68dd85b9a56095351c42f88db90863b9187fde82998f32451f68a33579138d16a4c0d4880dcca56fe041fb5b0f38"
}