> 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. 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. -- Laolu On Thu, Sep 20, 2018 at 1:31 AM Johan Torås Halseth <joha...@gmail.com> wrote: > I was thinking you could just make many requests to get the same > information, but if you always choose the same channel as long as its > capacity meets the requirement, then not much is learnt :) > > > > On Thu, Sep 20, 2018 at 9:26 AM Christian Decker < > decker.christ...@gmail.com> wrote: > >> That might not be so desirable, since it leaks the current channel >> capacity to the user. Depending on how fine grained the amount in the >> invoice is and how the user can control it, he could do a binary search >> over capacities and very reliably tell how much capacity you have and >> track it over time. That is still the case for a single channel, but if >> you always chose the same channel it reduces how much info is leaked. >> >> Cheers, >> Christian >> >> Johan Torås Halseth <joha...@gmail.com> writes: >> > Any reason not to include _all_ (up to a limit) incoming channels with >> > sufficient capacity? >> > >> > Cheers, >> > Johan >> > >> > On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <ru...@blockstream.com> >> wrote: >> > >> >> Hi all, >> >> >> >> I'm considering a change to c-lightning, where `invoice` would >> >> automatically append an 'r' field for a channel which has sufficient >> >> *incoming* capacity for the amount (using a weighted probability across >> >> our peers). >> >> >> >> This isn't quite what 'r' was for, but it would be a useful >> >> hint for payment routing and also potentially for establishing an >> >> initial channel. This is an issue for the Blockstream Store which >> >> deliberately doesn't advertize an address any more to avoid >> >> centralization. >> >> >> >> Thoughts welcome! >> >> Rusty. >> >> _______________________________________________ >> >> Lightning-dev mailing list >> >> Lightning-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> >> > _______________________________________________ >> > Lightning-dev mailing list >> > Lightning-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
