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 rusty@rustcorp.com.au

[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 😃: 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)

[lightning-developer]

It seems reasonable to give more precise feedback when an HTLC fails. Yet I think this proposal - despite fuzzing the exact amount - may leak too much information especially to an attacker.

If we have a remote channel with a capacity of c sats and we tried to send an HTLC of size h sats - assuming a uniform distribution of the sats in the channel - we have the following situation:

1. Before sending the HTLC the Entropy is log(c+1) bits
2. After sending the HTLC successfully the Entropy is log(c-h + 1) bits
3. After a failing HTLC the Entropy is log(h+1) bits

As this proposal is for the failure case let us look at the information gain which is log(c+1) - log(h+1) bits.

With l being the actual liquidity we have: l < h < c in the failure case.

You propose to send back the order as a power of two by which the HTLC exceeds the actual liquidity which can be expressed as log(h) - log(l).

Given the fact that we had a failing HTLC and that log(h) is roughly log(h+1) we would have an information gain of log(c+1)-log(h+1) + log(h) - log(l) which is roughly the information gain of log(c+1) - log(l+1) bits.

Note that for small payments which do not exceed half the channel capacity log(c+1) -log(l+1) > log(c+1) - log(c-l + 1). (which is equivalent to log(l+1) < log(c-l +1) meaning the entropy is reduced quite a bit)
The right hand side of the inequality log(c+1)-log(c-l+1) is the information gain if the HTLC was of size l and successful. The left hand site is close to the worst case where the attempted HTLCs was just 1 satoshi larger than the existing liquidity in which case (still assuming small payments) we learn the most.

Fuzzing the learnt information by one or two bits at the end does not change the fact that one leaks almost as much information as the worst case scenario sending out an HTLC. Also the honest sender still has to guess what could actually be sent (despite so much information was shared)

I suggest to compare this too a situation where a channel is being probed. The expected information gain for and arbitrary HTLC is:

(1-h/c) * (log(c+1) - log(c-h+1)) + (h/c)(log(c+1) - log(h+1))

I plotted this function for a channel of size 1M sats. You will see that for an HTLC size that is half the channel size the expected information gain is maximized at 1 bit. 1 Bit of information gain is the maximum for any channel size with a single probe. This indicates that under regular circumstances an attacker can only gain 1 Bit of Entropy per probe. With the proposal we help an attacker to save a lot of probes by sharing more than 1 bit and we still leave an honest sender with uncertainty.

From a privacy perspective it seems most reasonable to just let the onion fail and let the sender find another path through the network. Given that after the failed HTLC the channel capacity effectively reduced its size to the HTLC amount the sender will most likely use the gained information of the upstream channels and select a path via a different node. Of course this would yield an opportunity cost of missed routing fees which could justify sharing the additional information. In any case I hope the analysis is of help.

also @niftynei wrote:

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.

just to summarize: If we don't share information a successful payment of amount h leaks at most log(c+1) - log(c-h + 1) bit of information. The proposal leaks log(c+1) - log(l+1) -x_fuzz bits of information (with l<h and x_fuzz the amount of bits to fuzz the hint). Thus we might not want to give more precise liquidity indications on HTLC failures.