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 uncovered a potential exploit of this system.
Lightning Network will be the ultimate decentralized exchange. Users that are running LN on both BTC and LTC can advertise an exchange price and act as a maker earning a spread. Other users can act as a taker and atomically swap LTC/BTC with the maker node via lightning. â¡ðð
â Charlie Lee [LTCâ¡] (@SatoshiLite) July 11, 2018
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.