"The Lightning Network and interoperability.
The Lightning Network offers interoperability according to Elizabeth Stark...
and the 'Let's Talk Bitcoin' episode you did.
Can you please elaborate?
So many projects tout interoperability and say that we will have that with the Lightning Network,
with the additional security of the Bitcoin protocol.
Can you please explain this?"
Not quite sure what you mean by 'interoperability' here, but let's examine a couple of different
ways in which we see interoperability in these second-layer protocols.
The first one is the idea of the Lightning Network being an open protocol that can be
implemented by a wide variety of companies which can produce interoperable clients, wallets,
merchant services, and all kinds of other applications.
All of these Lightning applications (LApps) can operate because of two fundamental layers of interoperability.
The first is a protocol-level specification of how Lightning works internally, which is
called Basics of Lightning Technology (BOLT).
You can find that on GitHub as 'lightning-rfc,' which stands for "requests for comment."
That repository has, I believe, twelve specifications called BOLT.
Each one of the BOLT documents specifies a specific aspect of the Lightning Network.
It specifies exactly how it should be implemented so that there can be interoperability between clients.
For example, one of the BOLTs specifies how hashed timelocked contracts (HTLCs) are implemented
in terms of Bitcoin's script.
One of them talks about how messages are routed and serialised on the Lightning Network.
One of them talks about how different clients negotiate what capabilities they have.
One of them is a basic implementation of a source-routing gossip protocol.
All of these different specifications, very much like internet RFCs that specify how email works...
or how File Transfer Protocol (FTP) works...
All of those specifications allow developers to write a client, follow the specification,
and arrive at a degree of interoperability.
As is the case with any specification written in a human language, the specification itself
is not sufficient.
Just because you have a specification doesn't mean you can write software that will interoperate immediately.
The reason for that is because human language has ambiguity.
That ambiguity, when expressed in software, means that every developer will interpret things
slightly differently or misunderstand some of the assumptions, and then write a different implementation.
I remember the first year of my post-graduate degree in protocol design.
One of the exercises that our teachers gave us at university, was to write an implementation
of a transport layer protocol, similar to TCP but a different one (OSI stack one).
We were each given a document, which was the TP4 implementation. Then they said, "Go! Write!"
So we wrote an implementation.
We thought, 'Oh great! We've finished the exercise.'
Then the professor said, "Now make them work with each other."
We had to make a table where each of the students in the course had their own implementation
[and would be compared against] all the other implementations.
You had to put a cross mark if each of the featured worked in the table.
In the end, none of them worked with each other, because we had all made different assumptions.
It was a very good lesson into why the specifications don't necessarily [guarantee] interoperability.
Here is what we've seen in this particular area of engineering.
At the moment there are three primary development groups involved in the Lightning Network.
Lightning Labs makes LND.
You may have heard of some of the people working there,
such as Elizabeth Stark (who was on a recent podcast with us)
and of course Laolu Osuntokun, also known as "roasbeef," who is the lead developer and has done...
some amazing work in that company.
ACINQ, which is the French company that makes a client called Eclair.
Not the delicious pastry, it is in fact the word for 'lightning' in French.
The Blockstream team is implementing a client called c-lightning, and the Lightning Charge gateway
for e-commerce services.
Those three teams came together and implemented the BOLT specification.
Once they all had something that they agreed on after a big conference was compatible with BOLT,
then they spent three or four months of grueling interoperability testing -- which is still ongoing today.
The first time I tried to run a version of LND against c-lightning on mainnet a couple of months ago,
I discovered a couple of interoperability issues, filed some bug reports,
and they got fixed in the next iteration.
This is an ongoing effort.
The more these various clients talk to each other, the smoother they get, the more interoperable they become.
Interoperability is something that is achieved only as a moving target.
Keep in mind: the underlying protocol is also changing, it's getting improved at the same time.
The BOLT specifications are getting improved.
As changes happen to the specifications, then a whole new round of interoperability testing
needs to happen and these things will take a long time to evolve.
That's what interoperability means here.
That's one layer, interoperability at the protocol level, between Lightning Network nodes
that are trying to open channels with each other and route payments to each other.
A second layer of interoperability is the frontend / user interface side, which involves
encoding Lightning invoices as QR codes, etc.
What is the user experience?
Regardless of which client you use, you can use it together with other Lightning clients.
A third level of interoperability is the application programming interfaces (APIs) that...
allow various additional applications (wallets, user interfaces, merchant processing etc.)
to interoperate with various Lightning nodes.
These are usually done through some kind of remote procedure call (RPC) or gRPC interface,
which allows a client such as a desktop wallet to talk to a backend node.
For example, your wallet might talk to the Bitcoin Core client over an API.
Then finally, there's interoperability between blockchains.
Right now on the Lightning Network, there's support for two blockchains: Bitcoin and Litecoin.
One of the levels of interoperability is the ability to send a payment in one cryptocurrency
and receive it in another cryptocurrency.
Essentially, have the Lightning Network bridge Litecoin and Bitcoin.
I expect we're going to see many more currencies added as the BOLT specification is ported
to other blockchains beyond Bitcoin and Litecoin.
That's interoperability.
It's a moving target, it's a complex topic, and it's happening at different layers simultaneously
with lots of different teams working on details within the protocol.
The protocol itself is changing.
But I think all of this complexity and all of this work going into interoperability really makes a joke
of the idea that the Lightning Network is controlled by one company or that it's a "product."
It really is an open protocol with a lot of collaboration between a lot of teams with
different interests, trying to build interesting applications with this technology.
Eric asks, "LApps and atomic swaps. I'm excited about the release of the first new Lightning apps (LApps)."
"However I didn't see anything about atomic swaps on Lightning."
Do you foresee that altcoins without SegWit will integrate with the Lightning ecosystem and LApps?"
It's not the issue of whether altcoins have or don't have SegWit.
SegWit isn't necessary for Lightning to operate.
It's more about whether these other chains have a fix for transaction malleability.
If a chain has a fix for transaction malleability, and that fix could be SegWit, flexible transactions,
or a hundred other schemes that could be used...
If a chain does not have a transaction malleability problem and it has the basic capabilities of
simple smart contracts, specifically multi-signature and hashed timelocks, then you can implement Lightning.
In fact, you could implement Lightning [and be] compatible with the BOLT standard, which would
then allow you to do multi-currency swaps between that chain, Bitcoin, and Litecoin.
The reason you don't see atomic swaps is because this is still the very early days in Lightning development.
You won't see a LApp implementing atomic swaps any time soon.
If you do, you're going to see it with Litecoin and Bitcoin only.
That's because the only client that supports multiple chains is LND,
the Lightning Network daemon from Lightning Labs.
For the time being, that [only] supports Bitcoin and Litecoin, no other chains.
We might see a LApp that implements atomic swaps between Bitcoin and Litecoin.
You don't need Lightning to do atomic swaps.
You can do them using simpler technology.
We've seen that demonstrated by a number of different chains.
I believe the first one to do it was Komodo.
But if people port the Lightning software, or implement their own Lightning software
using the BOLT specifications, to their blockchain, then eventually we will be able to see a multi-currency
Lightning running across multiple blockchains.
I expect that someone is going to build an easy-to-use LApp that allows you to do...
cryptocurrency conversion in a decentralised manner.
It's just going to take time.