Jim Posen <[email protected]> writes: > 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.
If failure is common this would be true, but I think it's too early to design for it. This kind of signalling is what fees are for: when capacity gets low you increase fees, and when it gets high, you reduce them. But that may still prove insufficient. Two things come to mind: 1. `temporary_channel_failure` returns a `channel_update`. The implication is that this has the disabled flag, but we should probably make that true iff the request asks for < 2% of the channel capacity or some "minimal bar". If you can't even service this, you should disable the channel. 2. We can implement fast failure to reduce latency: https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming Note that there needs to be more analysis on reliable ways to mask the active capacity of a channel: using a static random threshold still leaks information that *something* has happened, so it may need to be more sophisticated. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
