From rusty at rustcorp.com.au  Sun Mar  4 02:46:46 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sun, 04 Mar 2018 13:16:46 +1030
Subject: [Lightning-dev] Pinging a route for capacity
In-Reply-To: <CADZtCSi5jLWsaBLc5FrYXe838zv6mcNW1QopwqkMGzhPWLiv-Q@mail.gmail.com>
References: <CADZtCSi5jLWsaBLc5FrYXe838zv6mcNW1QopwqkMGzhPWLiv-Q@mail.gmail.com>
Message-ID: <87tvtw8smh.fsf@rustcorp.com.au>

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.