Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-21 📝 Original message: > That might not be so ...
📅 Original date posted:2018-09-21
📝 Original message:
> 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 <johanth at 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.christian at 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 <johanth at 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 <rusty at 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >>
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180921/034910ba/attachment.html>;
📝 Original message:
> 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 <johanth at 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.christian at 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 <johanth at 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 <rusty at 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 at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >>
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180921/034910ba/attachment.html>;