In the previous article about the lightning network, we discussed replenishing a payment channel on the lightning network through splicing . However, it is not always necessary to replenish a payment channel, we can also make smart use of multiple open channels for a payment.
Many roads lead to Rome
See 1 – 2 for background and 3 – 4 for additional information.
Remember that the lightning network consists of a network of payment channels between users. A user can have several payment channels open with different parties. A payment from Alice to Dave is made by using one of the possible routes that eventually links Alice to Dave.
Now suppose that Alice wants to make a payment of 0.006 BTC to Dave, but Alice does not have enough bitcoins in her payment channel with Bob to make this payment. Or, suppose Bob doesn’t have enough bitcoins in his channel with Carol, or there aren’t enough bitcoins available between Carol and Dave. How can we still make this payment without adding bitcoins by means of splicing one without opening a new payment channel between Alice and Dave?
We can use the other payment channels that Alice has open to “split” the payment and have it run through multiple routes. For example, the entire network of payment channels between Alice and other parties could look like this:
Given that Alice does have enough bitcoins in total in her payment channels with Bob, Eve and Victor, the payment can be made by using these routes. Suppose Alice has 0.002 BTC available in each channel with Bob, Eve, and Victor and wants to make a payment of 0.006 BTC to Dave. How can we do this in such a way that the entire payment arrives at the same time and parts of the payment do not accidentally go through?
We can arrange the payments in such a way that Dave cannot claim the entire payment until Dave has received all parts of the payment. Recall from the article about Hashed Time-Lock Contracts (HTLCs) sharing a secret to successfully executing a payment through intermediaries. We’re going to use a similar trick here called Atomic Multi-Path Payments (AMP), an idea from Olaoluwa “roasbeef” Osuntokun.
The sender, Alice, in this case creates the secret number P and creates three different payments that require P to claim. Then Alice splits P into three different parts: P 1 , P 2 and P 3 . Alice then adds P 1 , P 2 and P 3 to the various payments she is about to send. For payments, Alice uses the payment channels she has open with Bob, Eve and Victor.
When all payments have arrived at Dave he is able to reconstruct the original P , which is needed to claim the payments. Dave does this by combining P 1 , P 2 and P 3 . Dave can then immediately claim all payments at once, so that the payment goes through in its entirety. For example, a payment of 0.006 BTC was successfully sent from Alice to Dave, without opening new payment channels and extra on-chain transactions.
The advantages
Setting up a payment via multiple routes in this way has the clear advantage that we are no longer tied to a single route from sender to recipient. As a result, it is not necessary to have payment channels open with large amounts. This benefits decentralization, because it is possible to prevent everyone from making payments via a few large hubs. In addition, AMP helps prevent some payment channels from containing too small an amount of bitcoins, while other payment channels have a surplus, causing uneven liquidity.
AMP also has an effect on the amount of fee that will have to be paid for such a payment. While the fees for lightning transactions will already be low, avoiding large hubs also ensures that the fees for such payment are no higher than normal.
Finally, AMP promotes privacy. With a normal lightning payment, the intermediaries know how much is being sent, but not who the origin and final destination are. Applying AMP has the effect that the intermediaries no longer know exactly how many bitcoins are being sent from A to B, because they do not know how large the total payment is. In addition, a larger number of routes are available for making small payments, making it more difficult to analyze the money flow between payment channels.
