Capacity indications on HTLC failures

[rustyrussell]

With AMP, we'll effectively be probing for channel capacity. Returning how far out a payment was provides a hint.

You can determine the order required, then fuzz it a little, eg:

switch(rand(8)):
case 0: increase, retry;
case 1: decrease, retry;
case 2-8: stop;

Signed-off-by: Rusty Russell [email protected]

[niftynei]

for maximum privacy, imo this should be reported as the 'absolute' value of the channel, rather than missing for the htlc. an absolute merely sets a ceiling for a probe, whereas updating the value for every htlc attempt cuts the search space on every attempt.

This brings up a good question, namely why do we obscure the available balance? We do it to prevent / reduce the ability of an omniscient observer from seeing in real time the path of a payment. Although probing reveals information about any given channel's capacity, tracking a payment's path currently requires a constant flood of probes to keep track of these capacities in real time.

I think @Roasbeef has some research results on the current feasibility of this kind of channel-level observation via probing?

[t-bast]

This brings up a good question, namely why do we obscure the available balance?

I'm going to revert your question :smiley:: setting aside the privacy issue of an observer that watches all of those in real-time, I think there are two main reasons why it wouldn't make sense to share exact balances:

• it's way too costly to gossip about those (but you could argue that we could just return them on payment relay failure and not actively broadcast them)
• they would likely be obsolete by the time the initial sender receives them (at time T you share your balance, but before the sender retries taking this into account, new payments have been made and that balance is invalid - it's a cat and mouse game)