 The first question was from an anonymous patron. How confident are you that Lightning Networks will bring the desired scalability and security to the network? Thanks. I am very confident. I am not only confident that we will be able to achieve tremendous scaling with Lightning Networks, but I think we will also be able to achieve that in a scale-free manner. We will also get much better security and privacy. What do I mean by that? I think we will see Lightning Networks operating either before the end of the year or very shortly after the beginning of 2018. I have already been running beta test software from both the L&D variety, which is the Lightning Network daemon, made by the Lightning Network company. But there are a number of implementations. Most people misunderstand that they think Lightning Network is a company. There is a company called Lightning Network. Just like there is a company called Blockchain, but that doesn't mean that's the company that makes the blockchain. It doesn't mean that's the company that makes the Lightning Network. There is one implementation by the Lightning Network company. That is the company that started all of this. The specification for the protocol is open source. Not only is it open source, but about a year ago, the various different groups, companies and open source projects involved in Lightning, got together. They built a set of common inter-parability standards. These standards are called BOLT. BOLT is the basics of Lightning technology. All of these puns you can make about weather, clouds, lightning strikes, thunder, and all of that. People are really milking that metaphor. BOLT is a set of standards. These define how the various implementations would inter-operate. I believe there are 12 BOLT documents. You can find them on GitHub. They are part of an RFC. They are basically the inter-parability standard. The six different teams that are working on implementations of the Lightning Network, including the Lightning Network company, Blockstream, C Lightning, Async, Eclair, and French company. Those three are most prominently involved in the inter-operability testing. There are three more companies that are working on implementations in a variety of different languages. These are completely independent teams working on all open source projects, all of them are open source, and all working on the same inter-operable standard. For the last month or so, I have watched the three companies that have the most advanced implementation so far, which are very close to production capability, have been doing inter-operability testing. Last week, all three companies were able to pass all 75 tests of compatibility, meaning that using any one of the three different implementations would allow you to work as part of the Lightning Network. It doesn't matter what client you have, just like it doesn't matter what Bitcoin wallet you have to use, it doesn't matter what client you have to use, Lightning Network, as long as it's inter-operable. It will be able to open payment channels to any of the other clients, be able to route payments across multiple channels, and do so with a very high degree of privacy. They are all implementing the onion routing protocol. What onion routing means is that each node only sees the immediate hop before it, and the immediate hop after it. The reason it's called onion routing is because the routing information is wrapped in layers. You receive an encrypted package from the node immediately previously to you, and you don't know where this is going, and the node before you doesn't know where it's going. You unwrap it, and you find routing information inside which tells you where to go for the next hop, but you don't know anything more than that. Then you send it to that next hop. They open it, and they find routing information to send it to the next hop. Every node in this route doesn't know how many hops have passed, and it doesn't know how many hops are yet to come. In fact, the routes are always the same length, so you can't tell if you're the first or the 20th in a 20-hop network. Paths can be up to 20 hops long, and they always look 20 hops. If the route information for less than 20 hops is padded with garbage that's encrypted, you don't know it's garbage, but you just pass it on thinking it's routing information for the next node, until one of the nodes opens up the package and finds out it's actually the destination of that route. The other 19 directions that follow are garbage, and it discards them, but only that node knows it's the last one in the hop. Only the sender and the recipient know how long the route is. Only the sender and the recipient know which position they are in the route, and everybody in between is just passing this encrypted bundle of information. This is a very high-security protocol. It's the same protocol that's used in Tor. If you've heard of Tor, Tor stands for the onion router, and it does this form of routing called onion routing. The initial implementation of Lightning Network will use onion routing for very high-degree privacy. One of the questions that remains is, will Lightning itself become centralized? Are there particular incentives to run a hub, to run a node that's connected with lots of payment channels, lots of other nodes, and that gets used for a lot of the routes? Is it possible that people with a lot of money, for example, exchanges, would set up Lightning nodes that are essentially the main participants in the Lightning Network? Can you end up with this hub-and-spoke system where there's a lot of concentration and centralization? I think it's unlikely that will happen, and there are a number of reasons. First of all, if you're running a Lightning node and you set up payment channels, in order for you to effectively route and make payments, you have to have the keys online on that system. The more funds you put into those payment channels, the higher the risk that your node is a target for hacking. There's a disadvantage to having a node with a lot of funds. If you open lots of payment channels to do a lot of routing, you have to put quite a lot of funds in those channels. If instead each node opens four or five different routes, they all end up creating this fairly tight mesh, where it's very peer-to-peer, and there's not much centralization. That's actually the best model for this, and that's what's called a scale-free network, which means that it looks the same at any scale. As a result, a network like that doesn't have the tendency to centralization. There are good reasons why centralization is discouraged. One of the really interesting things is that the Lightning network, as is already with the current Bolt specification, is implementing various techniques to rebalance channels. If you continuously send on one channel, all of the funds will end up on the far end of the channel. In order to rebalance it, you need to route payments in the opposite direction. They do that automatically. I've looked at the Lightning network daemon, and one of the things I also like quite a lot, is that they have a mechanism for automatically managing channels. You don't have to think about your node, which could be running on your smartphone. You can run a full Lightning network node on your smartphone, laptop, or desktop computer. You don't need to worry about what channels it needs to open. It basically manages channels on its own. It opens channels to parties that it thinks will give you good connectivity to the network. The same way that your Bitcoin node makes connections to eight other nodes in order to maintain good connectivity. The advantage of that is that it is designed to automatically manage channels, so as to create this not centralized environment.