Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message: Hi Bastien, I vaguely ...
📅 Original date posted:2022-07-01
📝 Original message:
Hi Bastien,
I vaguely remembered that the idea of inbound fees had been discussed
before. Before writing my post, I scanned through old ML posts and bolts
issues but couldn't find the discussion. Maybe it was part of a different
but related email or a bolts pr?
With regards to your objections, isn't it the case that it is always
possible to DoS your peer by just rejecting any forward that comes in from
them? Or indirectly affecting them negatively by setting high fees on all
outbound channels? To me it seems that there is nothing to lose by adding
inbound fees.
My thinking is that if I accept an incoming htlc, my local balance
increases on that incoming channel. My money gets locked up in a channel
that may or may not be interesting to me. Wouldn't it be fair to be
compensated for that?
Any thoughts from routing node operators would be welcome too (or links to
previous threads).
Joost
On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Hi Joost,
>
> As I've already stated every time this has been previously discussed, I
> believe
> this doesn't make any sense. The funds that are on the other side of the
> channel belong to your peer, not you, so they're free to use it however
> they
> want. If you're not happy with the way your peer is managing their fees,
> then
> don't open channels to them and let the network decide whether you're
> right or
> not.
>
> Moreover, you shouldn't care at all. If all the funds are on your peer's
> side,
> this isn't your problem, you used up all the money that was yours. As long
> as
> the channel is open, this is free inbound liquidity for you, so you're even
> benefiting from this.
>
> If Alice could set fees for Bob's side of the channel, Alice could
> arbitrarily
> DoS Bob's payments by setting a high fee. This is just one example of the
> many
> ways this idea completely breaks the routing incentives.
>
> Cheers,
> Bastien
>
> Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a
> écrit :
>
>> Path-finding algorithms that are currently in use generally don’t support
>>> negative fees. But in this case, the sum of inbound and outbound fees is
>>> still positive and therefore not a problem. If routing nodes set their
>>> policies accidentally or intentionally so that the sum of fees turns out
>>> negative, senders can just round up to zero and find a path as normal.
>>>
>>
>> Correction to this:
>>
>> The sum of inbound and outbound are not the fees set by one single
>> routing node. When path-finding considers a candidate hop, this adds the
>> outbound fee of the "from" node and the inbound fee of the "to" node.
>> Because those nodes don't necessarily coordinate fees, it may happen more
>> often that the fee goes negative. Rounding up to zero is still a quick fix
>> and better than ignoring inbound fees completely.
>> _______________________________________________
>> 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/20220701/5b33a7c3/attachment.html>;
📝 Original message:
Hi Bastien,
I vaguely remembered that the idea of inbound fees had been discussed
before. Before writing my post, I scanned through old ML posts and bolts
issues but couldn't find the discussion. Maybe it was part of a different
but related email or a bolts pr?
With regards to your objections, isn't it the case that it is always
possible to DoS your peer by just rejecting any forward that comes in from
them? Or indirectly affecting them negatively by setting high fees on all
outbound channels? To me it seems that there is nothing to lose by adding
inbound fees.
My thinking is that if I accept an incoming htlc, my local balance
increases on that incoming channel. My money gets locked up in a channel
that may or may not be interesting to me. Wouldn't it be fair to be
compensated for that?
Any thoughts from routing node operators would be welcome too (or links to
previous threads).
Joost
On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Hi Joost,
>
> As I've already stated every time this has been previously discussed, I
> believe
> this doesn't make any sense. The funds that are on the other side of the
> channel belong to your peer, not you, so they're free to use it however
> they
> want. If you're not happy with the way your peer is managing their fees,
> then
> don't open channels to them and let the network decide whether you're
> right or
> not.
>
> Moreover, you shouldn't care at all. If all the funds are on your peer's
> side,
> this isn't your problem, you used up all the money that was yours. As long
> as
> the channel is open, this is free inbound liquidity for you, so you're even
> benefiting from this.
>
> If Alice could set fees for Bob's side of the channel, Alice could
> arbitrarily
> DoS Bob's payments by setting a high fee. This is just one example of the
> many
> ways this idea completely breaks the routing incentives.
>
> Cheers,
> Bastien
>
> Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a
> écrit :
>
>> Path-finding algorithms that are currently in use generally don’t support
>>> negative fees. But in this case, the sum of inbound and outbound fees is
>>> still positive and therefore not a problem. If routing nodes set their
>>> policies accidentally or intentionally so that the sum of fees turns out
>>> negative, senders can just round up to zero and find a path as normal.
>>>
>>
>> Correction to this:
>>
>> The sum of inbound and outbound are not the fees set by one single
>> routing node. When path-finding considers a candidate hop, this adds the
>> outbound fee of the "from" node and the inbound fee of the "to" node.
>> Because those nodes don't necessarily coordinate fees, it may happen more
>> often that the fee goes negative. Rounding up to zero is still a quick fix
>> and better than ignoring inbound fees completely.
>> _______________________________________________
>> 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/20220701/5b33a7c3/attachment.html>;