Published on: 2019-06-29T06:50:07+00:00
Ugam Kamat proposed a new idea for simultaneous payments to multiple parties using the same partial route. The proposal suggests repurposing the onion blob in a similar way as needed for Spontaneous Payments, which would eliminate path duplication. However, Christian Decker pointed out a potential loophole in the proposal that could lead to DoS and failure attacks. Christian referred to a current proposal implemented by ElementsProject/lightning and lightningnetwork/lightning-rfc/pull/619 that allowed variable payloads instead of fixed 65 byte frames.Ugam's proposal works similarly to the Spontaneous Payment proposal by packing additional data in the unused hops. The onion blob for B and C will be identical to other lightning payments, and when D parses the onion, the 4 MSB of the realm will indicate how much data can be extracted. This data will encode the hashes of the pre-images for commitment transactions towards Eric and others. Ugam suggests using 2 onion blobs for simplicity and privacy, with a payload of 64 + 33 bytes = 97 bytes. The onion data is encoded in the same order as the payment hashes are packed in the bifurcation data for D. Eric and Grace will parse the onion and use the pre-images for settlement.Ugam suggests calculating PM = f(P1, P2) using SHA256(P1 || P2 || ss_d), where || represents concatenation and ss_d is the shared secret created using the ephemeral public key of the sender and private key of Dave. The proposal has several advantages, including lower fees in case of on-chain settlement, lower routing fees, more number of HTLCs in flight, and the usability of the route if each payment of Eric and Grace is below the htlc min B or C accepts, but together if it is higher. However, the probability of transaction failures increases as now the transaction is dependent on 2/3 branches.Christian has proposed a change in the proposal to allow variable payloads instead of fixed 65 byte frames. This can be implemented by repurposing the onion blob in a similar fashion as Spontaneous Payments with slight modification. The proposal works similarly to the Spontaneous Payment proposal by packing additional data in the unused hops. Commitment transactions between A & B, B & C, and C & D now carry only one HTLC instead of two, resulting in lower fees for on-chain settlements and routing fees for Alice.Ugam appreciates ZmnSCPxj's analysis of the proposal for FAST (Forked Away Simultaneous Transactions) and acknowledges the two choices mentioned for the proposal. The first option is that both forked branches must succeed for the fork node to claim its incoming payment. The second option is that either forked branch can succeed and the fork node can claim its incoming payment. However, ZmnSCPxj notes that if they go with the second option, fork nodes can attack opportunistically by only paying out to the smaller-valued branch and forgetting about the other branch of the payment. ZmnSCPxj suggests a plausible fix for the scheme where Eric and Grace need to cooperate and only take incoming payment if both of them receive it, requiring trust between them.The discussion concludes by highlighting the issue of fork points and join points along a multipart path in a payment system. It is noted that the lack of a later join point allows for potential attacks. There are two choices to address this issue, but both have their own vulnerabilities. The plausible solution is to choose the second option and have Eric and Grace coordinate to only take incoming payment if both of them receive it, but this requires trust between them. Multipart payments have a later join point, preventing fork nodes from performing opportunistic attacks.The Lightning Network community is discussing Ugam Kamat's proposal for simultaneous payments to multiple parties using the same partial route. The proposal involves repurposing the onion blob and packing additional data in unused hops. This would eliminate path duplication and reduce fees for on-chain settlements and routing fees. However, there are concerns about the increased probability of transaction failures as the transaction is dependent on 2/3 branches. Not all nodes need to support this feature, and nodes that can handle branching of payments can signal their support using global features.Overall, the proposal aims to improve efficiency and reduce fees in the Lightning Network by enabling simultaneous payments to multiple parties using the same partial route.
Updated on: 2023-07-31T21:45:12.018280+00:00