📅 Original date posted:2018-03-01
📝 Original message:
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/20180301/ba0d1507/attachment.html>;
René Pickhardt [ARCHIVE] /
npub1zl…d2k4w
2023-06-09 12:49:18
in reply to nevent1q…advd
Author Public Key
npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4wPublished at
2023-06-09 12:49:18Event JSON
{
"id": "8ebda6dbd595430169a6b3265e9a6f780ab17d978feeb2f027414262e4a3cb09",
"pubkey": "17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99",
"created_at": 1686314958,
"kind": 1,
"tags": [
[
"e",
"e14f71851bdf13bc9acc4bfc84ad1e53fde8c4c681c41af89b8ecb4c22851359",
"",
"root"
],
[
"e",
"f7b853dca79b3cd7ac38b6ab1886a9c111310037252ee674e541dbe45aa0ebe7",
"",
"reply"
],
[
"p",
"17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99"
]
],
"content": "📅 Original date posted:2018-03-01\n📝 Original message:\nHey everyone,\n\ndisclaimer I am new here and have not a full understanding of the complete\nspecs yet - however since I decided to participate in lighting dev I will\njust be brave and try to add my ideas on the problem jimpo posed. So even\nin case by ideas are complete bs please just tell me in a friendly way and\nI know I need to read more code and specs in order to participate.\n\nReading about the described problem techniques like IP-Fragmentation (\nhttps://en.wikipedia.org/wiki/IP_fragmentation ) come to my mind. The\nsetting is a little bit different but in from my current understanding it\nshould still be applicable and also be the favorable solution in comparison\nto the proposed ping:\n\n1.) IP setting: In IP-Fragmentation one would obviously just split the\nIP-package in order to utilize a link layer protocol that doesn't have\nenough bandwidth for a bigger size package.\n2.) Lightning case: When the capacity of a channel during routing is not\nhigh enough - which means that the channel balance on that side is\nsomewhere between 0 and the size of the payment - one would have to to send\nthe second part of the fragmented package on a different route. This is\nobvious since the insufficient channel balance cannot come out of thin air\n(as in IP-Routing).\n\nMy first intuition was that this would become a problem for onion routing\nsince the router in question does not know the final destination but only\nknows the next hop which can't be utilized as the channel doesn't have\nenough funds. However I imagine one could just encapsulate the second part\nof the fragmented payment in a new onion routed package that goes on a\ndetour (using different payment channels) to the original \"next\" hop und\nprogresses from there as it was originally thought of.\n\nNot sure however how the impacts to the HTLC would be and if it would\nactually be possible to fragment a payment that is encapsulated within the\nonion routing.\n\nIf possible the advantage in comparison to your proposed ping method is\nthat fragmentation would be highly dynamic and still work if a channel runs\nout of funds while routing payment. In your ping scenario it could very\nwell happen that you do a ping for a designated rout, everything looks\ngreat, you send a payment but while it is on its way a channel on that way\ncould run dry.\n\nbest Rene\n\n\nOn Thu, Mar 1, 2018 at 3:45 PM, Jim Posen \u003cjim.posen at gmail.com\u003e wrote:\n\n\u003e My understanding is that the best strategy for choosing a route to send\n\u003e funds over is to determine all possible routes, rank them by estimated fees\n\u003e based on channel announcements and number of hops, then try them\n\u003e successively until one works.\n\u003e\n\u003e It seems inefficient to me to actually do a full HTLC commitment handshake\n\u003e on each hop just to find out that the last hop in the route didn't have\n\u003e sufficient remaining capacity in the first place. Depending on how many\n\u003e people are using the network, I could also forsee situations where this\n\u003e creates more payment failures because bandwidth is locked up in HTLCs that\n\u003e are about to fail anyway.\n\u003e\n\u003e One idea that would likely help is the ability to send a ping over an\n\u003e onion route asking \"does every hop have capacity to send X msat?\" Every hop\n\u003e would forward the onion request if the answer is yes, or immediately send\n\u003e the response back up the circuit if the answer is no. This should reveal no\n\u003e additional information about the channel capacities that the sender\n\u003e couldn't determine by sending a test payment to themself (assuming they\n\u003e could find a loop). Additionally, the hops could respond with the latest\n\u003e fee rate in case channel updates are slow to propagate.\n\u003e\n\u003e The main benefit is that this should make it quicker to send a successful\n\u003e payment because latency is lower than sending an actual payment and the\n\u003e sender could ping all possible routes in parallel, whereas they can't send\n\u003e multiple payments in parallel. The main downside I can think of is that,\n\u003e by the same token, it is faster and cheaper for someone to extract\n\u003e information about channel capacities on the network with a binary search.\n\u003e\n\u003e -jimpo\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\n\n-- \nSkype: rene.pickhardt\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180301/ba0d1507/attachment.html\u003e",
"sig": "9da278c798f1f6b2d0ebafbe58bf1204f006c933ed451a91426e61a83f79fc9c4027165b5c039aeb4c26960f901d3df59450ef1a0ead791b4891679f1e9288ea"
}