[Lightning-dev] Pinging a route for capacity
Rusty Russell
rusty at rustcorp.com.au
Sun Mar 4 02:46:46 UTC 2018
Jim Posen <jim.posen at gmail.com> 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.
More information about the Lightning-dev
mailing list