[Lightning-dev] An Argument For Single-Asset Lightning Network

James Asefa jamesasefa at gmail.com
Thu Dec 27 22:33:43 UTC 2018


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.

This obviously can't scale to all participants, but can possibly provide a
hedge for a single node.

On Thu, Dec 27, 2018 at 1:33 PM Tamas Blummer <tamas.blummer at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181227/f5c23e96/attachment-0001.html>


More information about the Lightning-dev mailing list