[Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

Olaoluwa Osuntokun laolu32 at gmail.com
Sat Sep 29 01:48:34 UTC 2018


> This is orothogonal.  There's no point probing your own channel, you're
> presumably probing someone else's.

In my scenario, you're receiving a new HTLC, from some remote party
unbeknownst to you. I was replying to cdecker's reply to johan that one
wouldn't always add this new type of routing hint for all channels since it
leaks available bandwidth information. Without something like an "unadd" you
can't do anything against an individual attempting to prob you other than
drop packets (drop as in don't even add to your commit, resulting in an HTLC
timeout), as if you cancel back, then they know that you had enough
bandwidth to _accept_ the HTLC in the first place.

-- Laolu


On Wed, Sep 26, 2018 at 5:54 PM Rusty Russell <rusty at blockstream.com> wrote:

> 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,
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180928/3fae8786/attachment.html>


More information about the Lightning-dev mailing list