📅 Original date posted:2018-12-27
📝 Original message:
ZmnSCPxj,
Brilliant reasoning. I sum it up to make it more accessible:
Failing to route on purpose can be used to opt out of a previously agreed exchange of two differents assets.
A rational actor will opt out if the exchange is no longer fair. Anyone who grants an option for free heads financial disaster.
This is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point.
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.
Tamas Blummer
> On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network
>
> Introduction
> ============
>
> 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.
> However, a significant technical barrier prevents implementation of such feature as of current designs (late 2018) for Lightning.
>
> The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments.
> HTLCs can be used across cryptocurrency systems to transfer value between them.
> 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).
> 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.
>
> However, HTLCs can also be used to construct American Call Options.
> Further, due to UX concerns, on the Lightning Network, there is no cost incurred in merely setting up HTLCs for routing.
> By using the low-level HTLCs provided as primitives by Lightning Network, one can set up American Call Options.
> These on-Lightning American Call Options, however, can be "purchased" for free (gratis), thus potentially earning money in a completely risk-free manner.
> 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.
>
> Hashlocked Timelocked Contracts as American Call Options
> ========================================================
>
> An American CallOption is a right (but not obligation) to purchase an asset at a specific price, on or before an expiration date.
> HTLCs allow building American Call Options.
>
> Suppose we have Bitcoin, and some other asset, and both are on blockchains that support the same hash function and can define HTLCs.
> It is unimportant if both are on the same blockchain, or on different blockchains, since HTLCs can work across cryptocurrency systems.
>
> An American Call Option has these properties:
>
> 1. `P` = the price at which the asset can be purchased.
> 2. `E` = the date at which the option expires.
>
> Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget (WJT) on the WJT blockchain.
> We would then do the below ritual:
>
> 1. You provide me a hash of some secret preimage that only you know.
> 2. You make an HTLC on the Bitcoin blockchain.
> The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.
> 3. I make an HTLC on the WJT blockchain.
> The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.
>
> On or before `E`, you can claim the WJT on the WJT blockchain by providing a transaction that reveals the preimage.
> Since the preimage is now revealed, I can then claim the Bitcoins of price `P` on the Bitcoin blockchain.
> 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.
>
> 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.
> 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.
>
> HTLCs For Routing
> =================
>
> HTLCs can be used to enforce trades across different cryptocurrency systems.
> This property is used to allow routing of payments across different channels.
> Each channel is its own cryptocurrency system.
>
> Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I wanted to sell you my service of facilitating payments on Lightning.
> Suppose you want to pay to somebody, who, for the sake of convenience, we shall randomly call YAIjbOJA.
> As it happens, I have a channel with you, and a channel with YAIjbOJa.
>
> You need to pay YAIjbOJA `P` bitcoins.
> We then perform the below ritual:
>
> 1. YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.
> 2. On your channel with me, you set up an HTLC.
> 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.
> 3. On my channel with YAIjbOJA, I set up an HTLC.
> The value is `P`, the hash is the same hash as above, and the timelock is 1 day from now.
>
> (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)
>
> Afterward, YAIjbOJA may claim, or may not claim, the money in the HTLC by releasing (or not releasing) the hash to me.
> If YAIjbOJA claims the money, then I can take the hash and claim the money, plus fee, from you.
> If not, then this is a payment failure and I will then cancel the HTLC you offered using standard Lightning Network primitives.
>
> In general, we expect that YAIjbOJA wants to have the money because every randomly-generated imaginary entity likes money.
> 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.
> 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.
>
> This speed may mislead us into thinking that such convenience may be possible across different assets.
>
> Cross-Asset Lightning Nodes Offer Premium-Free American Call Options
> ====================================================================
>
> Suppose that Lightning Network supports multiple assets.
> Each channel has a single asset.
> 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.
>
> Suppose I advertise myself as such an exchange.
> Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on hand to pay YAIjbOJA, only bitcoins.
> As it happens, I have a bitcoin channel with you and a WJT channel with YAIjbOJA.
> I advertise myself as exchanging `P` bitcoins for 1 WJT as of the current time.
>
> Further suppose that in reality, YAIjbOJA is *you*, random Internet person reading my thoughts.
>
> You, your fake persona YAIjbOJA, and me, then perform the following ritual:
>
> 1. YAIjbOJA (really you) provides you with a hash whose preimage only YAIjbOJA (actually you) know. (i.e. you just make it up)
> 2. On the bitcoin channel with me, you set up an HTLC.
> 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.
> 3. On the WJT channel with YAIjbOJA (really you), I set up an HTLC.
> The value is 1 WJT, the hash is the hash you gave me, and the timelock is 1 day from now.
>
> The above is now the same as the setup for an American Call Option with expiration of 1 day from now.
> Further, within certain limits, you can set up the expiration of the American Call Option to be longer or shorter.
> 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.
>
> Suppose that the price of 1 WJT rises far above the price of `P`+1 bitcoins before the expiration (1 day from now).
> In such a case, "YAIjbOJA" (really you) will then release the hash and acquire the 1 WJT.
> You then close this channel and claim the WJT onchain, then sell it immediately to earn more than the `P`+1 bitcoins you paid.
> 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.
>
> Suppose that the price of WJT does not rise.
> Since this is an option and *not* a future, "YAIjbOJA" (really you) will simply claim that the payment errored somewhere and cancel the HTLCs.
> 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.
>
> Premium-free American Call Options Are Risk-free Earning Pumps
> ==============================================================
>
> Traditionally, options are analyzed assuming that the option itself has a price, the premium.
> This premium is the risk of the user of the option.
> If the user of the option does not exercise the option before the expiration, then the premium is a pure loss of the user.
>
> However, the above setup does not involve any payment when the option is not exercised.
> Payment failures are "free" (gratis) on the Lightning Network.
> 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.
>
> Because the American Call Option is premium-free, even if the expiration is very near, rational entities will still construct such options.
> Extreme volatility may occur in short time frames, especially in the realm of digital assets.
>
> 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.
> 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.
>
> We can try to mitigate this, but the solutions below all have significant drawbacks.
>
> 1. We could force that setting up the HTLCs requires payment.
> This forces the above American Call Options to have a premium.
> The effect, however, is that routing failure is not free.
> The current Lightning Network works despite not everyone publishing the balances of channels, precisely because routing failure is free.
> We only need to have one route succeed in order to actually successfully pay to the payee.
> With non-free routing failure, we cannot try many routes until one succeeds.
> * Suppose we limited this only to cross-asset exchanges.
> It would still require accurate knowledge of channel balances.
> 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.
> 2. Exchange nodes could increase their fees.
> This would create a wider "spread" of buying and selling assets.
> This spread would increase friction in crossing assets.
> Also, this would only reduce risk; if the exchange rate is volatile enough, then the option could still be exercised for riskless earnings.
> 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.
> 3. Exchange nodes could limit the timelock of cross-asset swaps.
> This would increase friction in crossing assets, since a timelock limit also imposes a limit to the route length.
> 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.
> 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.
> 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.
>
> Conclusion
> ==========
>
> HTLCs allow creation of American Call Options.
> The same HTLCs are used in Lightning Network to route across channels.
> If using a single asset, there is no issue related to time.
> Regardless of the value of bitcoin relative to any other asset, in the future, 1 BTC is 1 BTC.
>
> However, across assets, the ability of HTLCs to create American Call Options becomes troublesome.
> These can then be exploited to earn money from exercise of the option.
> 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.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Tamas Blummer [ARCHIVE] /
npub1cc…ex8m8
2023-06-09 12:53:37
in reply to nevent1q…50s8
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8Published at
2023-06-09 12:53:37Event JSON
{
"id": "e5818a3b636bd1bf65402f374b9807e5f6f9ffc350f978a1d649e46aa509430b",
"pubkey": "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7",
"created_at": 1686315217,
"kind": 1,
"tags": [
[
"e",
"2cf0f173e79c61db5016952295d26d3125e7525cbe8bdec64d68f3c949e75a64",
"",
"root"
],
[
"e",
"084064b227bedb23da9d2b77b695c60fa19be26f5a629542dbc4a4f9c77f4cdf",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-12-27\n📝 Original message:\nZmnSCPxj,\n\nBrilliant reasoning. I sum it up to make it more accessible: \n\nFailing to route on purpose can be used to opt out of a previously agreed exchange of two differents assets.\nA rational actor will opt out if the exchange is no longer fair. Anyone who grants an option for free heads financial disaster.\n\nThis is not an issue for same asset exchange, as in payment routing, since the exchange remains fair at any later time point. \n\nAlthough 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. \nTherefore 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.\n\nTamas Blummer\n \n\n\u003e On Dec 27, 2018, at 06:43, ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network\n\u003e \n\u003e Introduction\n\u003e ============\n\u003e \n\u003e 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.\n\u003e However, a significant technical barrier prevents implementation of such feature as of current designs (late 2018) for Lightning.\n\u003e \n\u003e The root cause of this significant technical barrier is the use of hashlocked timelocked contracts to route payments.\n\u003e HTLCs can be used across cryptocurrency systems to transfer value between them.\n\u003e 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).\n\u003e 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.\n\u003e \n\u003e However, HTLCs can also be used to construct American Call Options.\n\u003e Further, due to UX concerns, on the Lightning Network, there is no cost incurred in merely setting up HTLCs for routing.\n\u003e By using the low-level HTLCs provided as primitives by Lightning Network, one can set up American Call Options.\n\u003e These on-Lightning American Call Options, however, can be \"purchased\" for free (gratis), thus potentially earning money in a completely risk-free manner.\n\u003e 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.\n\u003e \n\u003e Hashlocked Timelocked Contracts as American Call Options\n\u003e ========================================================\n\u003e \n\u003e An American CallOption is a right (but not obligation) to purchase an asset at a specific price, on or before an expiration date.\n\u003e HTLCs allow building American Call Options.\n\u003e \n\u003e Suppose we have Bitcoin, and some other asset, and both are on blockchains that support the same hash function and can define HTLCs.\n\u003e It is unimportant if both are on the same blockchain, or on different blockchains, since HTLCs can work across cryptocurrency systems.\n\u003e \n\u003e An American Call Option has these properties:\n\u003e \n\u003e 1. `P` = the price at which the asset can be purchased.\n\u003e 2. `E` = the date at which the option expires.\n\u003e \n\u003e Suppose I, ZmnSCPxj, wanted to sell you an American Call Option for 1 Widget (WJT) on the WJT blockchain.\n\u003e We would then do the below ritual:\n\u003e \n\u003e 1. You provide me a hash of some secret preimage that only you know.\n\u003e 2. You make an HTLC on the Bitcoin blockchain.\n\u003e The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day.\n\u003e 3. I make an HTLC on the WJT blockchain.\n\u003e The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`.\n\u003e \n\u003e On or before `E`, you can claim the WJT on the WJT blockchain by providing a transaction that reveals the preimage.\n\u003e Since the preimage is now revealed, I can then claim the Bitcoins of price `P` on the Bitcoin blockchain.\n\u003e 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.\n\u003e \n\u003e 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.\n\u003e 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.\n\u003e \n\u003e HTLCs For Routing\n\u003e =================\n\u003e \n\u003e HTLCs can be used to enforce trades across different cryptocurrency systems.\n\u003e This property is used to allow routing of payments across different channels.\n\u003e Each channel is its own cryptocurrency system.\n\u003e \n\u003e Suppose I, ZmnSCPxj, am an intermediate node on Lightning, and I wanted to sell you my service of facilitating payments on Lightning.\n\u003e Suppose you want to pay to somebody, who, for the sake of convenience, we shall randomly call YAIjbOJA.\n\u003e As it happens, I have a channel with you, and a channel with YAIjbOJa.\n\u003e \n\u003e You need to pay YAIjbOJA `P` bitcoins.\n\u003e We then perform the below ritual:\n\u003e \n\u003e 1. YAIjbOJA provides you a hash, whose preimage only YAIjbOJA knows.\n\u003e 2. On your channel with me, you set up an HTLC.\n\u003e 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.\n\u003e 3. On my channel with YAIjbOJA, I set up an HTLC.\n\u003e The value is `P`, the hash is the same hash as above, and the timelock is 1 day from now.\n\u003e \n\u003e (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)\n\u003e \n\u003e Afterward, YAIjbOJA may claim, or may not claim, the money in the HTLC by releasing (or not releasing) the hash to me.\n\u003e If YAIjbOJA claims the money, then I can take the hash and claim the money, plus fee, from you.\n\u003e If not, then this is a payment failure and I will then cancel the HTLC you offered using standard Lightning Network primitives.\n\u003e \n\u003e In general, we expect that YAIjbOJA wants to have the money because every randomly-generated imaginary entity likes money.\n\u003e 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.\n\u003e 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.\n\u003e \n\u003e This speed may mislead us into thinking that such convenience may be possible across different assets.\n\u003e \n\u003e Cross-Asset Lightning Nodes Offer Premium-Free American Call Options\n\u003e ====================================================================\n\u003e \n\u003e Suppose that Lightning Network supports multiple assets.\n\u003e Each channel has a single asset.\n\u003e 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.\n\u003e \n\u003e Suppose I advertise myself as such an exchange.\n\u003e Suppose you want to pay to YAIjbOJA for 1 WJT, but have no WJT on hand to pay YAIjbOJA, only bitcoins.\n\u003e As it happens, I have a bitcoin channel with you and a WJT channel with YAIjbOJA.\n\u003e I advertise myself as exchanging `P` bitcoins for 1 WJT as of the current time.\n\u003e \n\u003e Further suppose that in reality, YAIjbOJA is *you*, random Internet person reading my thoughts.\n\u003e \n\u003e You, your fake persona YAIjbOJA, and me, then perform the following ritual:\n\u003e \n\u003e 1. YAIjbOJA (really you) provides you with a hash whose preimage only YAIjbOJA (actually you) know. (i.e. you just make it up)\n\u003e 2. On the bitcoin channel with me, you set up an HTLC.\n\u003e 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.\n\u003e 3. On the WJT channel with YAIjbOJA (really you), I set up an HTLC.\n\u003e The value is 1 WJT, the hash is the hash you gave me, and the timelock is 1 day from now.\n\u003e \n\u003e The above is now the same as the setup for an American Call Option with expiration of 1 day from now.\n\u003e Further, within certain limits, you can set up the expiration of the American Call Option to be longer or shorter.\n\u003e 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.\n\u003e \n\u003e Suppose that the price of 1 WJT rises far above the price of `P`+1 bitcoins before the expiration (1 day from now).\n\u003e In such a case, \"YAIjbOJA\" (really you) will then release the hash and acquire the 1 WJT.\n\u003e You then close this channel and claim the WJT onchain, then sell it immediately to earn more than the `P`+1 bitcoins you paid.\n\u003e 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.\n\u003e \n\u003e Suppose that the price of WJT does not rise.\n\u003e Since this is an option and *not* a future, \"YAIjbOJA\" (really you) will simply claim that the payment errored somewhere and cancel the HTLCs.\n\u003e 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.\n\u003e \n\u003e Premium-free American Call Options Are Risk-free Earning Pumps\n\u003e ==============================================================\n\u003e \n\u003e Traditionally, options are analyzed assuming that the option itself has a price, the premium.\n\u003e This premium is the risk of the user of the option.\n\u003e If the user of the option does not exercise the option before the expiration, then the premium is a pure loss of the user.\n\u003e \n\u003e However, the above setup does not involve any payment when the option is not exercised.\n\u003e Payment failures are \"free\" (gratis) on the Lightning Network.\n\u003e 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.\n\u003e \n\u003e Because the American Call Option is premium-free, even if the expiration is very near, rational entities will still construct such options.\n\u003e Extreme volatility may occur in short time frames, especially in the realm of digital assets.\n\u003e \n\u003e 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.\n\u003e 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.\n\u003e \n\u003e We can try to mitigate this, but the solutions below all have significant drawbacks.\n\u003e \n\u003e 1. We could force that setting up the HTLCs requires payment.\n\u003e This forces the above American Call Options to have a premium.\n\u003e The effect, however, is that routing failure is not free.\n\u003e The current Lightning Network works despite not everyone publishing the balances of channels, precisely because routing failure is free.\n\u003e We only need to have one route succeed in order to actually successfully pay to the payee.\n\u003e With non-free routing failure, we cannot try many routes until one succeeds.\n\u003e * Suppose we limited this only to cross-asset exchanges.\n\u003e It would still require accurate knowledge of channel balances.\n\u003e 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.\n\u003e 2. Exchange nodes could increase their fees.\n\u003e This would create a wider \"spread\" of buying and selling assets.\n\u003e This spread would increase friction in crossing assets.\n\u003e Also, this would only reduce risk; if the exchange rate is volatile enough, then the option could still be exercised for riskless earnings.\n\u003e 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.\n\u003e 3. Exchange nodes could limit the timelock of cross-asset swaps.\n\u003e This would increase friction in crossing assets, since a timelock limit also imposes a limit to the route length.\n\u003e 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.\n\u003e 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.\n\u003e 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.\n\u003e \n\u003e Conclusion\n\u003e ==========\n\u003e \n\u003e HTLCs allow creation of American Call Options.\n\u003e The same HTLCs are used in Lightning Network to route across channels.\n\u003e If using a single asset, there is no issue related to time.\n\u003e Regardless of the value of bitcoin relative to any other asset, in the future, 1 BTC is 1 BTC.\n\u003e \n\u003e However, across assets, the ability of HTLCs to create American Call Options becomes troublesome.\n\u003e These can then be exploited to earn money from exercise of the option.\n\u003e Further, because Lightning UX would be degraded otherwise, payment failures are free (gratis), leading to the American Call Options also being free of premium.\n\u003e This means that creating such options would be riskless, allowing potential earnings upon any strong volatility of exchange rates.\n\u003e \n\u003e This implies that a multi-asset Lightning Network may not be economically viable.\n\u003e Instead, Lightning Network would strongly prefer having a single asset across the network.\n\u003e \n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "2d5830cee5b9c6d88d4a29b37fdad5f7e5d3c13e3e625fea169d6e36c487e62a208de0878c72eb4a63ddbfc879866c00e578f1b13752afa658e055ca73445fe4"
}