Published on: 2018-12-04T18:52:58+00:00
In an email conversation between Rusty Russell and ZmnSCPxj on December 2, 2018, the topic of Lightning Network payment paths was discussed. ZmnSCPxj proposed merging failed payment paths into a single payment along the more expensive path. Rusty Russell agreed with this suggestion, stating that using "numpaths" to commit to future actions is unnecessary because the payee is only interested in the total value of the payment. This proposal would involve a temporary underpayment, but could be signaled to the payee with a simple message indicating that "more is coming." The conversation took place on the Lightning-dev mailing list.ZmnSCPxj suggests an alternative solution to the problem of multiple payment paths failing. Instead of relying on `numpaths`=3, which overcommits to future actions and may not be necessary anyway, it would be better to merge the failed paths into a single payment along the expensive 4th path. This approach would ensure that the payee receives the total value they are interested in, without getting bogged down in the details of the split. Rusty agrees with this suggestion and thanks ZmnSCPxj for their excellent point.ZmnSCPxj suggested a 2-byte "number of total pieces" as a solution, but it was discovered that this would not work for splitting the bill, where each payer is unrelated. Additionally, it would not work well for a dynamic algorithm that tries to pay the whole amount at once and then splits it if it doesn't fit. Rusty Russell explained that using `numpaths` overcommits to what you will do in the future, and is unnecessary anyway. The payee is interested in the total value, not the details of the split. They also discussed a network where there are four paths between payer and payee; three paths have low capacity but negligible feerate, while the fourth has high capacity with expensive feerates. In order to minimize fees when paying a large amount, it would be rational to split among the three low-cost paths. However, if two of those paths fail, it would be better to merge them into a single payment along the expensive fourth path.In a recent discussion about the implementation of Partial Payments (PP) in spontaneous payments, Johan Torås Halseth suggested the addition of an optional field to the invoice and letting the recipient wait until all funds have been received before pulling the payment. This proposal would not require any changes to the onion. The suggestion was discussed briefly in a previous call and it was determined that the extra bit set in the onion would be necessary to support PP in spontaneous payments. During the discussion, the use case of splitting a bill came up. It was noted that if a BOLT11 invoice does not specify an amount, it must include a specific minimum amount for successful payment. Initially, a 2-byte "number of total pieces" was suggested, but it was found that this wouldn't work well for splitting the bill since each payer is unrelated and doesn't know how the others are paying. As a solution to this issue, Rusty has written up an onion proposal to cover it.In a conversation between Johan Torås Halseth and Rusty Russell, the topic of supporting Base AMP is discussed. Johan believes that the invoice will already indicate if a node supports Base AMP, and if there is a reason to not reveal that support for certain invoices, it would simply not be specified in the invoice. This would be opt-in for both sides and not affect existing nodes. Rusty suggests having a flag on BOLT11 and inside the onion as an explicit opt-in for both sides, rather than relying on a partial payment error as a probe for Base AMP. A response from ZmnSCPxj clarifies that Rusty is referring to a probe by an intermediate node, rather than the source node which already knows if the payee supports AMP or not.In an email conversation between Johan Torås Halseth and Rusty Russell, they discuss the implementation of Base AMP (BAMP) in BOLT11. It is suggested that the receiver should assume NAMP for incoming payments, but this could result in partial payment errors if the recipient doesn't support Base AMP. Rusty suggests using a flag both on BOLT11 and inside the onion to explicitly opt-in for both sides and not affect existing nodes. Johan responds saying that it shouldn't be a problem as invoices will already indicate BAMP support, and non-BAMPy behavior can be adopted when receiving payments without specifying BAMP support in the invoice. Both parties agree that the implementation should be opt-in for both sides.In an email conversation between ZmnSCPxj and Rusty Russell, Rusty gives advice on modifying a pull request.
Updated on: 2023-07-31T20:44:43.888701+00:00