📅 Original date posted:2018-03-01
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180301/55533bfa/attachment.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-09 12:49:17
in reply to nevent1q…avh5
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-09 12:49:17Event JSON
{
"id": "fcb723f32a14f919e2a70a683561c92e32d36a55e07c1c31c41bde6f788d0f30",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686314957,
"kind": 1,
"tags": [
[
"e",
"e14f71851bdf13bc9acc4bfc84ad1e53fde8c4c681c41af89b8ecb4c22851359",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-03-01\n📝 Original message:\nMy understanding is that the best strategy for choosing a route to send\nfunds over is to determine all possible routes, rank them by estimated fees\nbased on channel announcements and number of hops, then try them\nsuccessively until one works.\n\nIt seems inefficient to me to actually do a full HTLC commitment handshake\non each hop just to find out that the last hop in the route didn't have\nsufficient remaining capacity in the first place. Depending on how many\npeople are using the network, I could also forsee situations where this\ncreates more payment failures because bandwidth is locked up in HTLCs that\nare about to fail anyway.\n\nOne idea that would likely help is the ability to send a ping over an onion\nroute asking \"does every hop have capacity to send X msat?\" Every hop would\nforward the onion request if the answer is yes, or immediately send the\nresponse back up the circuit if the answer is no. This should reveal no\nadditional information about the channel capacities that the sender\ncouldn't determine by sending a test payment to themself (assuming they\ncould find a loop). Additionally, the hops could respond with the latest\nfee rate in case channel updates are slow to propagate.\n\nThe main benefit is that this should make it quicker to send a successful\npayment because latency is lower than sending an actual payment and the\nsender could ping all possible routes in parallel, whereas they can't send\nmultiple payments in parallel. The main downside I can think of is that, by\nthe same token, it is faster and cheaper for someone to extract information\nabout channel capacities on the network with a binary search.\n\n-jimpo\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180301/55533bfa/attachment.html\u003e",
"sig": "166cea32597bb1bc69c744fef64f11659618c79e43b38865a31539a7efd6f87a0c36ab3ea025a38f3a88bd46b64adbed54f1fcf21221e9570eb5ced39987cb01"
}