Published on: 2021-08-25T20:06:09+00:00
In a series of conversations, developers and experts in the Lightning Network discussed the use of base fees in routing algorithms. One concern raised was that base fees could slow down the algorithm and have a multiplicative effect on split payments. It was also noted that base+proportional fees did not accurately reflect the costs of failed HTLCs or those dependent on the duration of a HTLC. The cost to nodes was primarily the opportunity cost of not being able to accept other transactions with higher fees. To capture these costs, one developer suggested setting a proportional fee and a minimum payment value.Opinions varied on how base fees should be managed going forward. Suggestions included adjusting the min_htlc_amount, shifting towards upfront fees, or setting a network-wide minimum fee at the protocol level. Some believed that eventually, everyone would set base fees to zero, while others argued that base fees were necessary to account for node operators' costs.The community also discussed simplifying the routing algorithm by setting the BOLT#7 fee_base_msat value to zero. However, concerns were raised about potential issues with small payments and leaving node operators uncompensated for their costs. Alternative solutions were proposed, such as mapping the base fee to other numbers compatible with flow-based routing, accepting smaller payments despite the HTLC minimum setting, or gradually increasing the minimum payment size as channels become overloaded. The community recognized the need to address charging for HTLC slot usage during DoS attacks and explore alternative algorithms without the drawbacks of a base fee.Accommodating micropayments within the routing algorithm was another topic of discussion. Proposals included having a minimum split size for payments below a certain threshold and using the Pickhardt-Richter algorithm with zero base fee for larger payments. Payments lower than the threshold would not be split and would follow the old try-and-try-until-you-die algorithm.To address irrational behavior and externalizing costs, a network-wide minimum fee at the protocol level of 1msat was proposed. This would allow for different payment regimes for micropayments without loss to node operators for low-value payments. Negative fees for passive channel rebalancing were also suggested for future consideration.Discussions on Twitter and other platforms centered around setting the BOLT#7 fee_base_msat value to zero. While this simplified the routing algorithm, alternative solutions were proposed to address the absence of a fixed minimum fee. These included setting a minimum payment size with a proportional fee or treating the minimum_fee setting as 1 sat instead of 5000 sats. The community also explored accepting smaller payments when channels were not busy but reserving larger slots for when the channel reached capacity. The goal was to align fees with costs and prevent payment lockup.In summary, the lightning community engaged in discussions about the problems caused by base fees in routing algorithms. Various proposals were suggested, including adjusting the min_htlc_amount, shifting towards upfront fees, or setting a network-wide minimum fee. There were debates on the necessity of base fees and the potential for them to be hardcoded to zero in the future. Solutions for accommodating micropayments and addressing irrational behavior were also explored. The community emphasized the importance of simple fee structures that accurately reflect costs and cautioned against hastily discarding the existing fee structure without thorough analysis.
Updated on: 2023-07-31T23:44:46.995197+00:00