Published on: 2020-08-16T19:10:13+00:00
ZmnSCPxj suggests using a Fibonacci sequence to split payments instead of the current method of splitting by half in adaptive splits. This would result in fewer splits and better utilization of channel capacity. Currently, `lnd` uses power-of-two splitting, which can require more splits than the worst-case scenario for the Fibonacci sequence. By dividing payments based on the Golden Ratio, which approximates the ratio between consecutive Fibonacci sequence entries, an approximate Fibonacci sequence can be achieved.The C-Lightning MPP implementation is facing a limitation on the number of HTLCs a channel can have. Initially, the plan was to allocate 10 HTLCs for every channel with outgoing capacity. However, this neglected the incoming number-of-HTLCs limit of the payee, leading to issues. The use of the same failure code, "temporary_channel_failure," for both hitting the msat capacity and number of HTLCs limits exacerbated the problem. As a result, the payment subsystem continued to split payments into smaller amounts, causing more than 100 outgoing payments and preventing the receiver from being able to receive them. To resolve this issue, it is suggested to consider the number of channels the payee has and use it as a basis for determining the number of HTLCs the receiver can get. The lower value between this and the outgoing channels of the payer should be used. Taking into account the number of channels for both the payer and the payee may be the solution to fix the issue.Generating invoices for Lightning Network payments becomes challenging when all channels are unpublished. To receive funds, nodes can use Multiple Payment Protocol (MPP) to accept payments from multiple payers with sufficient incoming capacity. However, generating invoices with routehints for payers with limited overlap in their routehints is crucial to avoid deadlock between payments. The author proposes a round-robin strategy to select routehints and generate multiple invoices, each with different sets of routehints. Additionally, privacy concerns arise as fake payers may probe and discover entry points used by the payee to connect to the public network. Therefore, it is recommended to avoid using unpublished channels.Settling MPP payments split into sub-payments also poses challenges for the payer. Currently, the paymod system uses a single sequence of routehints for all sub-payments, causing them to execute on the same routehint. To mitigate the risk of deadlock, each sub-payment should have a different sequence of routehints to try. The author suggests a round-robin distribution of routehints among sub-payments, where each sub-payment receives the entire list of routehints in a different order.Furthermore, it is advised that the first hop in the payment process should avoid using the same set of resources as much as possible. The Lightning Network proposes a solution to reduce congestion by coordinating sub-payments in a round-robin order. This involves maintaining a list of outgoing channels for each sub-payment and shuffling local channels at the start of the payment. Outgoing channels are distributed based on the same round-robin algorithm. When a sub-payment executes, it selects routehints using a similar algorithm to the invoice case. The algorithm removes the channel from the front of the round-robin list, appends it to a removed list, and considers splitting the payment if the round-robin list is empty. It skips channels with insufficient outgoing capacity or that are dead ends but breaks out of the loop if the channel has sufficient capacity.
Updated on: 2023-07-31T23:00:31.898913+00:00