{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-07-01\n📝 Original message:\nCurrently routing nodes on the lightning network charge fees based on a\npolicy that pertains to the outgoing channel only.\n\nSeveral mentions have been made by routing node operators that this limits\nthe control that they can exert over the flow of traffic. The movement of\nfunds on all of the incoming channels is free of charge, which does not\nmatch the reality of not all inbound liquidity being equal.\n\nOne option to fix this is to add two additional fields to the\n`channel_update` message:\n* `inbound_fee_base_msat`\n* `inbound_fee_proportional_millionths`\n\nWith the previously introduced tlv message extensions, it should be\npossible to let these fields propagate throughout the network without any\nupgrades required.\n\nSenders must pay each routing node the sum of its advertised inbound and\noutbound fee for the channels used:\n\noutbound_fee(amt_to_fwd) + inbound_fee(amt_to_fwd +\noutbound_fee(amt_to_fwd))\n\nSo the inbound_fee is calculated based on the actual balance change in the\nincoming channel. This includes the amount to forward as well as the\noutbound fee.\n\nAn important characteristic of any solution that is to be deployed in an\nexisting network, is that it is backwards compatible. If routing nodes\nstart to require inbound fees, every sender that hasn’t upgraded their node\nsoftware will no longer be able to use that routing node. The routing node\nwill miss out on routing fees.\n\nOne mitigation is to charge zero inbound fees until a sufficiently large\nportion of the senders has upgraded. It may be unclear though when this is\nthe case, and will likely take a significant amount of time. A test could\nbe to temporarily charge a minimal inbound fee, and watch for a reduction\nin traffic and increase in `fee_insufficient` failures returned. If there\nis little or no effect, then most senders have probably upgraded.\n\nAnother way to go about this is to set negative inbound fees during the\ntransitory phase. It is effectively a discount for using specific inbound\nchannels. So a routing node that charges 10 sats for forwarding today, may\nin the future increase that to 13 sats and set the inbound fee to -3 sats.\n\nSenders ignoring inbound fees will overpay (13 sats whereas 10 sats would\nhave been sufficient), but are still able to use the routing node. The\nrouting node may see a reduction in traffic though because it effectively\nincreased its fee for older senders only. But inbound fees could be\nincreased (decreased really because they are negative) gradually while\nmonitoring for fee over-payments. Over-payments are indicative of senders\nignoring the inbound fee discount.\n\nPath-finding algorithms that are currently in use generally don’t support\nnegative fees. But in this case, the sum of inbound and outbound fees is\nstill positive and therefore not a problem. If routing nodes set their\npolicies accidentally or intentionally so that the sum of fees turns out\nnegative, senders can just round up to zero and find a path as normal.\n\nOverall I think this can be a relatively compact change that may ultimately\nlead to better capital placement on the network and lower routing fees.\n\nLooking for feedback on the idea from both lightning devs and routing node\noperators.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/c0768856/attachment-0001.html\u003e"}