Bitcoin’s Lightning Network (LN) has seen a “16,856% increase in channels and a 4,084% increase in channel capacity in 6 months,” according to Blockstream, a bitcoin software company that develops one of LN’s implementation written in C.
“In January… the Lightning Network had a total of 46 open channels and 0.682 BTC in capacity. Today, there are roughly 7,800 open channels with 26 BTC of capacity,” they say.
What exactly they call channels and what exactly they call nodes is getting slightly confusing with the terminology changing constantly, but we take it to mean there are now 8,000 individuals or accounts in the Lightning Network and they can transact with each other a grand total of 26 btc, currently worth $160,000.
One Blockstream’s dev salary, all of LN’s capacity. That’s around three months after it launched on mainnet, with Blockstream saying today they launched the beta.
Meaning they are claiming this thing is now usable by ordinary people, but for some comparison bitcoin proper processed some $5 billion worth of bitcoins in the past 24 hours, moving around the globe nearly one million btc.
Moreover, it appears the more users are added, the lower LN’s capacity if we take only these two provided stats as data points.
That being, if our maths is correct and we average it out, in January each user could transact 0.01 btc, now the far more numerous users can transact only 0.003 btc each. That’s about twenty dollars.
It would, however, be unfair to extrapolate from current stats because LN was, and in many ways still is, in the ‘expect bugs’ faze. So people may have intentionally parked very small amounts there, but there is a fundamental capacity problem with LN.
The way LN works in a very basic form is quite similar to an IoU system coupled with a six degrees of connections set-up.
Money here doesn’t actually move for days, weeks, months, or even sometimes they mention years, and some go to say if ever.
So what you need to do first is to show you have whatever amount of bitcoin you want to pay. You often can’t pay directly, so the intermediary channel also needs to have whatever amount you want to pay.
All of this is calculated through the code and secured to some extent by bitcoin’s blockchain, so there isn’t a way to cheat here, and because of that you have this inefficiency of both A and B needing say 10 btc if A wants to pay C.
So if the Lightning Network was to ever reach one million bitcoins in capacity, at least one million bitcoins would have to be frozen for that sole purpose in a simple set up where A pays C.
In the current set-up, A might have to go through D, F, perhaps even G, before finding a way to pay H. All of those letters would need to have the illustrative sum of 10 btc to do so.
A good way to see this, therefore, is a swinging ball pendulum where A’s 10 btc is sort of currented through all the other balls to end with the final person receiving the sum, eventually once it is settled on the blockchain, with that current passed through only if all the balls have in possession the amount that needs to be paid.
One of the fundamental problems with LN is that each of those balls can double spend a previous transaction if the other is not watching.
They can do so because there is no validation method here, there is no history, except for the present.
That is, the ledger has some of the recent entires, and then it shows dot, dot, dot. So if you go offline, all those balls can try to send a previous payment and in effect cancel you out.
If you are online, you might have reason to be happy if they do so because now you might take some of their money as the code punishes them if you alert the code, but if you are at a wedding then your $20 or 10 btc as it may be might have gone.
That’s why watchtower services are now springing up to keep an eye for you in return for a fee and arguably in return for you having to trust them.
All those balls also want a fee to current the payment. Then you have the on-chain fees to join the LN network which if people actually use LN would rise to about $1,000 or $10,000 per transaction if the laws of supply and demand follow some dev’s imagination rather than reality.
Moreover, from the end-user’s perspective, you are not quite receiving a payment, but raising an invoice as far as the Graphical User Interface (GUI) input experience is concerned.
So you need to enter how much the payer has to pay you, you need to decide how much time he has to pay you, then you need to give the invoice you created to the payer.
Once that is done, you need to cross your fingers and hope all those balls manage to find you through the LN routing paths, and if they do of course don’t forget to pay the watchtower.
It is all very simple, if we ignore all the complexities, and it scales to trillions of transactions a second, if we ignore all the capacity limitations, and it is completely secure, if we ignore the double spending vectors, and fully decentralized, if we ignore all the obvious centralizing factors.
Other than that, it has its use cases in micro-payments, or in payments where you often transact with another party, but in truth, an LN like protocol has never been tried before, so no one can say whether reality will show it has any use case.
It may well do, and all of it might even work for general payments, just as it may be completely useless save for some edge case efficiency gains. Time alone, as it often does in these things, will say.