Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message: Currently routing nodes ...
📅 Original date posted:2022-07-01
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/c0768856/attachment-0001.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/c0768856/attachment-0001.html>;