Developers Point Out Flaw in Lightning Network’s Cross-Chain Functionality

While the Lightning Network is mostly known as a way to make Bitcoin payments instant and practically free, another often-touted aspect of the layer-two protocol has been its ability to enable a sort of decentralized exchange as a side effect of its original goals. However, the viability of this functionality has come under fire recently as developers have pointed out an economic issue with this system. Having said that, this is an issue that has been known about since the early days of the Lightning Network’s development.” to the end of the first paragraph

How the Lightning Network Functions as a Decentralized Exchange

Although the Lightning Network is usually associated with Bitcoin, the payments-focused layer can be built on top of any other blockchain that has the proper underlying features. For example, Lightning transactions have been successfully tested on the Litecoin and Vertcoin networks.

When Lightning Network functionality is available on more than one blockchain, it becomes possible to instantly swap the native tokens of those blockchains in a decentralized, low-trust manner. This works by routing payments through Lightning Network users who are operating on multiple blockchains. If Alice wants to send some litecoin to Bob but she only has bitcoin available, she can route through a third party who is holding both bitcoin and litecoin on the Lightning Network.

The Issue with This Setup

While this decentralized exchange sounds amazing in theory, multiple developers have poked holes in the logic behind the feature.

As pointed out in the most recent issue of Bitcoin Optech Newsletter, Lightning Network developer Corné Plooy created a thread on the Lightning-Dev mailing list back in May of last year where he explained how cross-chain Lightning Network payments effectively create a nearly-free options contract for users. A pseudonymous developer recently brought the topic up again on the same mailing list.

The basic issue at hand is Lightning Network participants are able to delay transactions. Through this flaw, a user could pause an exchange from bitcoin to litecoin (for example) and see how the bitcoin to litecoin exchange rate changes over the next 24 hours.

If the exchange rate moves in the user’s favor, they’ll complete the transaction. If the exchange rate moves against them, then they’ll cause the transaction to fail. With this method, the user can make money by simply canceling unprofitable trades and accepting profitable trades. They basically get to trade based on knowledge of where the price will move in the future.

A Solution That’s Good Enough

While the pseudonymous developer behind the most recent mailing list thread on this topic believes the idea of a multi-asset Lightning Network should be abandoned, Plooy has offered a potential solution that involves the use of a third party between the two users who want to make a trade. It may seem paradoxical to solve a Bitcoin problem with the use of a trusted third party, but the amount of trust placed in the third party is rather low. More importantly, Plooy’s solution is still an improvement over traditional, centralized crypto asset exchanges.

“The system described here is not perfect, but when it comes to developing decentralized and trust-free alternatives to exchange services, it is an improvement,” writes Plooy in his explanatory paper on his solution (PDF), “Compared to a regular exchange service, which has control over customers’ funds, the routing service cannot steal from its customers, it cannot lose customers’ funds in case of a hack, and unless the service provider [decides] to add restrictions on who [or] when to serve, it doesn’t have to know any [identifying] information about its customers, or even what asset is being traded between them, at what exchange rate.”

In short, the only way the trusted third party can cheat is to conduct the same delay attack that Plooy’s solution is intended to solve in the first place. Trusted third parties can compete with each other on fees, trustworthiness (not doing the delay attack on their users), and other features. The need to preserve one’s reputation as an exchange provider on the Lightning Network should limit the proliferation of this attack.

For now, it remains unclear how a Lightning-based decentralized exchange will function in the real world, but Plooy’s solution appears to be a “good enough” approach that can still offer tremendous value to users. Additionally, it’s possible that someone else will come up with a better solution that would make the Lightning Network’s functionality as a decentralized exchange require even less trust in a third party.

Updated (13th of January): This article was updated to better clarify that this particular issue with the Lightning Network’s cross-chain functionality had been known about since the early days of the protocol’s development