A contributor to the Lightning Network codebase who goes by the name ZmnSCPxj recently wrote a reasoned post to the Lightning Development mailing list detailing what he views as a limitation of the network, which is considered by many to represent the future of Bitcoin scaling and adoption.
The identity of ZmnSCPxj is not known. As they describe on their website, they prefer to be judged by the merits of their work. The “randomly generated Internet person” does insist that they are not Craig S. Wright, Luke-Jr, or Tom Elvis Jedusor.
As they point out, their identity is truly immaterial. After all, they aren’t asking for money or making claims that can be only believed if their identity is proven (as was the case with Craig S. Wright’s claims of being Satoshi Nakamoto.)
ZmnSCPxj has asserted that the use of Lightning Network to make seamless mulit-asset conversions is limited by its technical design at present. He discusses the ability of Lightning Channels to be used for American Call Options, and points out that this essentially will be problematic in situations where the value of traded assets changes significantly during trade windows.
The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments. [… ] [I]f cross-asset exchange nodes on Lightning Network exist, they will be exploited to create risk-free American Call Options. They will find that significant liquidity will be tied up in such American Call Options, and find that they will lose funds especially at times of volatility.
He spends a lot of time discussing the various scenarios where hashlocked timelocked contracts can function as American Call Options, and concludes that the problem with this is that “across assets, the ability of HTLCs to create American Call Options becomes troublesome.”
American Call Options A Potential Weakness in Cross-Asset Transfers
ZmnSCPxj has asserted that the use of Lightning Network to make seamless mulit-asset conversions is limited by its technical design at present.
The reason for this is that traders can take advantage of existing contracts when rates change. This will ultimately make Lightning Channels an undesirable way to transact various assets. Obviously, the problem doesn’t exist when a single asset such as Bitcoin is being transacted. But, as he concludes:
Further, because Lightning UX would be degraded otherwise, payment failures are free (gratis), leading to the American Call Options also being free of premium. This means that creating such options would be riskless, allowing potential earnings upon any strong volatility of exchange rates. […] This implies that a multi-asset Lightning Network may not be economically viable. Instead, Lightning Network would strongly prefer having a single asset across the network.
ZmnSCPxj’s most recent pull request for Lightning was just a few weeks ago. This is to say: he is a relatively active developer and his words carry validity and importance.
While he doesn’t say it in his letter to the other developers, it would seem that the point of making the observation is that, if Lightning Network ultimately wants to handle multiple assets — say Bitcoin and Litecoin — within channels as a function of its offering, then it will have to develop in such a way that allows for it. The present situation will prove unworkable. One solution might be to make it cost the user to have “payment failures.” Another might be to use a different or even entirely new mechanism to handle such transactions.
Fellow developer Tamas Blummer responded:
Although there is no escape from above reasoning, a market maker could still be profitable as long as the option is worth less than the bid-ask spread. Therefore the issue does not mean that LN cross asset exchange is not feasible, but that there is lower bound on bid-ask spread, that of the option premium.
Ultimately, Lightning Network is just one second-layer scaling option for the Bitcoin network. If the Bitcoin of the future is to handle multi-asset swaps, it seems likely that products specifically geared toward this will be developed, perhaps with the input of Lightning Developers or by the developers themselves.