[QUESTION] “Have you seen the video ‘How the Banks
Bought Bitcoin’? It says the Lightning Network will… centralise Bitcoin so that a few players have the power.” I have seen that video. 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 centralisation in the
Lightning Network or any second layer technology. I think there’s a couple of things to say about that.
First of all, it’s assuming Bitcoin itself isn’t [somewhat]… centralised already. What we know is that in
some areas of Bitcoin, there is already centralisation. In the absence of second layer technologies, there are two ways to resolve the increase
in demand and limited capacity. 1. Increase the base block size. What that does is push
the costs of scale on to those who operate nodes. [This] will lead to centralisation of mining and
centralisation of node ownership, at least in my opinion and the opinion of many others. 2. Push transactions off-chain,
not into a second layer that continues… the security model and trustless nature of Bitcoin,
but simply to push it into private databases. We’ve seen that happen as well in Bitcoin.
The vast majority of transactions happen offline, off-chain, within the databases of large
exchanges and 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 [trustless] in a second layer environment. I think that’s important to realize, because centralisation
occurs at different points of the system. It’s not a matter of having a completely decentralised
versus a completely centralised system. Different aspects of the system may have different
degrees of centralisation. Furthermore, I think… the Lightning Network is quite broadly misunderstood. One of the fundamental misunderstandings is that
the Lightning Network is simply payment channels. That’s not true. A lot of people think that in order to operate a Lightning
Network payment, you [must] have a payment channel… to, [for example], the coffee shop
where you want to buy a cup of coffee. [But] if that was the only way the 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, 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 and [there
has to be immediate] settlement on-chain. In fact, that’s not true either.
First of all, all payments [can be] routed. That means [the Lightning Network] isn’t just payment
channels, it’s channels connected to each other. If I want to visit a web site 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. That network has some degree of centralisation.
With the 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 [with] the person you want to pay. You can open a number of channels. I think the best
approach [for doing that] is to let the client do it for you If you’re running a Lightning Network node,
for example [with the client made by] Lightning Labs, one of the implementations… the Lightning Network
daemon (LND) has a system called autopilot. Autopilot will open channels for you so you don’t need
[to manage it yourself]. It’s 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,
[such as] when the other party doesn’t respond. Finally, once you’ve opened the channel (or several
channels) and you can route 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 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,
to shift the balance back towards you. There are a number of other tricks. Mostly these things
will be done by the wallets, not manually. I think there are a lot of misunderstandings
about how the Lightning Network works. Some people [took] those misunderstandings and, with
some very glitzy graphics and high production values, have created this impression that the LN is inherently
[prone to] centralisation, a hub-and-spoke topology. I don’t think that’s true. Of course, we won’t know until
we run it. [But] we’ve already seen a number of people, [including myself], running Lightning nodes on mainnet.
This experiment has just started. I am very hopeful for the future. I think it [will] be a great
addition to the technologies we use in this ecosystem. [But] if you don’t want to do that and instead you want to
use [only] on-chain scaling to do all of your transactions, [you can] and there are alternatives.
There are a number of alternative chains out there, including Bitcoin Cash (BCH), Litecoin (LTC),
Ethereum (ETH), Monero (XMR), Dash, and many others, that you can use to do your transactions. I simply think
that we will do better with Lightning on Bitcoin. [QUESTION] “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’s two really important
models for routing that we see. One model is where intermediate hops at each point… decide [what] direction to transmit
the packet they’ve just received. This is the model [which] is used on the internet.
One funny way of describing this is called a “hot potato,” where someone hands you a hot potato,
you hold it in your hands and want to get rid of it… as quickly as possible because it’s hot, so you pass it
along to the nearest person [with] their hands out. The model of internet routing is a bit more sophisticated
than that, of course. Routing decisions are made by… [each] intermediate routing node, because
[they] know the source and destination information. Using the destination information, it decides how
to get closer to that destination in the next hop. That’s not how the Lightning Network works. Even on the
internet, there used to be a model where you could do… what is known as source routing, where the source
of the IP packet could define a priori (e.g. in advance) the intermediate hops that the package should go
through. The intermediate hops wouldn’t make any… routing decisions, they’d simply pass it to the next IP address listed there. The originator decides in advance… what route the package should follow.
That’s called source routing. [They would transmit] it and then the
intermediary nodes simply follow that information. That’s how the Lightning Network works, at least now. There can be a number
of different routing implementations. The routing implementations are completely
independent from the underlying network, so you can… have different routing strategies being implemented. 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.
It’s a source-based, onion-routed network. The node that starts a payment receives information
about all of the available channels out there, [such as] the capacity that each channel has
and the fee each channel charges. Based on that information,
it constructs an optimal path. The optimal path may be [one which] will result
in the lowest amount of fees, for example. Once it has constructed a path (and it [will
construct several] because the first path may fail), 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, 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 has this “onion” of routing information. The outer layer is encrypted only to the first node that it
needs to reach. It transmits [the encrypted route]… to that first node. That first node can only read
the outer layer; it knows where to send it next, one hop. It unwraps [the outer layer of the encrypted route],
sends it to the next node; that node can only read… [the next hop] where it needs to send it.
It can’t see the source where it came from. It can only see that it came from the immediately
previous node [in the path] and immediately next node. It doesn’t know how long the path is,
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
[the payment], the source constructs a path based on… information it has about payment channels
that are possible routing candidates. Once it has 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 or behind. [It] doesn’t know where it’s going [to end up]
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 it is destination node. The origin node is the only one that knows
it didn’t receive this from someone else. Every node in between doesn’t know
anything [about the origin or destination]. 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 [up] a lot of value?” This is a really interesting and insightful question
because – yes, in order to use the Lightning Network, you [need] 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. 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. 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 some [bitcoin] 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 would be to… buy some bitcoin and instead of having the
seller send it to [a normal] bitcoin address, [they could] send it to your Lightning Network address,
which would then [increase the value of] your channel. [This would] allow you to make a bigger payment. Of course you can’t spend what you don’t have. That
means you will have to lock value into the channels. Ironically, this is what prevents centralisation of “hubs,”
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, that means you’re holding a lot
of bitcoin value in those channels. Those channels are hot wallets, which means
the possibility of someone hacking your node… and causing it to transmit all of that value
away is quite high. You become a target. So that’s a disincentive to running
very highly funded, centralised nodes. It’s much better to have more channels [to and from]
more nodes and to have a mesh network. [QUESTION] “A few articles have talked about AML regulation, how it might be applied to Lightning nodes. Are node operators likely to
face a lot of [legal] risk? Why?” That’s very difficult to answer at this point
because in many cases it [will be hard]… 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, the 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 places, anti-money laundering regulations
apply to flows greater than a certain amount. How these regulations would be applied to people
who are not banks or 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 that you can’t tell somebody is… running a Lightning Network node. A lot of [these concerns] came up initially when people asked… “If I run a Bitcoin node, propagating other people’s
transactions, does 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. In fact 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 isin’t? “[Will] node operators likely 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 AML regulation to Lightning nodes… will 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
payment[s] no matter where it is. In most cases you don’t need to know where it is;
that will only make the Lightning Network stealthier. [AML] is unlikely to be an effective regulation. [QUESTION] “Please explain what using
a Lightning-enabled wallet will be like. There’s a lot of confusion about channels,
the need to open and close them.” I remember a time when I was using
the internet and DNS didn’t exist. There was a lot of confusion about what
IP addresses had interesting services. I remember memorising 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
[find] someone who knew the FTP server because there were no DNS names to find it.
That was a very difficult internet to use, that nobody would use today. The early iterations of Lightning Network are like that.
They bring a lot of engineering details to the surface. 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 wallet [should]
look exactly the same as a multi-currency wallet, preferably something like Jaxx, which is one that I like.
It has multiple currencies, you can send and receive… in multiple currencies. If you want to send,
you scan a QR code and then hit ‘SEND.’ If you want to receive, you hit ‘RECEIVE.’
It shows you a QR code that somebody can scan, or you can copy it to a clipboard.
That’s how a Lightning wallet should work. You should have two buttons: SEND and RECIEVE. If you
want to send [a transaction] and you scan [an address], it should tell [you] if what you’re scanning is
a Bitcoin address or a Lightning Network channel. 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 [regular] 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
payment or an on-chain Bitcoin transaction. It will look exactly the same [in the wallet].
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 of your home computer. It knows how to route IP and it does it for you.
It does it invisibly in the background. You don’t tell your BitTorrent client
how many other [peers] to connect to. Yon’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 a QR, send, [done].
Simple as that. [QUESTION] “I’m interested in running a Lightning node. Where is the best place to start?” I found the best place to start was the Lightning Labs
implementation, Lightning Network daemon (LND). But that’s not the only one. You can also use c-lightning,
an implementation by Blockstream’s team. You can use Eclair from ASINQ, which is the third
implementation. All of three of these implementations… are what’s called BOLT-compliant. BOLT is a set of interoperability standards.
BOLT stands for “Basics of Lightning Technology,” which is what we call a backronym in this industry,
where you [choose the letters of the acronym first] then you figure out what words
would make work as an acronym. The nice thing about BOLT is that it makes sure all
implementations that are BOLT-compliant can work… with each other; they can open channels to each other, they can communicate on the network. [It creates] one unified, multi-implementation Lightning
Network. I’ve used LND, I haven’t used the other two 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
[explain] how to run a Lightning node on mainnet, which is the main network, or on
testnet if you want to run it on testnet.