[Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity
rusty at blockstream.com
Wed Sep 26 23:03:33 UTC 2018
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> That might not be so desirable, since it leaks the current channel
>> capacity to the user
>>From my PoV, the only way a node can protect the _instantaneous_ available
> bandwidth in their channel is to randomly reject packets, even if they have
> the bandwidth to actually accept and forward them.
> Observe that if a "prober" learns that you've _accepted_ a packet, then
> they know you have at least that amount as available bandwidth. As a result,
> I can simply send varying sat packet sizes over to you, either with the
> wrong timelock, or an unknown payment hash.
Yes. You have to have a false capacity floor, which must vary
periodically, to protect against this kind of probing (randomly failing
attempts as you get close to zero capaicty is also subject to probing,
> Since we don't yet have the
> "unadd" feature in the protocol, you _must_ accept the HTLC before you can
> cancel it. This is mitigated a bit by the max_htlc value in the channel
> update (basically our version of an MTU), but I can still just send
> _multiple_ HTLC's rather than one big one to attempt to ascertain your
> available bandwidth.
This is orothogonal. There's no point probing your own channel, you're
presumably probing someone else's.
More information about the Lightning-dev