From rusty at blockstream.com Wed Sep 26 23:03:33 2018 From: rusty at blockstream.com (Rusty Russell) Date: Thu, 27 Sep 2018 08:33:33 +0930 Subject: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity In-Reply-To: References: <877ejg9avy.fsf@rustcorp.com.au> <878t3wd3zx.fsf@gmail.com> Message-ID: <878t3nn9oa.fsf@rustcorp.com.au> Olaoluwa Osuntokun 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.