The first question is from an anonymous patron. "How confident are you that the Lightning Network
will bring the desired scalability, security, and [privacy]?" I'm very confident. I'm not only confident that
we will be able to achieve tremendous scaling, but I also think we will be able to achieve
much better security and privacy. What do I mean by that? We will see the Lightning Network operating… either before the end of the year,
or very shortly after the beginning of 2018. I have already been running beta test software for LND,
the Lightning Network daemon from [Lightning Labs], but there are a number of [other] implementations.
Most people misunderstand and think
the Lightning Network is a company. There is a company called Lightning [Labs],
just like there is a company called Blockchain. But it doesn't mean that company
makes or controls the blockchain. [Lightning Labs isn't the only] company that
makes [software for] the Lightning Network. There is one implementation by Lightning [Labs], the
company which [initiated a lot of the development], but the specification for the protocol is open source. About a year ago, various different groups
involved in Lightning [development] got together… and built a set of common interoperability standards. These standards are called "BOLT,"
the 'Basics Of Lightning Technology.' There are all of these puns you can make about
weather, clouds, lightning strikes, and thunder. People are really milking that metaphor. BOLT is a set of standards to define how
various implementations would interoperate. I believe there are [eleven] BOLT documents on GitHub
as part of a 'Request for Comment' (RFC) [repository].
They are interoperability standards [for] the six different
teams working on implementations of Lightning. [Those teams include] Lightning [Labs], Blockstream
making c-lightning, and ACINQ making Eclair. [Eclair is] French for 'lightning,'
[because ACINQ is] a French company. Those three are most prominently
involved in interoperability testing, but there other other companies working on
implementations in a variety of different languages. These are completely independent teams, all working
on open-source projects [within] the same standards. For the last month or so, the three companies
with the most advanced implementations for far — which are very close to production capability
— have done interoperability testing. Last week, all three companies passed
all seventy-five tests of compatibility, meaning that using any of the three implementations
would work as part of the [same] Lightning Network.
That means it doesn't matter which client you have,
just as it doesn't matter what bitcoin wallet you use. as long as it is interoperable, able to open channels, route payments to any of the other clients. and do so with a higher degree of privacy. They are all implementing the onion routing protocol, where each node only sees the immediate hop
before it, and the immediate hop after it. It is called onion routing because the routing
information is wrapped in encrypted layers. So you receive an encrypted package from the node
[one hop before you]; you don't know where… this [payment] is [ultimately being routed], and the node
before you doesn't know [either, unless they sent it]. You unwrap [one layer] and find
[some] routing information inside, which tells you where [it] goes for the next hop,
but you don't know anything more than that.
So you send it to the next hop. They [decrypt another
layer of] routing information, and send it to the next hop. No node in this route knows how many hops
have passed, or how many hops are yet to come, [unless they are the sender or receiver]. The routes are [limited to 20 hops and can vary,
but they will appear as being the same length]. You can't tell if you are the second
or twentieth hop in a 20-hop route. Paths can be up to twenty hops long,
and they always look like twenty hops. If the route is less than twenty hops, the route
information is padded with encrypted garbage. [As a routing node], you won't know it is garbage,
so you will just pass it on [normally] to the next node. One of the nodes will [decrypt the final layer]
and [see] that it is the destination of the route. The [remaining routing] directions that follow
are just garbage and it discards them.
Only that node, the recipient, and the sending node will
know it is the last one and how long the route is. Only the sender and recipient know
which position they are in the route. Everybody in between is just passing this
encrypted bundle of information [along]. This is a very high security protocol. It is the same
[type of] protocol that is used in Tor, 'the Onion Router.' The initial implementation of the Lightning Network
will use [the Sphinx construction for] onion routing. for very high degree of privacy. One of the questions that remains is,
will Lightning become centralized? Are there particular incentives to running a hub, which is
a node connected with lots of payment channels… [with] lots of other nodes. [If that hub is] used for a lot of the routes,
is it possible that [they will use it for censorship]? Is it possible that people with a lot of money, [such as]
exchanges, would set up Lightning nodes that are…
The main participants in the Lightning Network? [Would that result in] this hub-and-spoke system
with a lot of concentration and centralization? I think it is unlikely that will happen
[for] a number of reasons. First of all, if you're running a Lightning node [with]
open channels in order to route [a lot of] payments, you must have the keys online. The more funds you put into those payment channels,
the higher the risk that your node is a target for hacking. There is a disadvantage to having a node
with a lot of funds [in open payment channels]. Instead, if each node opens four or five different
routes, they create this fairly tight mesh [network]… that is very peer-to-peer, then there is not centralization. That is the best model for [the Lightning Network]. It is what is called a "scale-free" network,
which means it looks the same at any scale.
A network like that doesn't have
any tendency to centralization. There are good reasons why
centralization is discouraged. The Lightning Network, with the current BOLT
specification, is also implementing [the ability]… to re-balance channels. If you continuously send on one channel, all of the funds
will eventually end up on the far end of the channel. In order to re-balance it, you need to route payments
in the opposite [direction, back to you]. They do that automatically.
I've looked at the Lightning Network daemon. One of the things I like quite a lot, is the
mechanism for automatically managing channels, so you don't have to think about [how to open
channels and choosing which peers to connect to]. You can run a full Lightning node on your smartphone,
your laptop or desktop computer.
You don't need to worry about what channels it
needs to open. It manages channels on its own. It opens channels to [peers] that it
thinks will have good connectivity, [similar to how] your Bitcoin node
makes connections to other nodes. The advantage of that [mechanism to]
automatically manage channels is, [it is easier] to create this [mesh network] environment..