"AMP" doesn't solve Lightning Network's Liquidity Issue
In this article, I discuss the the latest Lightning Network proposal, called "AMP", and explain why it doesn't solve the major problem of liquidity. AMP stands for "Atomic Multipath Payments", and the basic idea is that if you can't find a route for a $6 payment, you could instead use 3 separate routes of $2. While this may add some flexibility to the system, it doesn't solve the main problem of inadequate liquidity.
You can see there's an inverse relationship between transaction size and the success rate. The bigger the payment, the more often it fails. The idea of breaking up a large payment into smaller payments sounds good, but for a group of multiple payments to atomically succeed, every payment in the group has to succeed. If we look at this from a probabilistic perspective, the odds of independent events occurring is calculated by multiplying the probabilities together. Think of rolling a die. You have a 1/6 chance to roll a 1, but you have a 1/216 chance to roll three 1's in a row. Generally, different payments would be independent events since the route going from Alice to Bob doesn't depend on the route going out from Alice to Carol. So, while the chances to route a smaller payment have gone up, the chances to route all of them might not be higher. They could actually be lower.
The mathematical probabilities become more complex when we consider combinations: For example, if Alice has 10 channels open, what is the probability that any combination of 3 of the channels might work for her? This kind of problem is usually solved with calculations based on binomial distributions -- specifically the cumulative distribution function of the binomial. If you're so inclined, you can play around with a binomial calculator:
For example, if we imagine Alice has a 10 different channels and each has a 10% chance of success and she needs to route 1 payment successfully, we can plug these values into the calculator to arrive at a 65% chance of success (see the last box).
Intuitively, we should have a 50% chance rather than 65% if we tried 10 times and each try has a 10% win rate. Indeed, we will converge at 50% if we increase the number of trials and successes in proportion. For example, (.1, 1000, 100)
No Free Lunch
Splitting your money up into more channels doesn't provide any inherent advantage. As you increase the probability of success of a single trial (p) and also increase the number of successes required (k) in proportion, the overall probability (P) remains unchanged. For example, .2, 100, 20... or .4, 1000, 400.
There's a lot of interesting things that can happen with this probability distribution; for example if you go slightly above expectancy (say an 11% win rate with 10% of the trials requiring success), you'll approach a limit of 100% (certainty) that the overall experiment succeeds as the trials become large...and you'll approach 0% if you use 9% win rate on the same experiment. It can get a little confusing to think about, but the basic principle is unchanged: You can increase the probability of success on a single event, but increasing the number of successes required has an opposing effect on the probability of the experiment as a whole. If you want a way to formally express this idea, we can look to the generalization of the binomial distribution in the normal, or (in the case when p is relatively small), the poisson. Here is a nice proof of the later. The bottom line is that there's no free lunch or math trick that can be exploited here. The probabilities are what they are at each level of transaction size in the system.
Can't We Just Open More Channels?
The user can always force his way into higher probabilities of success by trying more times or adding more channels, which brings up a question: If there's a certain low threshold amount where a lot of payments will succeed, why can't everyone just send payments of that amount -- and if you need a bigger payment, just send multiple small payments? This would simply eat up the liquidity available at those payment levels. Low transaction amounts have high probability because they don't demand much capacity, but raising the demand in aggregate would use those routes up, and we're back to square one. Another question is: why can't people just open up more small channels for their own usage, which then also provides liquidity to others in the network who will use small channels? Since payments require multiple hops, each channel opened for usage requires multiple channels for routing. In that sense, liquidity is consumed faster than it is created. While it is true that the channels only need the liquidity during a transaction (which could be brief), we still need that liquidity in the system, which goes back to the original problem of users having to deposit much more than they actually want to transact with. Also, the more people open small channels, the more on-chain transactions are required for both opening and closing the channel.
They Still Don't Get It.
I saw a funny comment on r/bitcoin when I started looking into this:
"This is so bizarre. SegWit, CT, Lightning Factories, MAST, Schnorr, Taproot, Graftroot and now AMP. Bitcoin's fundamentals are becoming stronger and stronger while the price plunges." Sorry, but Bitcoin's fundamentals aren't based on cool technology or "clever solutions". It's based on the utility of being able to send electronic cash to anyone in the world quickly and cheaply... something that Bitcoin Cash does very well and which the lightning network does not.
15 of 15 reviewers say it's worth paying for
0 of 15 reviewers say it's not worth paying for