 Lightning network and interoperability. Lightning network offers interoperability according to Elizabeth Stark and the Let's Talk Bitcoin episode you did. Can you please elaborate so many projects, count interoperability, and say that we will have that with lightning network and the additional security of the Bitcoin protocol? Can you please explain this? Not quite sure what you mean by interoperability, 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 that can produce interoperable clients, wallets, merchant services, all kinds of other applications, all of these applications, lightning applications, or laps, as they have now been called, can operate because of two fundamental layers of interoperability. The first one is a protocol-level specification of how lightning works internally, which is called BOLT, Basics of Lightning Technology. You can find that on GitHub, the lightning-RFC, which stands for Request for Comments. That repository has, I believe it is now, 12 specifications called BOLT, BOLT1 through BOLT12, and each one of the BOLT documents specifies a specific aspect of the Lightning network and specifies exactly how it should be implemented so that there can be interoperability between clients. For example, one of the BOLT specifies how hashed time-locked contracts are implemented in terms of Bitcoin script. One of them talks about how messages are routed and how they are serialized on the Lightning network. One of the BOLT specification 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 on the internet, or how FTP works, for example, 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 you express it in software means that every developer will interpret things slightly differently, maybe misunderstand some of the assumptions, and write a slightly different implementation. I remember specifically in my first year of my postgraduate 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 this was a different one, the OSI-STAC one. We were each given the document, which was the TP4 implementation for this protocol, and said, Right, so we wrote an implementation. We thought, Oh great, we finished the exercise, and then the professor said, Great, now make them work with each other, and we had to do a table where each of the students in the course had their own implementation, and across the top all of the other implementations, and then you put a cross mark if each of the features works in the table. None of them worked with each other, because we had all made different assumptions, and it was a very good lesson into why the specs don't necessarily mean interoperability. What we've seen in this particular area of engineering is the Lightning Network groups that are involved in this, which at the moment are three primary development groups, the Lightning Network Company, which makes L&D, and you may have heard of some of the people working there, Elizabeth Stark, who was on a recent podcast with us, and of course, Laulu, also known as Roastbeef, who is the lead developer and has done some amazing work in that company. Async, which is a French company that makes a product called Eclair, which is not the delicious pastry, but is in fact the name for Lightning in French, and the Blockstream team that is implementing a client called Sea Lightning, and the Lightning Charge gateway for e-commerce services. Those three teams came together, implemented the Bolt specification, and once they all had something that they had agreed on after a big conference was compatible with Bolt, then they spent, I think it was three or four months, of grueling interoperability testing, which is still ongoing today. The first time I tried to run a version of L&D against Sea Lightning on Mainnet a couple of months ago, I discovered a couple of interoperability bugs and filed some bug reports, and those got fixed in the next iteration, etc. This is an ongoing effort. The more these various clients talk to each other, the smoother they get, the more interoperable they get, and interoperability is something that is achieved only as a moving target. Because, keep in mind, the underlying protocol is also changing, it's getting improved at the same time. The Bolt specifications are getting improved, and as changes happen to the specifications, then a whole new round of interoperability needs to happen, and these things will take a long time to continue to evolve. That's what interoperability means. That's one layer. Interoperability at the protocol level between Lightning network nodes that are trying to open channels with each other, route payments to each other, and interoperate in that way. A second layer of interoperability is the front-end user-interfacing side, which involves how do you encode Lightning invoices, QR codes, etc. What is the user experience so that, regardless of which client you use, you can use it together with other Lightning network clients? A third level of interoperability is the API's application programming interfaces that allow various additional applications, wallets, user interfaces, merchants, processing applications, etc., to interoperate with various Lightning nodes. These are usually done through some kind of RPC, remote procedure call, or GRPC, which is the Google version of that interface, that allows a client, let's say a desktop wallet, to talk to a back-end node, just like, for example, your wallet might talk to a Bitcoin core over an API. Finally, there is interoperability between blockchains. Right now, on the Lightning network, there is support for two blockchains, Bitcoin and Litecoin. One of the levels of interoperability is the ability to send a payment in one currency and receive it in another currency. So, essentially, have Lightning network bridge Litecoin and Bitcoin. I expect we will see many more currencies added as the bulk specification is ported to other blockchains beyond Bitcoin and Litecoin. That is interoperability. It is a moving target, a complex topic, happening at different layers simultaneously, with lots of different teams working on different details within the protocol, and the protocol itself is changing. But I think all of this complexity and all of this work that's going into interoperability really makes a joke of the idea that Lightning network is controlled by one company, or that it's a product of one company. 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, LAPS and Atomic Swaps. I'm excited about the release of the first new LAPS. LAPS, by the way, stands for Lightning Apps LAPS. However, I didn't see anything about Atomic Swaps on Lightning. Do you foresee the possibility altcoins without sequit integrating with the Lightning ecosystem with a LAP? Eric, it's not the issue of whether altcoins have or don't have a sequit. A sequit isn't necessary for Lightning to operate. It's more about whether these other chains have a fix for transaction liability. If a chain has a fix for transaction liability, if it doesn't suffer from a transaction liability, that fix could be sequit, it could be flexible transactions, it could be a hundred other schemes that could be used to change transaction liability. If a chain does not have a transaction liability problem, and it has the basic capabilities of simple smart contracts, specifically multi-signature, hash time locks, in its capability, then you can absolutely implement Lightning. In fact, you can implement Lightning that's compatible with the Bolt standard, which would then allow you to do multi-currency Lightning between that chain and Bitcoin and Litecoin. The reason you don't see Atomic Swaps is because right now, this is very early days in Lightning, and you won't see a LAP implementing Atomic Swaps. I don't think anytime soon, and if you do, you're going to see it on Litecoin and Bitcoin only. That's because really the only client I believe that supports multiple chains is LND, the Lightning Network Demon from Lightning Labs. That, for the time being, supports Bitcoin and Litecoin, no other chains at the moment. We might see a LAP 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 multi-currency Lightning running across multiple blockchains. I expect that someone is going to build an easy-to-use LAP that allows you to do currency conversion in a decentralized manner over Lightning. It's just going to take time.