Author: ZmnSCPxj 2019-06-25 22:32:42
Published on: 2019-06-25T22:32:42+00:00
The Lightning Network community is discussing an idea proposed by Ugam Kamat which involves simultaneous payment to multiple parties using the same partial route. The scenario presented is of Alice wanting to pay the bill amount to Eric, the restaurant owner and a tip to Grace, her waiter. In the current situation, Alice would have to send two payments to Eric and Grace. However, if they repurpose the onion blob in the same way as needed for spontaneous payments, there will be no path duplication. Dave would split the payments, one to Eric and the other going to Grace through Frank. The pre-image used in commitments A->B, B->C and C->D will be a function of pre-images P1 of D->E and P2 of D->F and F->G such that PM = f(P1, P2). This proposal works in a similar fashion to the Spontaneous Payment proposal, by packing additional data in the unused hops. The first byte would indicate how many hashes are packed, so the payload can be 64 + 33 bytes = 97 bytes. The first hop tells D the short-channel id, the amount to forward, CLTV and the padding. Since the pre-image is 32 bytes, it can be packed in one single hop that is received by the final party. This leaves the remaining 7 hops that can be used for routing.Under Scriptless Script (payment point / scalar), this is possible to do while retaining a form of proof-of-payment. However, note that the proof-of-payment scalar will be the sum of Eric and Grace proof-of-payment scalars. It is uncertain if that provides undeniable proof that you paid Grace or Eric. One solution would be to route through Eric and leave Eric with a higher-than-normal fee, which retains an undeniable proof-of-payment of Grace. Eric would not provide proof-of-payment, but in this scenario, given it seems, it is a "tip" and the actual payment is to the restaurateur Grace. In any case, this is effectively simply creation of fork points and join points along a multipart path. That the payment does not later join is merely a detail, especially once we get to "high" AMP (which requires payment points / scalars). We decided at the previous dev summit not to implement this due to complexity-of-implementation for payers, as well as how to resolve when one branch fails while the other branch claims the payment.
Updated on: 2023-06-02T19:00:34.720579+00:00