A suggestion to hint for channel capacity in BOLT 11 invoices
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.
Support us and the authors of this article by donating to the following address:3HrX9eNHfQYKqtjearwuuqgKd7dBwyZFs5