Development challenges for the Lighting Network

- Are there any limitations that the developers are currently working on? Keep in mind that the Lightning Network is not a company, it's a protocol specification and it's implemented by many, many different companies and open source projects that implements according to the specification.

What is BOLT (Basis of Lightning Technology)

The specification is called the Basis of Lightning Technology or BOLT, which is a nice play backronym as it's called. So BOLT is how the Lightening Network is specified then there's a number of BOLTs that specify how different parts work, so that everyone can write an implementation, and then test it for interoperability against other clients, and ensure that they can interoperate on this network. Now interestingly enough, one of the advantage that you have on the Lightning Network is because you don't have to march and lockstep to consensus rules, you only care about ensuring that the consensus rules of the Bitcoin network support the security of what you're doing, you can implement various features independently, all of the standard or specification and move a bit faster than the standard implementation. That means the developments in Lightning happens a lot faster.

Cool new Lightning features are being built

There are a number of different companies and projects that are implementing all kinds of interesting features, many of them intended to address the shortcomings, difficulties, user interface kludges that occur from the very first specification. So we're currently operating on the first iteration of the BOLT standard and that BOLT standard is advancing gradually as new things are agreed and added to the standard at meetings that happen until now physically but obviously now virtually around the world between the various teams and developers working on this meetings that anyone can participate in and watch or read the transcript afterwards, and this is where the standards are defined.

Lightning Network challenges

Now you will notice there're couple of things that are difficult to do in Lightning. Here's one example in which way Lightning differs from a Bitcoin transactions. In order to send someone a Lightning payment, they must first give you an invoice. And this has to do with the fact that today's routing mechanism works on the basis of the hash of a secret that has to be back propagated across the network in order to ensure that everybody is satisfied with the payments and it happens trustlessly. So that means there has to be an invoice which means you can't just send money to someone without first coordinating with them and getting an invoice for the specific amount that you want to send them. The second issue is that nodes on the Lightning Network have to be online and they have to be online for two reasons, one is to ensure that, the counterpart in their payment channel, doesn't try to cheat by broadcasting an old commitment state, which is a complex issue that can be resolved in a number of different ways, but for now it's simpler to simply have these Lightning nodes online monitoring the payment channel transaction and ensuring that no one's trying to cheat. And then finally, there're a number of issues in the routing area whereby it is sometimes both difficult to establish a route because the sender of a transaction has to construct that route and therefore needs a view of the connectivity of the entire network to do which means a big database of who's connected to who, and this has implications both for privacy, as well as routeability. These are the kinds of problems that Lightning developers are working on.

Solutions and trade-offs for Lightning Network development

None of these problems are unsolvable, in fact, there are many different solutions that are being proposed, and it's about different trade-offs in terms of privacy and speed, reliability and resilience of the network, robust connectivity and all of these other issues. There are a number of proposals to solve these, you'll hear terms such as a Trampoline Routing, Rendezvous Routing, you'll hear terms such as Huddle Invoices and Turbo Channels, and these are all various ways of overcoming some of the limitations that the first iteration of the lightning specification has, and moving the network forward to make it easier to use, easier to understand, more predictable in its behavior for end users, less complex in its behavior for end users, and to hide some of that complexity by using various protocols and protocol improvements. (ambient music) If you enjoyed this video, please subscribe, like and share. All my work is shared for free, so if you wanna support it, join me on Patreon. (ambient music)