The Lightning Network for Dummies: Part 1
Routing and Capital Lock-Ups
In the past few months, we’ve seen a huge surge in interest around the Lightning Network with releases and community lead initiatives such as the Lightning Torch as well as a remarkable level of evangelism by a number of notable individuals — one favorite amongst the community is Square and Twitter CEO, Jack Dorsey.
Naturally, this rise in popularity has coincided with a number of concerns regarding the network’s viability and the audience it is ultimately intended to serve. In this article and subsequent, I will be addressing some of these concerns, so we can all more aptly understand Lightning’s current limitations and vectors for improvement.
The complexity of the Lightning Network is so vast, given all the BOLT specifications, as they’re planning to solve some of Lightning’s hardest economic/technical problems with very clever, advanced cryptography. We think it’s important that everyone has a common understanding of the inter-workings so we can ensure the esoterica doesn’t lead to false or misleading media headlines.
Routing Problems? Not Quite
The Lightning Network uses onion-style routing whereby payment information is encrypted in a nested fashion so that intermediary nodes along the route only know who they received the payment from and who to send it to next. This allows for the network to have a higher degree of privacy in the facilitation of its payments (provided that intermediaries don’t compare records).
For those not familiar with this sort of routing, take the instance, here, where A wishes to send a payment to E.
Because A has to define the route between it and E, it needs to keep an updated view of the entire network and there is no evidence this can be done at scale. Now, you might be thinking to yourself — why does A need an entire view of the entire network, shouldn’t it just need to know one or more routes between it and E? Well, you’re right, it doesn’t need to maintain a view of the entire network — although, this is one of the common concerns raised by critics of the Lightning Network. So, we want to ensure we make this clear, right here. Nodes do not need to maintain an updated view of the entire network, they only need to know how to route payments to counter-parties of interest to them. The way in which this local view is created is up to participants (Ex: Alex Bosworth’s implementation), who are able to leverage all advertised channel information to do so.
Note: For those who would like to know more about this system, please reference BOLT #7: P2P Node and Channel Discovery.
Moving on… if A has identified a route between it an E (routing information in the Lightning Network for public channels is public domain and easily accessible), it must then determine if there is enough capital available in the route to make the payment. Below, I have updated the previous diagram with the amount of capital available for lockup by each of the members of the channel.
Note: It should be noted that this is an inaccurate representation of capital lockup in the Lightning Network (lockup is done between parties on channels, not by each party individually). This explanation is merely used to get the point across of capital availability in the network for individual nodes and their capacity.
So, A wishes to send a 1 BTC payment to E and cannot find a route which can fully collateralize this payment. Does anyone see what is wrong, here? The Lightning Network is intended for small payments, 1 BTC is well beyond that and should really just be sent over the Bitcoin blockchain. So, let’s try again with a few more decimal points.
So, let’s say that A wishes to send .0005 BTC (~$2) to E, but there is still not enough available capital in the known routes to send this transaction given that most of each intermediary’s capital is currently locked routing other payments. Well, given that intermediaries in the Lightning Network take fees, it’s likely that someone would capitalize on this deficiency in the network and fill this gap.
Capital Lock-ups
Another concern regarding Lightning is this idea that capital will be locked up for days in channels to facilitate payments — this is simply untrue. Most time-locks in the Lightning Network can be greatly decreased to a matter of seconds given that most of the protocol can be automated through clever engineering of clients which can quickly facilitate the payment protocol and monitor all open channels.
And what’s to stop A from making multiple payments to E? A could very well send a payment of .0002 BTC along the H->I->J->E route while simultaneously sending a .0003 BTC payment along the K->L->E route or send multiple .0001 BTC payments along the B->C->D->E route. I point this out because many critics ignore the ability to packetize payments with things like AMP to facilitate larger transactions on the Lightning Network.
So, if A does decide to do this, it would create a routable payment that was encrypted such that only K could decrypt it to see that they needed to send it to L who could then decrypt to see that they needed to send it to E who could then decrypt it and get the plaintext payment. And in this way, we are able to send payments in a semi-private manner as intermediaries only know who they get the payment from and who it is going to. This is only semi-private, though, given that intermediaries could compare information to gather the full route of the payment.
I’d like to show you a picture of the Lightning Network from a few months ago to illustrate a few additional points, here.
As anyone can clearly see, Lightning (like any decentralized network) is developing its own set of supernodes / hubs — something that my example didn’t even account for. This means that new participants of the network will be provided with the optionality of connecting to only those whom they care about or connecting to a supernode and having access to a much larger group with only a single hop. This greatly diminishes the memory overhead that nodes will have to maintain for route in the network and also allows for much shorts routes in the network through more reliable channels.
Now, sending payments through a single hop can completely undermine any privacy for payments, but it’s a tradeoff that users are free to make for themselves. And that’s one of the great things about this project — users are free to take as much or as little risk that they please with the capital they put up as well as the payments that they elect to facilitate.
Going Forward
I look forward to the continued expansion and development of the Lightning Network. I’m quite sure there will be additional concerns raised as the network continues gaining popularity, but people should bear in mind that most of these are not innate to the network and can be resolved with clever engineering.
We hope these primers serve as a means overtime to debunking the technical misunderstandings of Lightning to ensure that myths don’t proliferate; don’t just trust, verify.
Table of Contents
Thank you to Steven McKie (Editor) and Olaoluwa Osuntokun for your contributions and feedback to this article!
