 Flores asks, will the Lightning Network really bring enough scaling? Is such a solution computationally better than a block-sized increase? Yes, and yes. The Lightning Network completely changes the scaling game. It changes it because now we can start talking about millions of transactions per second, which you can't even conceive of with a block-sized increase. The block-sized increase can push the can down the road, but you don't change the scaling by orders of magnitudes with block-sized increases. It's not possible to do order-of-magnitude block-sized increases without fundamentally destroying the decentralization principles of Bitcoin, at least not yet. Whereas with Lightning, by taking most of these transactions off-chain and yet retaining the exact same trust model and doing actual Bitcoin transactions with smart contracts, Lightning is Bitcoin. It's me exchanging signed Bitcoin transactions with another person without recording them on the blockchain, because we don't need to unless there's a dispute. We can do millions of those per second just between the two of us. Forget everybody else in the world. Yes, Lightning Network really does bring enough scaling. It allows us to change the dimensions of Bitcoin. It allows us to reduce the granularity of payments, not just down to millibits, but down to satoshis and even subsatoshi amounts, which has been demonstrated by the way. And do that on the scale of millisecond round trips, where basically creating and confirming transactions thousands of times per second. Anonymous asks, how dangerous would it be for the average user to run a Lightning network hub on a home PC or a smartphone? Okay, there is no such thing as a hub. Lightning Network is a collection of peers. If you only open one channel and you don't want to route payments, you should be using Lightning Network in a bi-directional fashion, where you're also routing payments. It gives you much more privacy. If you're only connected to a single other Lightning Network node, and it can see all of the transactions coming from you, and it knows you're not connected to anybody else, then it can tell you that the transactions are yours. If you're connected to somebody else, the transactions could be coming from any number of routes of which you are, you know, HUB 19. It's not possible for any of the nodes to know whether you're the originator or simply relaying. So everybody relaying everything is the model. And a mesh network, not a hub and spoke system, is the better and more secure model. And it's actually what the clients implement right now. They'll go out and automatically connect to lots of nodes to give you that kind of mesh connectivity. Is it dangerous for an average user to run that? I don't know. I don't know what you mean by dangerous. There is some security risk in that system will have keys on it, so it is a hot wallet. And if you're running that hot wallet with a lot of Bitcoin in it, then it's a target for attack, and someone can hack into your Lightning node, and can use it to make a payment over Lightning to drain your wallet. So there is a security risk. There may also be legal risks. I'm not a lawyer, so I can't really comment. Different countries, different jurisdictions, different states will have different requirements. I would assume that if you do run a Lightning network node, you should be running it over Tor. Again, I don't know. It depends on your jurisdiction, your country, or the state of the rule of law. Andre asks, do you think second-layer solutions to scaling make hard forks on the first layer exponentially hard to do? Hmm, that's a really interesting question. I hadn't really thought about that. Well, they do in some way, because if you have, for example, Bitcoin tied up in a multi-sig as part of a Lightning channel, and someone hard forks that off, being able to use the Bitcoin kitty-cats, which is the new fork, on that amount of money that's in the payment channel would require you to have support for Bitcoin kitty-cats. In the Lightning clients that you're using, so that it can move those with some kind of non-replayable... Yeah, second-layer does make it harder to do hard forks. It makes it harder for hard forks to be beneficial to those who hold. It makes it harder for the airdrop to be successful. Interesting concepts. I hadn't really thought about that. Thank you, Andre. Ron asks, is the Lightning network really viable? How surmountable are Lightning scaling challenges? Some smart Bcash supporters I follow on Twitter question the ability of Lightning nodes to maintain the state of channels, fees, and balances well enough for the network to function well. Thoughts? By the way, I'm not calling it Bcash. I'm just reading you the question as it was. Ron has been reading some postings from Bcash supporters who are criticising Lightning as unable to scale. One of the criticisms I've heard myself and seen in a number of videos and medium posts, etc., is the idea that routing on the Lightning network is not a solved problem. That's absolutely right. Routing is not a solved problem in Lightning network. In fact, Lightning is still under heavy development and is in the very early stages of development. Most of the clients are still in the beta category, their pre-production software. Even though you can run Lightning on mainnet, it's still not suitable for production use. There are bugs to iron out. What about Lightning routing? The bottom line is that routing is not part of the core specification of Lightning. That's deliberate. The reason for that is because the routing algorithm is independent of the construction of payment channels. Meaning that there are two broad considerations in Lightning. One is, how do you construct payment channels between two parties that do not require trust? Then, how do you transmit payments by connecting a number of payment channels together to create a path? That's one set of problems. That set of problems is at the moment specified by a series of standards called the Bolt Standards. In fact, there are three different types of Lightning network that are defined by three different standards. There's Bolt, which is the basics of Lightning technology, which is one set of standards around which there are a number of implementations. There's Lit, which is a slightly different implementation of payment channels and routing. And then there's Raiden, which you may have heard of, which is on the Ethereum network. Which is another implementation of the same concept with a different set of specifications. I'll talk about Bolt, which I think is what most people refer to today as the Lightning network. Bolt is the set of standards that allow interoperability between the three most common implementations. C Lightning, L&D, and Eclare. These three implementations are currently interoperating with a very big network that is growing rather rapidly on mainnet and testing out the basic concept. Routing at the moment on that network is done in a very simplistic fashion, and that's a mechanism called source routing. The interesting thing about the Lightning specification is that routing is not part of the Lightning specification. It can be handled separately. In fact, like many other Internet networks, which is what Lightning network is, or a network of networks, routing is something that happens at a separate layer of the protocol, and there can be multiple independent routing algorithms operating simultaneously. Now you may have heard of another Internet network that has routing as a separate layer, where many routing algorithms operate independently, and that's the Internet, of course. In the very early days of the Internet, the mechanism used for routing when the network was small and fairly static was a mechanism called source routing, where each host kept a broad map of what the network looked like and constructed a path for the packets by encapsulating that path within each packet. The source of a transmission on the TCP-IP network in the very early days incorporated information into the packet that said, send it to this node, then have that node send it to the next node, then have that node send it to the next node. That path was specified in advance. Now, Lightning network uses source routing for now, and the reason for that is because it's one of the simplest implementations you can have. There are some criticisms that source routing won't scale, and that's absolutely right. Source routing will not scale, but Lightning network isn't committed to using just source routing. There are a number of other routing algorithms that could be used, and in fact many could be used simultaneously on the network, to optimize for different things. Maybe a routing algorithm that optimizes for privacy, for fees, for the minimum amount of hops, or for large payments or small payments. Who knows? This is still an area of active research. There are two or three proposed routing implementations that use different structures within the network in order to introduce some level of hierarchical routing, where basically you have nodes that are aware of their immediate environment, meaning the nodes that are most closely connected to them, and then they aggregate that information and act as beacons that repeat it to adjacent neighborhoods. This organization of Lightning into neighborhoods with nodes repeating that information across neighborhoods is one proposed approach to routing. There will be dozens more, just like today on the internet. There are dozens of routing protocols operating for different levels of scale and different uses of the network. The routing that's used to route IP packets on backhaul fiber optic networks is different from the routing that's used within your office block to route packets within a switched environment, and that's how it should be. So when people say how surmountable are Lightning scaling challenges and is Lightning network viable and does the routing scale, that to me is a matter of engineering optimization, meaning that it is naive to say at this stage that because the routing that we have today doesn't scale to billions of nodes, that means that no routing can ever scale to billions of nodes, or without centralizing the network or creating a hub and spoke system or destroying privacy, etc. To say that it is not possible ever because it is not done today is to misunderstand how engineering works. And to me, I think this is an area of active research. The routing algorithm that exists today works for the Lightning network that exists today. And one of the key tenets of engineering is you don't optimize something before it's necessary to optimize something. Premature optimization is a bad engineering practice. There's no reason to introduce or waste resources trying to build a routing algorithm today that scales to millions of nodes when we have thousands of nodes, because there are other more interesting engineering problems to solve at this point. I would argue that issues of user interface design and ease of use for end users are far more important to solve at this stage of the Lightning network. And solving problems of routing at scale will happen when it needs to happen, and not yet. Is the Lightning network really viable? Yes, it is. It works today. And I think there is far, far more research and development than most people realize happening in this exciting space.