When you create a channel on the Lightning network, you lock up funds into a smart contract known as an HTLC; those funds are now blocked from being moved on the base chain but can be moved in Lightning and avoids double-spending between the two layers. Now that you’ve locked funds into Lightning, you want to establish a channel with someone you want to pay directly or someone who has a large set of channels you can use to route payments.
Once you’ve established a channel capacity with someone, you can route through that channel based on its size. This can limit the amount of funds moving through a channel and cause certain payments to fail, making Lightning less practical for large payments.
At the moment, we have the luxury of being able to use Lightning for micropayments and the base chain for larger payments without too much hassle, but this won’t always be the case as more people come onboard, competition for block space increases and Lightning will need to facilitate larger transactions too.
To help with getting around channel capacity limitations, multi-part or multi-part payments are proposed as a solution.
What are simplified multi-path payments?
Simplified Multi-path Payments (SMPs), also known as Base AMP, are Lightning Network payments that are split into two or more parts, all sharing the same hash and preimage and are sent using a different path from one Lightning wallet to another.
Although proposed after atomic multi-path payments (AMP), simplified multi-path payments required fewer changes to the Lightning protocol to implement and preserve the ability for spenders to receive a cryptographic proof of payment, so they were the first to be deployed on the production network.
The main downside of simplified multi-path payments when using HTLCs is that third parties who see multiple payments using the same hash can infer that they’re part of a larger true payment, so these partial satoshi payments can be matched and tracked.
Both AMP and SMP allow splitting higher value HTLCs into multiple lower value HTLCs that are more likely to succeed individually, so a spender with sufficient liquidity can use almost all of their funds at once no matter how many channels those funds are split across.
The current issue with bitcoin payments on Lightning
Channels come in all sizes, and routing payments through these so-called payment tubes can hit a snag if the amount pushed through is larger than the routes available. Consider the following as an example:
- Alice has two channels with Bob
- channel 1: 1 BTC
- channel 2: 1 BTC
- Alice wants to send 2 BTC to Bob
- Bob sends a 2 BTC Lightning invoice to Alice
- Alice cannot pay the invoice because each channel only has 1 BTC
Either Alice would have to manually ask Bob for two separate invoices of 1 BTC each and conduct two payments, or the Lightning wallet should be smart enough to figure out that there is a viable payment route available.
Even though it is not explicitly stated by the invoice.
How simplified payments would route these funds
In a world where simplified multi-path payments are live, Alice would approach the problem as follows:
- Alice wants to send 2 BTC to Bob
- Step 1
- Bob sends a 1 BTC invoice to Alice
- Alice pays 1 BTC to Bob through channel 1
- Step 2
- Bob sends a 1 BTC invoice to Alice
- Alice pays 1 BTC to Bob through channel 2
Instead of manually creating two invoices, the invoices would be split on the protocol, and the payment would be processed.
Fragmenting of liquidity
The example above is a simple one to get you to understand the concept, but in reality, these payments could be split up into two, four, eight or any amount of payments all with different values. Let’s take the case of one bitcoin, which is a rather large transfer. Depending on the channels available that one bitcoin transfer could require eight transactions all in different sizes, all talking different parts and requiring a different amount of hops before it completes in Bob’s wallet.
Let’s say that one bitcoin required eight separate payment packets to be sent over in increments of
- 100 000 sats
- 200 000 sats
- 50 000 sats
- 75 000 sats
- 45 000 sats
- 250 000 sats
- 100 000 sats
- 180 000 sats
A multi-path payment can solve the problem in this case; if there are routes it can find to service the required transfer, but that doesn’t mean it is always going to find a route.
The sender doesn’t know what the balances between R1 and the recipient are, so correct partial amounts will need to be figured out through trial and error.
One can imagine that in this specific case, where there is just a single way of completing the payment, trial and error is a lengthy and impractical process as those payments keep hitting different blocks and failing and looking for a new path.
Another complicating factor in this trial and error process is that failures are reported, but successes aren’t. As long as the set is not yet complete, the receiver will hold the HTLC. Unfortunately, the sender cannot distinguish this successful outcome from an HTLC stuck somewhere midway.
We’re walking multiple paths
While this is a relatively simple explanation, you can imagine as more people are routing payments and packets of payments are split up through multi-path payments flying through channels; it can become a relatively complex feature to implement and manage.
We are at the edge of what is currently known with this technology and are exploring as we go, perhaps multi-path payments have a future in Lightning in one version or another, or new solutions are proposed in the future.
Sources:
If you’d like to learn more about multi-path payments and how they can be implemented on Lightning, and what it means for users and lightning-enabled apps, then we recommend you check out the following resources as part of your research.
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Have you tried all the forms of Lightning payments? Which one do you prefer? Let us know in the comments down below.
