 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 implement according to this specification. The specification is called the basis of lightning technology or BALT, which is a nice play back her name as it's called. So BALT is how the Lightning Network is specified, then there's a number of BALTs 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 advantages you have on the Lightning Network is because you don't have to march in 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 of the standard or specification and move a bit faster than the standard implementation. That means that development and lightning happens a lot faster. 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 clues that occur from the very first specification. So we're currently operating on the first iteration of the BALT standard and that BALT 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. Now you will notice there are a couple of things that are difficult to do in Lightning. Here's one example in which way lightning differs from 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 payment 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 but 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 are 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 routability. These are the kinds of problems that Lightning developers are working on. None of these problems are unsolvable. In fact, there are many different solutions that are being proposed and it's about different tradeoffs 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 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. If you enjoyed this video, please subscribe, like and share. All my work is shared for free, so if you want to support it, join me on Patreon.