Lightning Network has 1% success rate with transactions larger than $200

Lightning Network, a technology often touted as the solution to Bitcoin’s scalability problem, has been growing leaps and bounds in popularity in the recent months in spite of being at a nascent stage. The technology has been tested successfully for processing micro-transactions swiftly. But it seems Lightning Network still struggles with transferring bigger amounts.

Lightning Network can only ensure 100 percent success rate for transactions of up to three cents, a report by cryptocurrency research firm Diar suggests.

The publication found that anytime someone uses the Lightning Network to transfer a sum larger than $5, there is 50-percent chance the transaction could fall through. The chance of failure is even more striking with bigger amounts. Sending $490 – the maximum amount currently allowed on the network – has only one-percent chance of success.

Diar sourced the data from Reddit user YeOldDoc who used lnmainnet.gaben.win to plot the probability of successfully routing a payment between random nodes on the Lightning Network. YeOldDoc made the calculations based on how many nodes have the capacity to route a payment of that size.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

One interesting takeaway from the Diar research is that despite its rapid channel growth, Lightning Network has yet to improve the transaction efficiency of its system. As pointed out by Cornell University computer science professor Emin Gün Sirer, the number of Lightning Network routes has grown 10 times in the past five months, but the probability of successful routing has not increased at all.

Developers have been implementing Lightning Network payments for fun activities online in order to test its utility for micro-transactions. This includes playing Pokemon with it, buying candies, or doodling penises on a graffiti board. But, we are yet to see any implementation for payments above a few dollars.

The total network capacity of Lightning Network crossed $150,000 in April with more than 2,000 active running nodes and 6,600 channels. At the time of writing, the total network capacity seems to be still nearly the same, with more than 2,500 nodes and 7,800 channels.

Lightning Network acts as a “second layer” to a payments blockchain, allowing for faster transactions with very little transaction fees. The Network works by creating “channels” between nodes.

Any two nodes on the Lightning Network can agree to hold their coins on a common wallet. The channel is essentially a multi-sig wallet — where the consent of both parties are required before funds can be moved out. This wallet is then registered on the blockchain.

This process means that the wallet now acts as a ‘payments channel,’ which can be used to pay the cryptocurrency without requiring to register the transaction on the blockchain. When they finally close the channel, the resulted transaction is recorded on the blockchain as one transaction. This allows the two parties to carry out swift transactions with low fees, as their transactions don’t have to wait for miner confirmations every time.

This doesn’t mean that you need to create a channel every time you want to transact with someone. You can use existing channels of the people you are connected with.

But there is a catch. For the transaction to go through, everyone involved in the transaction will have to be online. This includes you, the person you are sending the money to, and, if you are using someone else’s channel, then they have to be online as well.

In addition, the channel — you are making the transaction through — should have enough funds to support your transaction, that is, twice the amount of the transaction value.

This is what gives rise to the payments not going through for larger amounts.

Through current means, if you want Lightning Network to process large transactions, you need nodes that can create larger channels that can always be online.

Clearly, individuals are less likely to fit the bill.

Large cryptocurrency exchanges can create Lightning channels to increase its network capacity and increase the probability of transactions going through. But as Diar points out, opening up a Lightning channel will likely land them in regulatory trouble.

The exchanges are required to perform know-your-customer (KYC) and anti-money-laundering (AML) checks on users of their platforms. Through Lightning Network, while you can do this for channel creators, they can’t control where the actual transactions are routed.

It is important to remember that the technology is still in its nascent stage. With subsequent improvements, and an increased number of nodes (therefore, channels), it might ensure that Bitcoin lives up to its creator’s vision as a peer-to-peer electronic form of money that can be used for everyday transactions.

Update 16:30 UTC, June 26: Lightning Labs co-founder and chief technology officer Olaoluwa Osuntokun has since downplayed the methodology used in Diar’s research.

“Based on what I can find with respect to methodology used to generate these metrics, […] the model itself is flawed, and produces flawed metrics,” he told Hard Fork over email.

Among other things, Osuntokun noted that the research failed to factor out Lightning Network channels that simply do not offer support for transactions larger than their specified amount. “When one takes into account how Lightning Network works, this is akin to saying ’the probability of room that fits 10 people will be able to fit 50 people is 0 [percent],’” he said.

(For the record, Diar and the Redditor who originally provided the data claim they did remove nodes with insufficient capacity from their samples.)

Another issue in Diar’s methodology is that it assumes the maximum transferrable amount is $490. Osuntokun has clarified that the maximum payment size on the Lightning Network currently stands at 4,294,967 satoshis – or about $260 at the time of writing.

“By not removing channels which have a total capacity that’s less than the target amount to be sent, the results of the model are greatly skewed, as they include nonsense data points,” Osuntokun added.

Update 08:40 UTC, July 2: In a response to the Lightning Network development team, Diar has since defended the legitimacy of its research. The full response can be found here.

Speaking to Hard Fork, Lightning Labs CEO and co-founder Elizabeth Stark expressed skepticism at the validity of Diar’s research model, referring to the data set as “flawed.”

In the interest of full disclosure, we’ve also decided to include Osuntokun’s full unedited response to Hard Fork from June 26:

Based on what I can find with respect to methodology used to generate these

metrics, and my knowledge of the underlying protocol (I’m one of the

co-authors of theLightningProtocol specification, the lead developer of

lnd, and the CTO+Co-Founder ofLightningLabs), IMO the model was created by

someone that at the time, didn’t understand exactly howLightningworks at a

low-level. As a result, the model itself is flawed, and produces flawed

metrics.

First, it’s important to understand that the LN is a flow-based debit

network in a sense. Flow based because payment cannot proceed on a path

unless the path has a sufficient amount of BTC to satisfy the payment, and

debit-based as each channel has a limit on the maximum amount of BTC it can

send/receive.

With this set up, we can now examine the flawed methodology of the payment.

It attempts to compute “the probability that any two random nodes on the

network can send a payment of size X BTC, given that they have at least 2*X

BTC in the channel”. The flaws with this methodology are as follows:

* It doesn’t remove channels that inherently have a capacity of less than

X BTC. For example, according to this model, “the probability of sending

50 BTC with a channel that has a 10 BTC capacity is 0%”. When one takes

into account how LN works, this is akin to saying “the probability of a

room that fits 10 people will be able to fit 50 people is 0%”.

By not removing channels which have a total capacity that’s less than

the target amount to be sent, the results of the model are greatly

skewed, as they include nonsense data points.

* Currently on the network, most nodes have very small channels. For

example, since many of the popular Lapps (Lighting Apps) are

micropayment based games or services, most users only open very small

channels. For example, satoshis.place pays for each pixel by the

satoshi. At the time of writing, 1 satoshi is $0.00006151, so even just

a channel of $2 can go a very long way!

As the distribution of channels are skewed on the smaller size atm,

failing to remove channels that have a capacity less than the target

payment size has a dramatic effect.

* It claims the probability to send $490 is zero. However, protocol

currently has a max payment size of 4,294,967 satoshis, which at the

time of writing is ~$264 dollars! Once again, by using an erroneous

model to generate metrics, the result is fundamentally incorrect.

* It includes nodes that have zero channels in the computation. Most

clients will continue to track nodes that no longer have any channels

within their view of the network. This further skews the metrics.

* It doesn’t factor in a technology we’ve created atLightningLabs called

Atomic Multi-Path Payments (AMP). Currently, on the network, each

payment can only utilize a single channel. As a result, if I have 5

channels that are $10 each, then I’m unable to make a payment of $50. I

can only make a payment of $5 since I can only utilize a single path.

AMP changes this, as it lets users utilize _all_ their active channels

when making payments. As a result, users will be able to make a wider

range of payment as they’ll be able to utilize the fully aggregate

payment liquidity of the network.

To illustrate how big of a deal this is, even many $2 channels on the

network would be able to be _partially_ utilized to create a say, $100

payment by my node. AMP also decrease the importance of very large

channels, which lessens concentration pressure on the network, as your

node doesn’t need to have a ton of money distributed in channels to be

useful to the network, and earn routing fees.

* As the network is still at an early stage, most users aren’t yet

distributing a large number of funds within the network.

* The question of “if a node can pay any other random node” may not

actually be pertinent when you consider the typical access pattern

of most consumer payments. Most people pay the same handful of

services/people each month in a predictable pattern. As a result,

within the network, most nodes will never even need to send a

payment to other nodes in the network, instead they’ll be sending

payments to the services/games/businesses they use the most. The

typical access pattern of payments _it not random_.

* “In a world of AMP, what’s a more relevant metric to track in order to

gauge the throughput of the network?”

The answer to this is to instead track the max-flow [0] from any one node

to another. It allows one to compute the largest flow possible in a

network from a single source to a single sink. As Lightning is a flow

network, this is a more pertinent metric. Applied to Lightning, when

factoring in AMP, this would answer: “what’s the largest aggregate payment

that one node can send to any other node”.