Rusty Russell proposed a change to c-lightning that enables invoices to automatically attach an r field for a channel with sufficient incoming capacity for the amount (using a weighted probability across our peers). This isn’t quite what ‘r’ was for, but it would be a useful hint for payment routing and also potentially for establishing an initial channel. Johan Torås mentioned including “all” incoming channels with sufficient capacity.

Christian Decker thinks this may not be the best solution seeing it causes leakage of current capacity channel to the user. If the user so wishes, he can use a binary search of capacities to know how much capacity anyone has and “track it overtime” depending on the level of control they have and the nature of the amount in the invoice. However, always choosing the same channel can reduce how much information the user can access.

Russel also mentioned that in his opinion, the only means of securing the “instantaneous available bandwidth” in a node’s channel is for the node to randomly reject packets even if it has capacity to accept it, which according to Olaoluwa is not possible since all packets must be accepted before they are cancelled at the moment due to the absence of an “unadd” feature in the protocol. Under this condition, a user can send multiple packet sizes and as you accept any packet, they automatically know that you have at least the size of that packet available as bandwidth. This is a problem which he said is “mitigated a bit by the max_htlc value in the channel update (which is a sort of LN’s version of an MTU)“.

Russel shared an implementation that was done on c-lightning (server side) which can be tested against on his mainnet and testnet nodes.

Resources

• Follow discussion
• c-lightning implementation