Bitcoin Q&A: Lightning Network interoperability

Bitcoin Q&A: Lightning Network interoperability


“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.

Author:

15 thoughts on “Bitcoin Q&A: Lightning Network interoperability”

  • Gee Willickers says:

    Having a shared protocol ALLOWS for interoperability. Shared protocols don't determine that all implementations will be interoperable in practice. Nor is interoperability necessarily desired among each implementation.

  • Stakenet is implimenting Segwit and lightning to be able to do atomic swaps and CCPoS (Cross chain proof of Stake)
    One of the first POS coins i believe.

  • There is no cross-compatibility between BTC and LTC aside a Submaribe Swap between Bitcoin and it's token Lighting Bitcoin

  • Hello Mr. Andreas… Congratulation!!!……you are really doing a great job….. I have a question: If I install a node of LN in my PC, and after that, I sell it….. should I necessarily reinstall the node again? and should I redo all the connections (with other nodes)? or…. is it possible (in some way) "to save" the node ? I'd really love hear from you.

  • Regarding interoperability the Aion network is the furthest along. They have an Ethereum-bridge in beta testing and will then enable any blockchain to connect through them to Ethereum. Long term they will enable all blockchains to interact with each other (transfer of value and logic) with them functioning as the underlying protocoll/infrastructure. Pretty exciting stuff!

  • Hi Andreas, I have been following DeepOnion privacy coin, and they are currently updating their code so they can implement lightning networks, smart contracts and atomic swaps. I would like to know what you think of this proposal and if it will mean good things for DeepOnion in the future? Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *