 Have you seen the video on how banks bought BTC? It says that the Lightning Network will centralize Bitcoin, so that a few players have the power. I have seen that video, and I'm not going to do a point-by-point rebuttal of that particular video. I think it contains a number of misstatements. It makes some incorrect assumptions, then from those draws, very broad conclusions that are not really supported by the evidence. It is predicting a level of centralization in the Lightning Network or any second-layer technology. I think there are a couple of things to say about that. First of all, that is assuming that Bitcoin itself isn't centralized already. In fact, what we know is that in some areas of Bitcoin, there is already centralization. In the absence of second-layer technologies, there are two ways to resolve the increase in demand and limited capacity. One is to increase the block size, or increase the base block size, if you like. What that does is it pushes the costs of scale onto those who operate nodes, and will lead to centralization of mining and centralization of node ownership, at least in my opinion, and the opinion of many others. The other way is to push transactions off-chain, but not into a second-layer that continues the security model and trustless nature of Bitcoin, but simply to push it into private databases. We have seen that happen in Bitcoin as well. The vast majority of transactions happen offline and off-chain within the databases of large exchanges, large merchant providers. This isn't a choice between on-chain and off-chain, it is a choice between off-chain private and off-chain second-layer trustless environments. I think that is important to realize, because centralization occurs at different points of the system. It is not a matter of having a completely decentralized versus a completely centralized system. Different aspects of the system may have different degrees of centralization. Furthermore, I think Lightning Network is quite broadly misunderstood. One of the fundamental misunderstandings is that Lightning Network is simply payment channels, and that is not true. A lot of people think that in order to operate a Lightning Network payment, you have to have a payment channel... to, let's say, the coffee shop where you want to buy a cup of coffee. If that is the way Lightning Network worked, it wouldn't be very effective. If you had to open a payment channel every time you wanted to make a payment, then the cost of the funding and settlement transaction would be huge. The second misunderstanding is that in order for the merchant to be paid or the recipient to be paid, they have to close the channel. Settlement has to happen on the chain. In fact, that is not true either. Within a Lightning Network, first of all, all payments are routed. That means that it is not just payment channels. It is payment channels connected to each other. If I want to visit a website on the internet, I don't need to open a VPN to that web provider. I can have a connection with someone else on the internet, and they will route my packets to the website, as long as there is a path that reaches from my computer to the computer of the provider. Of course, that network has some degree of centralization. With Lightning Network, if you have the ability to create a path from your node to the person you want to pay, then you can route a payment over that path. Once you open a channel, you don't have to open a channel to the person you want to pay. You can open a number of channels. In fact, I think the best approach to do that is to let the client do it for you. If you are running a Lightning Network node, for example, from Lightning Labs, which is one of the implementations, if you are running LND, which is the Lightning Network daemon from Lightning Labs, it has a system called Autopilot. Autopilot will open channels for you so that you don't know how it is doing it in the background. It simply opens channels with as many people as it needs to be well connected, so it can find routes. It also closes channels when it needs to, when the other party doesn't respond. Finally, once you have opened the channel and you can route payments, you don't have to close those channels in order to use the funds that you receive. You can use them to make payments again over the Lightning Network. You don't have to cash out. You can keep your funds within the Lightning Network. You can also refill channels through a number of different technology options. One of those is essentially to route a payment to yourself in the inverse direction of the channel you used previously, so as to shift the balance back towards you. There are a number of other tricks, and most of these things will be done by the wallets, not manually. I think there are a lot of misunderstandings about how a Lightning Network works. Some people have taken those misunderstandings with some very glitzy graphics and high production values, have created this impression that Lightning Network is inherently something that will centralize into a hub and spoke topology. I don't think that's true. Of course, we won't know until we run it, and we're already seeing a number of people running Lightning nodes on mainnet. This experiment has just started. I am very hopeful for the future. I think it's going to be a great addition to the technologies that we use in this ecosystem. Of course, if you don't want to do that, and instead you want to use on-chain scaling to do all of your transactions, there are alternatives. There are a number of alternative chains out there, including Bitcoin Cash and Litecoin, Ethereum, Monero, Dash, and many others that you can use to do your transactions. I simply think that we will do better with Lightning on Bitcoin. How do routes across Lightning Network payment channels form? How does a node find an optimal path? If each channel needs funding to stay up, won't that lock a lot of value? Let's take the first two parts of that question first, which is a really interesting question. There are two really important models for routing that we see. One model is where the intermediate hops at each point are designed in which direction to transmit the packet they've just received. This is the model that's used on the internet. One funny way of describing it is called a hot potato, where someone hands you a hot potato and you hold it in your hands. You want to get rid of it as quickly as possible, because it's hot, and so you pass it along to the nearest person who has their hands out. The model of internet routing is a bit more sophisticated than that, of course, but the routing decisions are made by the intermediary routing nodes. Because each of those intermediary routing nodes knows the source and destination, and using the destination information... decides how to get closer to that destination in the next hop, and applies that. That's not how Lightning Network works. In fact, even on the internet, there used to be a model where you could do what is known as source routing. Where the originator of an IP packet could define a priori, the intermediary hops that the packet should go through, and they wouldn't make any routing decisions, they'd simply pass it to the next IP address listed there. Which means that the originator decides in advance what route the packet should follow, that's called source routing, and transmits it, and then the intermediary nodes simply follow that information. That's how Lightning Network works, at least now. There can be a number of different routing implementations. The routing implementations are completely independent of the underlying network, so you can have different routing strategies being implemented. But the one we see now in the beta-tested, testnet version of Lightning today, is a form of source routing... that uses encrypted layers called onion routing, so it's a source-based, onion-routed network. What that means is that the node that starts a payment receives information about all of the available channels out there, and the capacity that each channel has, and the fee that each channel charges. Based on that information, it constructs an optimal path. The optimal path may be the path that will result in the lowest amount of fees, for example. Once it's constructed a path, and it won't just construct one, it will construct several, because the first path may fail. Once it's constructed a path, it encrypts each hop in the path and embeds it such that it wraps the routing information in layers like an onion. It takes the final destination and the final hop and encrypts it to the public key of the node before the final hop. Then it takes that information and encrypts it to the public key of the node before that, and then works backwards, wrapping encryption around, until eventually it's called this onion, essentially, of routing information, which is the path. The outer layer is encrypted only to the first node it needs to reach, and then it transmits it to that first node. That first node can only read the outer layer. What it does is it knows where to send it next, one hop next. It unwraps it, sends it to that next node. That next node can only read where it needs to send it next, and it can't see where it came from. It can only see that it came from the immediately previous node, and it can only see that it's going to the immediately next node. It doesn't know how long the path is, and it doesn't know which position it has in the path, which makes it very difficult to reconstruct the path. To summarize, the source decides how to route it. Then the source constructs this path based on information it has about payment channels that are possible routing candidates. Once it's constructed a viable path, it wraps each element of that path in an encrypted packet, creating a layered onion of routing information, so that each node can only read one hop ahead and doesn't know where it's going and doesn't know where it came from. Then it transmits that, which starts unwrapping the route layer by layer until it arrives at the destination. The destination node is the only one that realizes that it is the destination node, and the origin node is the only one that knows that it didn't receive this from someone else. Every node in between doesn't know anything. The second question that Mitt asked, let me repeat that and start again. If each Lightning network channel needs funding to stay up, won't that lock a lot of value? This is an insightful question. In order to use Lightning network, you have to have enough value in the channel to transmit the payment you want. In fact, you have to have that value on your end of the channel, as capacity to send. That's why you would normally open two or three channels to other nodes that give you a number of paths into the Lightning network, and you would fund those with amounts that are enough to do the kinds of payments that you want to do. If you wanted to route something that is greater than the amount you have in your channels, you would have to open a new channel, or you would have to fund one of your existing channels with more money. There are a couple of ways to do that. For example, one way to do that would be to buy some Bitcoin, and instead of having the seller send it to you to a Bitcoin address, you could have them send it to your Lightning network address, which would then fill up your channel on your end, and increase its value to then allow you to make a bigger payment. Yes, of course, you can't spend what you don't have, and that means you will have to lock value into the channels. Ironically, this is exactly what prevents centralization of hubs, if you like, because if you try to create a Lightning network node that connects through many channels to many other nodes, and has a lot of value available to route, then that means you are holding a lot of Bitcoin value in those channels. Those channels are hot wallets, which means that the possibility of someone hacking your node and causing it to transmit all of that value away is quite high. You become a target, and so that's a disincentive to running very highly funded centralized nodes. It's much better to have more channels to more nodes and to have a mesh network. A few articles have popped up about AML regulation and how it might be applied to Lightning nodes. Our node operator is likely to face a lot of risk and why. That's very difficult to answer at this point, because in many cases it's very difficult to see how these regulations would be applied to individuals running software on their home computers. It's difficult to see how you would even find these individuals. In most cases, Lightning network is intended to be used for smaller amounts of money, so each of the payment channels would probably not have a very large balance. In many cases, anti-money laundering regulations apply to flows greater than a certain amount. How this law would be applied would be applied to people who are not banks and are not money service bureaus. Characterizing them all as banks is preposterous. Attempting to prosecute everybody who is running a Lightning node would be preposterous. It would only lead to more stealthy implementations that simply hide better, so you can't tell that somebody is running a Lightning network node. A lot of this stuff came up initially when people said, if I'm running a Bitcoin node and I'm propagating other people's transactions, doesn't that make me a money transmitter? There was a lot of concern about people being prosecuted for running Bitcoin nodes. None of that came to fruition. None of that actually happens. Not in any liberal democracy, or in fact only in a very few examples. We've seen very few examples, and most of those were focused on banning miners, even in Venezuela. It's probably illegal to run a Bitcoin node in North Korea, but then again, what isn't? So, are node operators likely to face a lot of risk? I don't think so, not really, but I'm not a lawyer. I can't advise you. I think any country that tries to apply AML regulation to Lightning nodes will simply end up pushing those nodes... outside of the country, where they'll have even less visibility and control. It won't change the operation of the network. The internet is open. We can route to a Lightning network node, no matter where it is. It can facilitate routing of a payment, no matter where it is. In most cases, you don't need to know where it is. That will only make Lightning network stealthier and unlikely to be an effective regulation. Please explain how using a Lightning-enabled wallet will be like. There's a lot of confusion about channels and the need to open and close them. I remember a time when I was using the internet where DNS didn't exist. There was a lot of confusion about what IP addresses had interesting services. I remember memorizing the IP address of the main FTP server at Berkeley, because that's where they stored the Berkeley software distribution, the first open-source stuff. If you wanted to download BSD, you had to figure out someone who knew the FTP server... because there were no DNS names to find it. That was a very difficult to use internet that nobody would use today. The early iterations of the Lightning network are like that. They bring a lot of the engineering details to the surface. You, as a user, see all of the gnarly bits that should be hidden behind the user interface. In my opinion, a Lightning-enabled wallet looks exactly the same as a multi-currency wallet, preferably something like Jack's, which is one that I like. It has multiple currencies, and you can send and receive in multiple currencies. If you want to send, you scan a QR code, and then you hit send, and it sends it. If you want to receive, you hit the receive button. It shows you a QR code that somebody can scan, or you can copy it to a clipboard and send it. That's how a Lightning wallet should work. You should have two buttons, send and receive. If you want to send and you scan, it should tell, on its own, if what you're scanning is a Bitcoin address, or a Lightning network channel endpoint, and if it's a public key from a Lightning network, you should route the payment over the Lightning network. If what you scanned is a Bitcoin address, it should either use an on-chain transaction, because it also has an on-chain wallet capability, or use a gateway that converts a Lightning network payment to an on-chain Bitcoin payment. Therefore, you can't tell the difference. You can't tell when you're making a Lightning network or a Bitcoin on-chain payment. It will look exactly the same. You won't need to open and close channels. Any more than you need to configure the routing table of your Wi-Fi router, or the VPN connectivity of your home computer, it knows how to route IP, and it does it for you, and it does it invisibly in the background. You don't tell your BitTorrent client how many other computers to connect to. You don't tell your TCP IP stack where to route packets. That should be an implementation detail. It should be hidden by good engineering. The interface should be as simple to use as any Bitcoin wallet today. Scan, send. Project a QR code, have someone else scan it, and they can send to you. Simple as that. I'm interested in running a Lightning node. Where is the best place to start? I found the best place to start would be the LND, Lightning Labs Implementation, Lightning Network Demon. That's not the only one. You can also use C Lightning, which is C-Lightning, which is an implementation by Blockstream's team. Or you can use Eclair from Async, which is a third implementation. All three of those implementations are what's called Bolt-compliant. Bolt stands for Basics of Lightning Technology, which is what in the industry we call a Bacronym, where you figure out what kind of fancy words you want to use, and then you figure out what words would make that work as an acronym. The nice thing about Bolt is that that makes sure that all three implementations that are Bolt-compliant can work with each other. They can open channels to each other. They communicate on the network. They create one unified multi-implementation Lightning network. I've used LND. I haven't used the other two implementations yet, but I will be playing around with those two over time. You can find those at lightning.network and lightning.engineering. There's also a GitHub repository. There's a few interesting medium articles that tell you how to run a Lightning node on mainnet, which is the mainnetwork, or on testnet, if you want to run it on testnet.