pull down to refresh
132 sats \ 6 replies \ @nullcount 18 Jul \ on: Multi-path payments in Lightning - question bitcoin
Multi-path payments (MPP) is a general term for payment splitting. There are many implementations of MPP with different attributes: https://www.gijsvandam.nl/post/all-types-of-multi-part-payments-in-lightning-network-explained/
@tolot Assuming we're only talking about Base MPP... In your first scenario:
B E A -> -> -> G -> D C F h0 h1 h2 h3 h4
NodeD creates an invoice and signals support for
base_mpp. NodeA creates two HTLCs using the same payment hash in NodeD's invoice for each HTLC. HTLC-1 is routed B->E->G->D and HTLC-2 is routed C->F->G->D. Remember, only NodeD knows the preimage for this invoice.NodeA sends both HTLCs at the same time, but they arrive at NodeD at slightly different times. NodeD gets the first HTLC and they have the preimage to redeem it, but they also know that there is a second HTLC incoming. They don't want to redeem HTLC-1 until they have HTLC-2 also. If they did prematurely redeem it, then they would have to reveal the preimage to NodeG who is also responsible for forwarding HTLC-2 and NodeG could use that same preimage to prematurely redeem HTLC-2 without actually forwarding it to NodeD.
Once NodeD has both HTLCs, they can safely redeem both of them by revealing the preimage to NodeG, etc.
Your second senario would happen in a similar way:
B E A -> I -> -> -> G -> D C F h0 h1 h2 h3 h4 h5
I think the confusion lies in this statement: "meaning two HTLCs flowing in the same channel for the first hop, then splitting and the riconverging."
The HTLC's don't "split" and "recombine". They are two seperate HTLCs. Its just like making two separate payments that happen to use some different hops and some of the same hops. Only the receiver has to worry about "combining" these HTLCs into a single payment.
Every LN channel has a limit to the number of "in-flight" HTLCs allowed on that channel. The default is 400+ HTLCs so most nodes should have no problem holding two HTLCs. It does not matter that those HTLCs happen to have the same payment hash (preimage).
Thanks for the reference!
My question precisely refers to the basic MPP part
The receiver does this by offering the basic_mpp feature in the invoice. The sender can now use multiple payments to pay the invoice. It should try to use diverse paths to the receiver, to increase the chances of success. The receiver, upon receiving the first HTLC out of the set, waits for at least 60 seconds for the other HTLCs from that set. If it receives them all, it reveals the pre-image to collect all of them. If it doesn't receive all HTLCs in time, it fails all HTLCs it did receive.
Where specifically I'm focused on
It should try to use diverse paths to the receiver, to increase the chances of success
It's not clear to me if using different paths is done simply to maximise the probability of success or also because it's not possible to have two HTLCs going through the same channel if the first is not settled yet.
reply
More paths means smaller value HTLCs. Payment success probability is higher with smaller payments. LN channels can hold hundreds of "in-flight" HTLCs simultaneously.
reply