Bitcoin Q&A: Misconceptions about Lightning Network:

Bitcoin Q&A: Misconceptions about Lightning Network - Andreas Antonopoluous
https://www.youtube.com/watch?v=c4TjfaLgzj4
Transcription by CannyCassiopeia

Have you seen the video 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 and it's predicting a level of centralization in Lightning Network or any second layer of technology.
 I think there's a couple of things to say about that, first of all that's assuming that Bitcoin itself isn't centralized already and in fact what we know is that in some areas of the coin, there is already centralization in the absence of second layer technologies.
There are two ways to resolve the increase in demand and limit its capacity: One is to increase the block size or increase the base block size if you like and what that does is it pushes the costs of scale on to those who operates 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 and we've seen that happen as well in Bitcoin.
The vast majority of transactions happen offline and off chain within the databases of large exchanges and large merchant providers. So this isn't a choice between on chain and off chain, it's a choice between off chain private and off chain second layer trustless environment so I think that's important to realize because centralization occurs at different points of the system. It's 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's not true so a lot of people think that in order to operate a Lightning Network payments, you have to have a payment channel to let's say the coffee shop where you want to buy a cup of coffee and if that's the way Lightning Network worked it wouldn't be very effective because if you had to open a payment channel every time you wanted to make a payment then the cost of the funding transaction and settlement transaction would be huge.
The second misunderstanding is that in order for the merchants to be paid or the recipients to be paid, they have to close the channel that settlement has to happen on the chain, in fact that's not true either. Within a Lightning Network, first of all, all payments are routed - that means that it's not just payment channels. It’s 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. And of course that network as well has some degree of centralization with Lightning Network. If you have the ability to create a path from your point from your node to the person you want to pay then you can route a payment over that path and once you open a channel, you don't have to open a channel to the purse you want to pay. You can open a number of channels and in fact I think the best approach to do that is to let the client do it for you.
So if you're running a Lightning Network node for example from Lightning Labs which is one of the implementations if you're running LnD which is the Lightning Network daemon from Lightning Labs, it has a system called autopilot and what auto pilots will do is open channels for you so that you don't know how it's doing it in the background - that simply opens channels with as many people as it needs to be well connected so it can find routes. And it also closes channels when it needs to, when the other party doesn't respond and finally, once you've opened the channel and you can route payments or you've opened several channels and you can round payments through them.
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 Networks. You don't have to cash out, you can keep your funds within the Lightning Network and 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.
And there are a number of other tricks and mostly these things will be done by the wallets not manually so I think there are a lot of misunderstandings about how Lightning Network works and some people have taken those misunderstandings and 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.
Apologies, 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 lightening nodes on main net so 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 and 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, Litecoin, Ethereum and Monero. 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 want that lock? A lot of value. Let's take the first two parts of that question first, which is a really interesting question. There's two really important models for right routing that we see: One model is where the intermediate hops at each point decide in which direction to transmit the packet that they've just received so this is the model that's used on the Internet.
One funny way of describing it is this called a “hot potato” where someone hands you a hot potato and you hold it in your hands and then 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 priority. The intermediary hops that the package 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 package 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 test net version of Lightning today is a form of source routing that uses encrypted layers called Onion Routing so it's a source based on your 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 and based on that information it constructs an optimal path and 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 and will construct several because the first path may fail but 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 and so it takes the final destination and the final hop and encrypts it to the public key of the nodes 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 and the outer layer is encrypted only to the first node that needs to reach and then it transmits it to that first node that first node can only read the outer layer and what it does is it knows where to send it next one hop next it unwraps it sends it to that next 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 and 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 so 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 elements 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 and 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 MIT 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? And this is a really interesting and insightful question because yes in order to use Lightning Network you have to have enough value in the channel to transmit the payments you want. In fact you have to have that value on your end of the channel as capacity to send and that's why you would normally open two or three four or five 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 now. If you wanted to route some that is greater than the amount you have in your channels, you'd have to open a new channel or you'd have to fund one of your existing channels with more money.
There's 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 – (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 - then allow you to make a bigger payment. So 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're holding a lot of Bitcoin value in those channels and 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 a very highly funded centralized node.
It's much better to have more channels, more nodes and to have a mesh network a few articles have pop-top 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 there's 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 and 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 and in many cases, in many places money laundering anti money laundering regulations apply to flows greater than a certain amount.
How this law would be applied should be applied to people who are not banks and enough money service bureaus characterizing them all as banks is preposterous. Attempting to prosecute everybody who's running a lightning node would be preposterous it would only lead to more stealthy implementations that simply hide better so that you can't tell that somebody is running a Lightning Network node.
You know a lot of this stuff came up initially when people said well if I'm running a Bitcoin node and I'm propagating other people's transactions doesn't that make me a money transmitter and 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 example we've seen very few examples and most of those were focused on banning minors. Even in Venezuela it's probably illegal to run a Bitcoin node in North Korea you know but then again what isn't so our node operators likely to face a lot of risk I don't think so not really but I'm not a lawyer so I can't advise you.
 I think any country that tries to apply a ML regulation to lightning nodes will simply end up pushing those nodes outside of the country where they'll have even less visibility and control and 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 and it can facilitates routing of a payment no matter where it is and in most cases you don't need to know where it is so that will only make climbing Network stealthier and is 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 need to open and close them.  I remember a time when I was using the Internet when 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 the first brillouin source stuff and 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 and that was a very difficult to use internet that nobody would use today, the early iterations of Lightning Network alike that they bring a lot of the engineering details to the surface and you as a user see all of the gnarly bits that should really be hidden behind the user interface.
In my opinion a lightning enabled wallets looks exactly the same as a multi currency wallet preferably something like Jack's. Let's say 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 codes and then you hit send in 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 and 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 to use a gateway that converts a lightning Network to unchain Bitcoin payments and therefore you can't tell the difference you can't tell when you're making a lightning network or Bitcoin on chain payments 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 clients 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 protect 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's the best place to start I found the best place to start would be the LND lightning labs implementation lightning Network daemon but that's not the only one you can also use C lightning which is C - lightning which is an implementation by block streams team or you can use Eclair from async which is third implementation all three of those implementations are what's called bolt compliance and vault are a set of interoperability standards both stands for basics of lightning technology which is what's in the industry we call a backronym where you figure out what kind of fancy word you want to use and then you figure out what words would make that work as an acronym.
So the nice thing about bolt is that that makes sure that all three implementations that are bolt compliance 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 iView LNT 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 dot Network and lightning dot engineering there's also a github repository and there's a few interesting medium articles that tell you how to run a lightening node on main net which is the main network or on test Nats if you want to run it on past that.