- Are there any limitations
that the developers are currently working on?
Keep in mind that the Lightning Network is not a company,
it's a protocol specification
and it's implemented by many, many different companies
and open source projects that implements according
to the specification.
The specification is called
the Basis of Lightning Technology
or BOLT,
which is a nice play backronym as it's called.
So BOLT is how the Lightening Network is specified
then there's a number of BOLTs
that specify how different parts work,
so that everyone can write an implementation,
and then test it for
interoperability against other clients,
and ensure that they can interoperate on this network.
Now interestingly enough, one of the advantage
that you have on the Lightning Network
is because you don't have to march
and lockstep to consensus rules,
you only care about ensuring
that the consensus rules of the Bitcoin network
support the security of what you're doing,
you can implement various features independently,
all of the standard or specification
and move a bit faster than the standard implementation.
That means the developments in Lightning
happens a lot faster.
There are a number of different companies
and projects that are implementing
all kinds of interesting features,
many of them intended to address the shortcomings,
difficulties, user interface kludges
that occur from the very first specification.
So we're currently operating on the first iteration
of the BOLT standard and that BOLT standard is
advancing gradually as new things are agreed
and added to the standard at meetings that happen
until now physically but obviously now virtually
around the world between the various teams
and developers working on this meetings
that anyone can participate in
and watch or read the transcript afterwards,
and this is where the standards are defined.
Now you will notice there're couple of things
that are difficult to do in Lightning.
Here's one example in which way Lightning differs
from a Bitcoin transactions.
In order to send someone a Lightning payment,
they must first give you an invoice.
And this has to do with the fact
that today's routing mechanism works on the basis
of the hash of a secret
that has to be back propagated across the network
in order to ensure that everybody is satisfied
with the payments and it happens trustlessly.
So that means there has to be an invoice
which means you can't just send money to someone
without first coordinating with them
and getting an invoice for the specific amount
that you want to send them.
The second issue is that nodes on the Lightning Network
have to be online
and they have to be online for two reasons,
one is to ensure that,
the counterpart in their payment channel,
doesn't try to cheat
by broadcasting an old commitment state,
which is a complex issue
that can be resolved in a number of different ways,
but for now it's simpler
to simply have these Lightning nodes online
monitoring the payment channel transaction
and ensuring that no one's trying to cheat.
And then finally,
there're a number of issues in the routing area
whereby it is sometimes both difficult to establish a route
because the sender of a transaction
has to construct that route and therefore needs a view
of the connectivity of the entire network to do
which means a big database of who's connected to who,
and this has implications both for privacy,
as well as routeability.
These are the kinds of problems
that Lightning developers are working on.
None of these problems are unsolvable,
in fact, there are many different solutions
that are being proposed,
and it's about different trade-offs
in terms of privacy and speed,
reliability and resilience of the network,
robust connectivity and all of these other issues.
There are a number of proposals to solve these,
you'll hear terms such as a Trampoline Routing,
Rendezvous Routing,
you'll hear terms such as Huddle Invoices
and Turbo Channels,
and these are all various ways of overcoming
some of the limitations that the first iteration
of the lightning specification has,
and moving the network forward
to make it easier to use, easier to understand,
more predictable in its behavior for end users,
less complex in its behavior for end users,
and to hide some of that complexity
by using various protocols and protocol improvements.
(ambient music)
If you enjoyed this video,
please subscribe, like and share.
All my work is shared for free,
so if you wanna support it, join me on Patreon.
(ambient music)