Olaoluwa Osuntokun <laol...@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.

Lightning-dev mailing list

Reply via email to