<div dir="ltr">It seems like the router in this case is essentially short a straddle on the BTC vs. WJT exchange rate with almost 0 premium. One way for the router to hedge this is to be long an equivalent straddle by constructing their own cross-chain payment to themselves with some other node, for the same amount. <div><br></div><div>This obviously can't scale to all participants, but can possibly provide a hedge for a single node.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 27, 2018 at 1:33 PM Tamas Blummer <<a href="mailto:tamas.blummer@gmail.com">tamas.blummer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ZmnSCPxj,<br>
<br>
Brilliant reasoning. I sum it up to make it more accessible: <br>
<br>
Failing to route on purpose can be used to opt out of a previously agreed exchange of two differents assets.<br>
A rational actor will opt out if the exchange is no longer fair. Anyone who grants an option for free heads financial disaster.<br>
<br>
This is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point. <br>
<br>
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. <br>
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.<br>
<br>
Tamas Blummer<br>
<br>
<br>
> On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev <<a href="mailto:lightning-dev@lists.linuxfoundation.org" target="_blank">lightning-dev@lists.linuxfoundation.org</a>> wrote:<br>
> <br>
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network<br>
> <br>
> Introduction<br>
> ============<br>
> <br>
> In theory, the Lightning Network could potentially perform "seamless" currency conversions, allowing a payer to spend one currency to pay a payee requesting for another currency.<br>
> However, a significant technical barrier prevents implementation of such feature as of current designs (late 2018) for Lightning.<br>
> <br>
> The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments.<br>
> HTLCs can be used across cryptocurrency systems to transfer value between them.<br>
> From this point-of-view, every single Lightning Network channel is a cryptocurrency system whose custodians are two entities, who are the only entities who can use the system (the single Lightning Network channel).<br>
> HTLCs allow cross-system trades to be performed, so that participation on any single Lightning Network channel can be leveraged to participation over the entire Lightning Network.<br>
> <br>
> However, HTLCs can also be used to construct American Call Options.<br>
> Further, due to UX concerns, on the Lightning Network, there is no cost incurred in merely setting up HTLCs for routing.<br>
> By using the low-level HTLCs provided as primitives by Lightning Network, one can set up American Call Options.<br>
> These on-Lightning American Call Options, however, can be "purchased" for free (gratis), thus potentially earning money in a completely risk-free manner.<br>
> Abusing this gratis ability means that any Lightning Network node advertising cross-asset on-Lightning exchange will find large amounts of its liquidity tied up in stalled forwarding payments (in reality, American Call Options) with a risk of monetary loss in case of large fluctuations in exchange rate.<br>
> <br>
> Hashlocked Timelocked Contracts as American Call Options<br>
> ========================================================<br>
> <br>
> An American CallOption is a right (but not obligation) to purchase an asset at a specific price, on or before an expiration date.<br>
> HTLCs allow building American Call Options.<br>
> <br>
> Suppose we have Bitcoin, and some other asset, and both are on blockchains that support the same hash function and can define HTLCs.<br>
> It is unimportant if both are on the same blockchain, or on different blockchains, since HTLCs can work across cryptocurrency systems.<br>
> <br>
> An American Call Option has these properties:<br>
> <br>
> 1. `P` = the price at which the asset can be purchased.<br>
> 2. `E` = the date at which the option expires.<br>
> <br>
> Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget (WJT) on the WJT blockchain.<br>
> We would then do the below ritual:<br>
> <br>
> 1. You provide me a hash of some secret preimage that only you know.<br>
> 2. You make an HTLC on the Bitcoin blockchain.<br>
> The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.<br>
> 3. I make an HTLC on the WJT blockchain.<br>
> The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.<br>
> <br>
> On or before `E`, you can claim the WJT on the WJT blockchain by providing a transaction that reveals the preimage.<br>
> Since the preimage is now revealed, I can then claim the Bitcoins of price `P` on the Bitcoin blockchain.<br>
> Alternately, you can simply not exercise this right, and at time `E` I would then reclaim my WJT, and at time `E` + 1 day you would reclaim your bitcoins.<br>
> <br>
> Of course, I want to *sell* this contract to you, so you would have to pay me some bitcoins before we set up the above.<br>
> A multi-stage construction of transactions that go through HTLC-like constructs can be done on both blockchains to ensure that the above contracts appear on both chains only if the payment for the actual contract (i.e. the "premium") is done, and to enforce that both contracts appear if the premium is paid, but that is beyond the scope of *this* writeup, which will focus on how Lightning Network HTLCs can form the above construction without any premium being paid.<br>
> <br>
> HTLCs For Routing<br>
> =================<br>
> <br>
> HTLCs can be used to enforce trades across different cryptocurrency systems.<br>
> This property is used to allow routing of payments across different channels.<br>
> Each channel is its own cryptocurrency system.<br>
> <br>
> Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I wanted to sell you my service of facilitating payments on Lightning.<br>
> Suppose you want to pay to somebody, who, for the sake of convenience, we shall randomly call YAIjbOJA.<br>
> As it happens, I have a channel with you, and a channel with YAIjbOJa.<br>
> <br>
> You need to pay YAIjbOJA `P` bitcoins.<br>
> We then perform the below ritual:<br>
> <br>
> 1. YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.<br>
> 2. On your channel with me, you set up an HTLC.<br>
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash you were given, and the timelock is 2 days from now.<br>
> 3. On my channel with YAIjbOJA, I set up an HTLC.<br>
> The value is `P`, the hash is the same hash as above, and the timelock is 1 day from now.<br>
> <br>
> (in reality, the timelocks are parameterized and selected by the payer (you), and LN nodes will impose some "reasonable" limits on the timelocks; but the first HTLCs set up must have longer timelocks than the later HTLCs)<br>
> <br>
> Afterward, YAIjbOJA may claim, or may not claim, the money in the HTLC by releasing (or not releasing) the hash to me.<br>
> If YAIjbOJA claims the money, then I can take the hash and claim the money, plus fee, from you.<br>
> If not, then this is a payment failure and I will then cancel the HTLC you offered using standard Lightning Network primitives.<br>
> <br>
> In general, we expect that YAIjbOJA wants to have the money because every randomly-generated imaginary entity likes money.<br>
> Thus, in the case of payments, YAIjbOJA has a strong incentive to claim the money without waiting for the timelock to expire or nearly expire.<br>
> We can see that in practice, on the current Lightning Network, HTLCs are often very transient and will be quickly claimed, despite having long timelocks.<br>
> <br>
> This speed may mislead us into thinking that such convenience may be possible across different assets.<br>
> <br>
> Cross-Asset Lightning Nodes Offer Premium-Free American Call Options<br>
> ====================================================================<br>
> <br>
> Suppose that Lightning Network supports multiple assets.<br>
> Each channel has a single asset.<br>
> Some nodes will advertise themselves as providing exchange capability, taking one asset on one channel and exchanging it for another asset on a different channel.<br>
> <br>
> Suppose I advertise myself as such an exchange.<br>
> Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on hand to pay YAIjbOJA, only bitcoins.<br>
> As it happens, I have a bitcoin channel with you and a WJT channel with YAIjbOJA.<br>
> I advertise myself as exchanging `P` bitcoins for 1 WJT as of the current time.<br>
> <br>
> Further suppose that in reality, YAIjbOJA is *you*, random Internet person reading my thoughts.<br>
> <br>
> You, your fake persona YAIjbOJA, and me, then perform the following ritual:<br>
> <br>
> 1. YAIjbOJA (really you) provides you with a hash whose preimage only YAIjbOJA (actually you) know. (i.e. you just make it up)<br>
> 2. On the bitcoin channel with me, you set up an HTLC.<br>
> The value is `P`+1 bitcoin (the 1 being my fee), the hash is the hash that "YAIjbOJA" gave you (i.e. you really just made it up), and the timelock is 2 days from now.<br>
> 3. On the WJT channel with YAIjbOJA (really you), I set up an HTLC.<br>
> The value is 1 WJT, the hash is the hash you gave me, and the timelock is 1 day from now.<br>
> <br>
> The above is now the same as the setup for an American Call Option with expiration of 1 day from now.<br>
> Further, within certain limits, you can set up the expiration of the American Call Option to be longer or shorter.<br>
> Thus, I have inadvertently given you an American Call Option, for *no premium* (completely gratis), when my only intent was to facilitate cross-currency Lightning Network payments.<br>
> <br>
> Suppose that the price of 1 WJT rises far above the price of `P`+1 bitcoins before the expiration (1 day from now).<br>
> In such a case, "YAIjbOJA" (really you) will then release the hash and acquire the 1 WJT.<br>
> You then close this channel and claim the WJT onchain, then sell it immediately to earn more than the `P`+1 bitcoins you paid.<br>
> Alternatively, presumably I would have a new exchange rate I would be willing to exchange WJT for, and you can just send the WJT with the new exchange rate immediately over the Lightning Network.<br>
> <br>
> Suppose that the price of WJT does not rise.<br>
> Since this is an option and *not* a future, "YAIjbOJA" (really you) will simply claim that the payment errored somewhere and cancel the HTLCs.<br>
> Since even payment errors are not unwrappable and are onion-wrapped, I cannot determine whether the payment really errored, or you were just setting up an American Call Option that you have now decided not to exercise.<br>
> <br>
> Premium-free American Call Options Are Risk-free Earning Pumps<br>
> ==============================================================<br>
> <br>
> Traditionally, options are analyzed assuming that the option itself has a price, the premium.<br>
> This premium is the risk of the user of the option.<br>
> If the user of the option does not exercise the option before the expiration, then the premium is a pure loss of the user.<br>
> <br>
> However, the above setup does not involve any payment when the option is not exercised.<br>
> Payment failures are "free" (gratis) on the Lightning Network.<br>
> However, payment failures are also the non-exercised branch of the American Call Option that can be set up on a cross-currency on-Lightning exchange.<br>
> <br>
> Because the American Call Option is premium-free, even if the expiration is very near, rational entities will still construct such options.<br>
> Extreme volatility may occur in short time frames, especially in the realm of digital assets.<br>
> <br>
> Thus, it is strongly likely that, if cross-asset exchange nodes on Lightning Network exist, they will be exploited to create risk-free American Call Options.<br>
> 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.<br>
> <br>
> We can try to mitigate this, but the solutions below all have significant drawbacks.<br>
> <br>
> 1. We could force that setting up the HTLCs requires payment.<br>
> This forces the above American Call Options to have a premium.<br>
> The effect, however, is that routing failure is not free.<br>
> The current Lightning Network works despite not everyone publishing the balances of channels, precisely because routing failure is free.<br>
> We only need to have one route succeed in order to actually successfully pay to the payee.<br>
> With non-free routing failure, we cannot try many routes until one succeeds.<br>
> * Suppose we limited this only to cross-asset exchanges.<br>
> It would still require accurate knowledge of channel balances.<br>
> This is because if a payment fails on a hop *after* the exchange, the payer still loses money from that attempt to the exchange node.<br>
> 2. Exchange nodes could increase their fees.<br>
> This would create a wider "spread" of buying and selling assets.<br>
> This spread would increase friction in crossing assets.<br>
> Also, this would only reduce risk; if the exchange rate is volatile enough, then the option could still be exercised for riskless earnings.<br>
> Rational entities will still tie up most of the liquidity on the exchange on riskless American Call Options; even if the exchange rate is very stable, they lose nothing.<br>
> 3. Exchange nodes could limit the timelock of cross-asset swaps.<br>
> This would increase friction in crossing assets, since a timelock limit also imposes a limit to the route length.<br>
> If one asset is much stronger than the other, then the weaker asset will find its part of the Lightning Network to be strongly centralized around the exchanges between the two assets.<br>
> Payees of the weaker asset will strongly prefer to be at most one hop away from exchanges in order to viably receive payments from payers who are using the stronger asset.<br>
> Again, rational entities will also still tie up most of the liquidity on the exchange on riskless American Call Options; again, even if the exchange rate is very stable in short time frames, they lose nothing anyway.<br>
> <br>
> Conclusion<br>
> ==========<br>
> <br>
> HTLCs allow creation of American Call Options.<br>
> The same HTLCs are used in Lightning Network to route across channels.<br>
> If using a single asset, there is no issue related to time.<br>
> Regardless of the value of bitcoin relative to any other asset, in the future, 1 BTC is 1 BTC.<br>
> <br>
> However, across assets, the ability of HTLCs to create American Call Options becomes troublesome.<br>
> These can then be exploited to earn money from exercise of the option.<br>
> Further, because Lightning UX would be degraded otherwise, payment failures are free (gratis), leading to the American Call Options also being free of premium.<br>
> This means that creating such options would be riskless, allowing potential earnings upon any strong volatility of exchange rates.<br>
> <br>
> This implies that a multi-asset Lightning Network may not be economically viable.<br>
> Instead, Lightning Network would strongly prefer having a single asset across the network.<br>
> <br>
> _______________________________________________<br>
> Lightning-dev mailing list<br>
> <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>