Published on: 2022-09-25T19:52:17+00:00
In a Lightning Network mailing list, Lisa Neigut proposed the idea of fee ratecards to replace the current fee calculation method. The ratecards would allow channel operators to specify four different rates for a channel's liquidity, which would automatically update based on the current channel capacity. This proposal aims to enable node operators to experiment with negative fees and variable values for channel capacity.There are concerns raised about the potential side effects and drawbacks of negative fees. It is suggested that negative fees could lead to strategic behavior of routing nodes and create negative cost cycles. Additionally, there is uncertainty about the virtualization of channels into smaller channels, as it may increase payment latency and decrease reliability.Rene suggests investigating how fee ratecards interact with other proposals and combining ideas to make them even stronger. It is proposed that various fee ratecards could be used for different `htlc_maximum_msat` values, reducing failed attempts and latency for large payments.The use of feerate cards in the Lightning Network specification meeting is also discussed. Feerate cards would reduce the number of payment attempts required to find an exact channel balance and provide a lower-cost mechanism for discovering which band of payment is likely to succeed. The use of four evenly spaced buckets is suggested to simplify reasoning about information leakage.Negative fees are expected to make channel balance data a competitive advantage, encouraging node operators to guard their balances more closely. However, it is noted that payment base fees will no longer be used as they do not work with negative rates.The email conversation also delves into the topic of pathfinding algorithms and their dependence on data collection probing. There is a suggestion that failed payment attempts can be indistinguishable from data collection probing, but data collection probing is preferable as it can happen out of band without causing latency. There is a question raised about the need for channel capacities to efficiently make payments and whether that information should be gossiped.The discussion touches on the issue of privacy, scalability, and network capacity. There is a proposal to strike a balance between "probe-ability" and obfuscation of balance by using payment bands. It is suggested that fee ratecards based on time of day/week could be a better method of optimization. Concerns about centralized entities performing data collection are also addressed, with the argument that the current protocol design already incentivizes centralized efforts to collect exact balance data.Another participant in the conversation raises concerns about pathfinding algorithms and unscalable data collection. The try-and-try-again approach is seen as problematic, as high-frequency spenders gain more knowledge about successful channels and amounts, creating performance advantages over low-frequency spenders. The idealized system would have fewer forwarding failures to prevent such discrepancies. However, it is acknowledged that fee ratecards are a better alternative than frequently issuing new channel updates with modified fees.In a separate discussion, ZmnSCPxj suggests modeling a ratecard as four separate channels between the same two nodes with different costs each. This allows for trying alternative routes if the lowest-cost path fails. Concerns are raised about pathfinding algorithms that depend on unscalable data collection, which could lead to centralized entities performing data collection at the expense of network robustness and participant independence.Lisa Neigut's proposal of a ratecard is described in more detail, explaining that it is a set of four values used to price different bands of available liquidity for a channel. The use of ratecards requires estimations of the current division of funds or paying the highest ratecard for each hop. Questions are raised about whether this should be pro-rata and the challenges in obtaining precise estimates of current fund divisions.The Lightning Network's proposal for ratecards aims to enable node operators to experiment with negative fees and variable values for channel capacity. The benefits include reduced bandwidth consumption required for payment success and the ability to express fine-grained prices for existing capacity. The addition of a TLV to the channel_update gossip message containing a ratecard is suggested, with routing nodes paying based on guessed channel capacity and payment priority.Overall, the discussions revolve around the use of fee ratecards in the Lightning Network, addressing various concerns, proposals, and potential impacts on privacy, scalability, and network capacity. The conversations also touch on pathfinding algorithms, data collection probing, and the balance between probe-ability and obfuscation of balance information.
Updated on: 2023-08-01T00:41:24.465605+00:00