Re: [Lightning-dev] Three Strategies for Lightning Forwarding Nodes
Good morning Michael, > Hey ZmnSCPxj > > It is an interesting topic. Alex Bosworth did a presentation at the Lightning > Hack Day last year with a similar attempt at categorizing the different > strategies for a routing/forwarding node (Ping Pong, Liquidity Battery, > Inbound Sourcing, Liquidity Trader, Last Mile, Swap etc) > > https://btctranscripts.com/lightning-hack-day/2021-03-27-alex-bosworth-lightning-routing/ > > It seems like your attempt is a little more granular and unstructured (based > on individual responses) but perhaps it fits into the broad categories Alex > suggested maybe with some additional ones? I think all the broad categories Alex suggested have a common theme: all of them are public forwarding nodes. What I point out in this writeup is the strategy that ANY public forwarding node may have. For example, a node may select passive rebalance, wall, or low fee forwarding strategies, independently of whether or not it is JUST a forwarding node, or is a merchant / personal node in addition to being a forwarding node, or is selling inbound liquidity elsewhere, or is selling onchain-offchain swap services, or multiple of those. It seems to me that the general forwarding strategy is orthogonal to the strategies that Alex presented. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Onion messages rate-limiting
Hi Matt, > Ultimately, paying suffers from the standard PoW-for-spam issue - you > cannot assign a reasonable cost that an attacker cares about without > impacting the system's usability due to said cost. Applying this statement to related a area, would you also agree that proposals to introduce pre-payments for HTLCs to mitigate jamming attacks is similarly a dead end? Personally, this has been my opinion for some time now. Which is why I advocate for the forwarding pass approach (gracefully degrade to stratified topology), which in theory would allow the major flows of the network to continue in the face of disruption. -- Laolu ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Onion messages rate-limiting
Hi Val, > Another huge win of backpressure is that it only needs to happen in DoS > situations, meaning it doesn’t have to impact users in the normal case. I agree, I think the same would apply to prepayments as well (0 or 1 msat in calm times). My main concern with relying _only_ on backpressure rate limiting is that we'd end up w/ your first scenario more often than not, which means routine (and more important to the network) things like fetching invoices becomes unreliable. I'm not saying we should 100% compare onion messages to Tor, but that we might be able to learn from what works and what isn't working for them. The systems aren't identical, but have some similarities. On the topic of parameters across the network: could we end up in a scenario where someone is doing like streaming payments for a live stream (or w/e), ends up fetching a ton of invoices (actual traffic leading to payments), but then ends up being erroneously rate limited by their peers? Assuming they have 1 or 2 channels that have now all been clamped down, is waiting N minutes (or w/e) their only option? If so then this might lead to their livestream (data being transmitted elsewhere) being shut off. Oops, they just missed the greatest World Cup goal in history! You had to be there, you had to be there, you had to *be* there... Another question on my mind is: if this works really well for rate limiting of onion messages, then why can't we use it for HTLCs as well? -- Laolu ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals
> That's not 100% reliable at all. How long to you want for the new gossip? So you know it's a new channel, with a new capacity (look at the on-chain output), between the same parties (assuming ppl use that multi-sig signal). If you attempt to route over it and have a stale policy, you'll get the latest policy. Therefore, it doesn't really matter how long you wait, as you aren't removing the channel from your graph, as you know it didn't really close. If you don't see a message after 2 weeks or w/e, then you mark it as a zombie just like any other channel. -- Laolu On Wed, Jun 29, 2022 at 5:35 PM Rusty Russell wrote: > Olaoluwa Osuntokun writes: > > Hi Rusty, > > > > Thanks for the feedback! > > > >> This is over-design: if you fail to get reliable gossip, your routing > will > >> suffer anyway. Nothing new here. > > > > Idk, it's pretty simple: you're already watching for closes, so if a > close > > looks a certain way, it's a splice. When you see that, you can even take > > note of the _new_ channel size (funds added/removed) and update your > > pathfinding/blindedpaths/hophints accordingly. > > Why spam the chain? > > > If this is an over-designed solution, that I'd categorize _only_ waiting > N > > blocks as wishful thinking, given we have effectively no guarantees w.r.t > > how long it'll take a message to propagate. > > Sure, it's a simplification on "wait 6 blocks plus 30 minutes". > > > If by routing you mean a sender, then imo still no: you don't necessarily > > need _all_ gossip, just the latest policies of the nodes you route most > > frequently to. On top of that, since you can get the latest policy each > time > > you incur a routing failure, as you make payments, you'll get the latest > > policies of the nodes you care about over time. Also consider that you > might > > fail to get "reliable" gossip, simply just due to your peer neighborhood > > aggressively rate limiting gossip (they only allow 1 update a day for a > > node, you updated your fee, oops, no splice msg for you). > > There's no ratelimiting on new channel announcements? > > > So it appears you don't agree that the "wait N blocks before you close > your > > channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144? > > Because it's simple. > > >>From my PoV, the whole point of even signalling that a splice is on > going, > > is for the sender's/receivers: they can continue to send/recv payments > over > > the channel while the splice is in process. It isn't that a node isn't > > getting any gossip, it's that if the node fails to obtain the gossip > message > > within the N block period of time, then the channel has effectively > closed > > from their PoV, and it may be an hour+ until it's seen as a usable (new) > > channel again. > > Sure. If you want to not forget channels at all on close, that works too. > > > If there isn't a 100% reliable way to signal that a splice is in > progress, > > then this disincentives its usage, as routers can lose out on potential > fee > > revenue, and sends/receivers may grow to favor only very long lived > > channels. IMO _only_ having a gossip message simply isn't enough: > there're > > no real guarantees w.r.t _when_ all relevant parties will get your gossip > > message. So why not give them a 100% reliable on chain signal that: > > something is in progress here, stay tuned for the gossip message, > whenever > > you receive that. > > That's not 100% reliable at all. How long to you want for the new > gossip? > > Just treat every close as signalling "stay tuned for the gossip > message". That's reliable. And simple. > > Cheers, > Rusty. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals
Hi Lisa, > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > indistinguishable from any other onchain usage My model of gossip v2 is something like: * there's no longer a 1:1 mapping of channels and UTXOs * verifiers don't actually care if the advertised UTXO is actually a channel or not * verifiers aren't watching the chain for spends, as channel advertisements expire after 2 weeks or w/e * there might be a degree of "leverage" allowing someone to advertise a 1 BTC UTXO as having 10 BTC capacity (or w/e) So in this model, splicing on the gossip network wouldn't really be an explicit event. Since I'm free to advertise a series of channels that might not actually exist, I can just say: ok, this set of 5 channels is now actually 2 channels, and you can route a bit more over them. In this world, re-organizing by a little corner of the channel graph isn't necessarily tied to making a series of on-chain transactions. In the realm of the gossip network as it's defined today, the act of splicing is already itself a noticeable chain signal: I see a channel close, then another one advertised that uses that old channel as inputs, and the closing and opening transactions are the same. As a result, for _public_ channels any of the chain signals I listed above don't actually give away any additional information: splices are already identifiable (in theory). I don't disagree that waiting N blocks is probably "good enough" for most cases (ignoring block storms, rare long intervals between blocks, etc, etc). Instead this is suggested in the spirit of a belt-and-suspenders approach: if I can do something to make the signal 100% reliable, that doesn't add extra bytes to the chain, and doesn't like additional information for public channels (the only case where the message even matters), then why not? -- Laolu On Wed, Jun 29, 2022 at 5:43 PM lisa neigut wrote: > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > indistinguishable from > any other onchain usage. > > I'm admittedly a bit confused as to why onchain signals are even being > seriously > proposed. Aside from "infallibility", is there another reason for > suggesting > we add an onchain detectable signal for this? Seems heavy handed imo, > given > that the severity of a comms failure is pretty minimal (*potential* for > lost routing fees). > > > So it appears you don't agree that the "wait N blocks before you close > your > channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144? > > fwiw I seem to remember seeing that it takes ~an hour for gossip to > propagate > (no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first > estimate. > I trust we'll have time to tune this after we've had some real-world > experience with them. > > Further, we can always add more robust signaling later, if lost routing > fees turns > out to be a huge issue. > > Finally, worth noting that Alex Myer's minisketch project may well > help/improve gossip > reconciliation efficiency to the point where gossip reliability is less > of an issue. > > ~nifty > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Using BOLT 8 to Send Wumbo Messages
Hi y'all, Quick post... A few weeks ago, some of the dlcspecs developers reached out to ask for feedback on this PR [1] that attempts to specify a way to send messages larger than 65 KB using BOLT 8 (Noise based encrypted transport). After taking a glance at the PR, I realized that it isn't totally obvious from reading BOLT 8 that it's actually possible to do this w/o adding any new application layer messages (as the PR proposes). As I explained in my comment [2], all the sender needs to do is chunk their messages, and the receiver reads out messages into a read buffer exposed over a stream-like interface. This is no different than using TCP/IP to send a 65 KB message over the wire: a series of messages below the Maximum Transmission Unit at each hop are sent, w/ the receiver collecting/re-ordering them all before delivering up the API stack. This was actually in the OG spec, but then was removed to make things a bit simpler. Here's my commit from way back when implementing this behavior [3]. If we wanted to re-introduce this behavior (so we can do things like increase the max HTLC limit w/o having to worry about messages being to large due to all the extra sigs), afaict, we could just add a new wumbo message feature bit. This bit indicates that a peer knows how to properly chunk and aggregate larger messages. [1]: https://github.com/discreetlogcontracts/dlcspecs/pull/192 [2]: https://github.com/discreetlogcontracts/dlcspecs/pull/192#issuecomment-1171569378 [3]: https://github.com/lightningnetwork/lnd/commit/767c550d65ef97a765eabe09c97941d91e05f054 -- Laolu ___ 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
[Lightning-dev] Inbound channel routing fees
Currently routing nodes on the lightning network charge fees based on a policy that pertains to the outgoing channel only. Several mentions have been made by routing node operators that this limits the control that they can exert over the flow of traffic. The movement of funds on all of the incoming channels is free of charge, which does not match the reality of not all inbound liquidity being equal. One option to fix this is to add two additional fields to the `channel_update` message: * `inbound_fee_base_msat` * `inbound_fee_proportional_millionths` With the previously introduced tlv message extensions, it should be possible to let these fields propagate throughout the network without any upgrades required. Senders must pay each routing node the sum of its advertised inbound and outbound fee for the channels used: outbound_fee(amt_to_fwd) + inbound_fee(amt_to_fwd + outbound_fee(amt_to_fwd)) So the inbound_fee is calculated based on the actual balance change in the incoming channel. This includes the amount to forward as well as the outbound fee. An important characteristic of any solution that is to be deployed in an existing network, is that it is backwards compatible. If routing nodes start to require inbound fees, every sender that hasn’t upgraded their node software will no longer be able to use that routing node. The routing node will miss out on routing fees. One mitigation is to charge zero inbound fees until a sufficiently large portion of the senders has upgraded. It may be unclear though when this is the case, and will likely take a significant amount of time. A test could be to temporarily charge a minimal inbound fee, and watch for a reduction in traffic and increase in `fee_insufficient` failures returned. If there is little or no effect, then most senders have probably upgraded. Another way to go about this is to set negative inbound fees during the transitory phase. It is effectively a discount for using specific inbound channels. So a routing node that charges 10 sats for forwarding today, may in the future increase that to 13 sats and set the inbound fee to -3 sats. Senders ignoring inbound fees will overpay (13 sats whereas 10 sats would have been sufficient), but are still able to use the routing node. The routing node may see a reduction in traffic though because it effectively increased its fee for older senders only. But inbound fees could be increased (decreased really because they are negative) gradually while monitoring for fee over-payments. Over-payments are indicative of senders ignoring the inbound fee discount. 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. Overall I think this can be a relatively compact change that may ultimately lead to better capital placement on the network and lower routing fees. Looking for feedback on the idea from both lightning devs and routing node operators. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
