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, AFAICT). > 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. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
