Re: [Lightning-dev] Inbound channel routing fees
On 7/1/22 08:02, Joost Jager wrote:> Any thoughts from routing node operators would be welcome too (or links > to previous threads). I'm a routing node operator and have been for over a year. I've been wanting this feature (plus negative fees) for a long time now. Reason 1: For peers that tend to be liquidity sources (i.e. the liquidity tends to be all on my side), there's currently no way to keep a channel in balance with fees. All I can do is set a zero outbound fee and usually that's not good enough :/. A high inbound fee would discourage payments through that route. Reason 2: Not all inbound traffic is created equally. If two different peers wish to route through me to the same outbound peer, I may value the two forwards differently depending on who the sender is. E.g. A->C where A is a great peer that I frequently route payments to B->C where B is a peer that I rarely route payments to, or otherwise wish to preserve more inbound from I'm much happier routing A->C than I am routing B->C, but there's currently no way of expressing this to the market through fees. All I can do is htlc-intercept B->C and reject it, but this damages my reputation obviously. Reason 3: Greater expressivity in fee-setting generally allows markets to push more flows off-chain without having to loop or open new channels. While I think negative fees would be more impactful for this, inbound fees are helpful as well. Combining negative + inbound fees is where the real magic would happen IMO. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Inbound channel routing fees
On Fri, Jul 1, 2022 at 2:17 PM Thomas HUET wrote: > It was discussed in this issue: > https://github.com/lightning/bolts/issues/835 > Ah yes that was it. Thanks for the pointer! > 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. > I'd think that if a merchant charges inbound fees, others won't open channels and the merchant won't have inbound liquidity. So why would they do this? Also if they wanted to charge inbound fees, they could already do so today by setting up a fee-charging gateway with a private channel to the main node that accepts the payments. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Inbound channel routing fees
> > > 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). > If I understand it correctly, we're talking about nodes A and B, where B is malicious and sets a high inbound fee on the A-B channel? I'd think that for the network, it's actually better if B advertises their high inbound fee and nobody even tries that route, instead of everyone trying and having to wait for a failure because B drops packets? > 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. > Isn't the same true for a high inbound fee set by B? This would make it clear to everyone that B is the node that makes the A-B channel too expensive to be useful? > 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. > I fundamentally disagree with not giving nodes tools to misbehave. To me this indicates that the system is fragile. I'd actually rather go the opposite way: give them tools and show that the system is unaffected. But on the point of DoS'ing a particular node: I think there are so many ways to do this already, that inbound fees probably won't be the tool of choice even if it was available. > > 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. > It's different, but in my view not completely different. If a routing node all of a sudden decides to charge 10% outbound across all channels for whatever reason, its peers will be affected because their capital will at that point be misplaced for earning routing fees. If you say 'shoot themselves in the foot', you seem to have a rational routing node in mind looking to maximize fees? How does DoS'ing a particular peer fit in that picture, why would they do this? > > 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? > Agreed, if it isn't interesting at all, you should close. I should have put that more nuanced. Some channels will likely be more interesting than others and inbound fees could help with keeping the less interesting ones afloat. It's another option besides plainly closing the channel. Suppose I have three peers A, B and C. I am routing traffic back and forth between A and B at a low fee of 0.1%. Then C comes along and opens a 1 BTC channel with me. They push out the full balance towards B and pay 0.1% for that. After that, there is very minimal activity and after a month I decide to close the channel. A big opportunity cost for me because I could have placed that 1 BTC local balance in a much better way. With an inbound fee, I could have earned more. > 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 > I'd say that the lack of inbound fees requires more trust from the acceptor of the channel and leads to more centralization. > , 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). > Yes, can see that work too. The advantage of an inbound fee though is that the fee that you pay is proportional to the balance of the counter party. So you only start paying when you actually move the balance and you don't need to pay everything upfront (which requires some trust from the initiator). Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Inbound channel routing fees
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 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 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 >> 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 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
Re: [Lightning-dev] Inbound channel routing fees
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 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 > 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 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@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
Re: [Lightning-dev] Inbound channel routing fees
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 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 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@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
Re: [Lightning-dev] Inbound channel routing fees
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 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@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
Re: [Lightning-dev] Inbound channel routing fees
> > 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
