rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 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>