Published on: 2021-08-30T12:32:30+00:00
The email exchange discusses a proposed protocol change for the transport layer of HTLCs/PTLCs to support local payment splits and merges. The author suggests a new lightning message called `update_update_htlc` to update the amount of an HTLC committed/offered to a channel to reflect flows more accurately. This change would have several consequences, including the need for a cancellable payment mechanism, adopting a transport mechanism to optimize flow for success probabilities, and adding Friend of a Friend Balance sharing to reduce uncertainty around senders and recipients. The author also suggests deprecating the base fee on a protocol level. Another email thread explores the issue of an HTLC of size X arriving at a channel with less liquidity than X. It discusses the cost function defined in Pickhard-Richter and the possibility of including a base fee. An alternative solution proposed is to optimize for a maximum fee instead of optimizing for the exact fee, effectively converting the base fee to a proportional fee.The Lightning Network (LN) protocol could be modified to allow the source to instruct arbitrary intermediate nodes to join and/or split payments, which would allow the output of the mincostflow algorithm to be used directly. However, if any hop fails, the entire payment fails and has to be restarted "from the top." This scheme may increase privacy as less information can be extracted by surveillors, but the practicality of whole-flow payments is yet to be considered. If a hop fails to deliver, some join nodes would be left waiting for an incoming HTLC that will not arrive. The failure would have to be handled by a split node when it receives an update_fail_htlc. However, that split node cannot propagate the failure backward to the source if other outgoing HTLCs are still in play, leading to some interesting choices.Stefan Reitshamer addresses misunderstandings regarding the min-cost flow problem with concave functions. While finding good solutions for a subset of problems may be easier, the LN-graph may have structures that make finding a solution easier. ZmnSCPxj suggests an alternative solution to non-zero base fees by optimizing for a maximum fee instead of the exact fee. By splitting up the payment into smaller bunches of value, the mincostflow algorithm solves individual bunches rather than individual msats, effectively converting the base fee to a proportional fee. The LN protocol could also be modified to allow the source to instruct arbitrary intermediate nodes to join and/or split payments, which would simplify the use of the mincostflow algorithm. However, this would mean that if any hop fails, the entire payment fails and needs to be restarted from the beginning.The article highlights the feasibility of a proposed scheme for Lightning Network (LN) involving whole-flow payments. In this scheme, only one HTLC would be paid for each channel with non-zero flow using a single 'base_fee', avoiding underestimation of the base fee for non-zero base fee channels. However, if any hop fails to deliver, the entire payment fails and has to be restarted from the beginning. The current LN scheme splits only at the source and joins only at the destination, where if any hop of an MPP fails, only the sub-payment(s) going through that hop will need to be retried. Despite the benefits of the proposed scheme, there are concerns that it is not practical since a failed hop would leave some join nodes waiting for an incoming HTLC that will never arrive. To address this issue, the article suggests that a split node could give a request-to-fail signal to its other outgoing HTLCs, which would fail all its incoming HTLCs so that the entire payment fails and needs to be restarted from the top. Another solution proposed in the article is to modify the LN protocol such that instead of MPP having individual sub-payments that split at the source and join at the destination, the source can instruct arbitrary intermediate nodes to join and/or split payments. This would allow the output of the mincostflow algorithm to be used directly, without the problematic disect stage.The cost function defined in Pickhardt-Richter can include a base fee, but the current Pickhardt-Richter scheme cannot work with non-zero base fees if it were modified to consider fees due to the disect algorithm. An alternative solution would be to optimize for a maximum fee rather than optimizing for the exact fee. This effectively converts the base fee to a proportional fee and may help create a practical payment algorithm that handles current LN with non-zero base fees. Finally, having particular split amounts is helpful to reduce the ability of intermediate nodes snooping on payment amounts, and it may be practical to have the payment unit adjustable by a higher-level process. The article presents different options: supporting whole-flow payments or sticking to the current scheme of partial failure of MPP.
Updated on: 2023-07-31T23:45:56.528619+00:00