Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message: Hi Joost, > isn't it the ...

📅 Original date posted:2022-07-01
📝 Original message:
Hi Joost,

> isn't it the case that it is always possible to DoS your peer by just
rejecting any forward that comes in from them?

Yes, this is a good point. But there is a difference though. If you do that
with inbound fees, the "malicious" peer is able to prevent _everyone_ from
even trying to route through you (because it's advertised).

Whereas if they selectively fail HTLCs you forward to them, only the payer
for
that HTLC knows about it, and they can attribute the failure to the
malicious
node, not to you.

Of course, that malicious node could also withhold the HTLC or return a
malformed error, but unfortunately we cannot easily protect against this.
My point is that this is bad behavior, and we shouldn't be giving more
tools for nodes to misbehave, and inbound fees are a very powerful tool
to help misbehaving nodes.

> Or indirectly affecting them negatively by setting high fees on all
outbound channels?

This case is completely different, because the "malicious" node can't
selectively
advertise that, it will affect traffic coming from all of their peers so
they
would really be shooting themselves in the foot if they did that.

> 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?

If that channel isn't interesting to you, then by all means you should fail
that HTLC or close the channel? Or you shouldn't have accepted it in the
first place?

I understand the will to optimize revenue here, but I fear this concrete
proposal leads to many kinds of unhealthy incentives. I agree that there is
a
risk in accepting channels from unknown nodes, but I think it should be
addressed differently: you could for example make the opener pay a fee when
they open a channel to you to compensate that risk (some kind of reversed
liquidity ads).

Cheers,
Bastien

Le ven. 1 juil. 2022 à 14:17, Thomas HUET <thomas.huet at acinq.fr> a écrit :

> Hi Joost,
>
> It was discussed in this issue:
> https://github.com/lightning/bolts/issues/835
>
> On the network, the traffic is not balanced. Some nodes tend to receive
> more than they send, merchants for instance. For the lightning network to
> be reliable, we need to incentivise people to open channels to such nodes,
> or else there won't be enough liquidity available and payments will fail.
> The current fee structure provides this incentive: You pay some onchain
> fees and lock some funds and in exchange you will earn routing fees. My
> concern is that your proposed change would break that incentive and make
> the network less reliable.
>
> Thomas
>
> Le ven. 1 juil. 2022 à 14:02, Joost Jager <joost.jager at gmail.com> a
> écrit :
>
>> 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
>>>>
>>> _______________________________________________
>> 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/c3c96202/attachment-0001.html>;