Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, You are right that an exchange can not simply embed the option into the offer price as there is no payment in case the offer is not taken, so nothing would pay for their hedging costs. This however is not a unique situation, but people deal with it frequently. Every offer has a timespan within which the market maker can not back out, and in your language writes a free option. That timespan might be very short on an electronic trading platform or rather long in trade finance. Bid-ask spreads of the offer reflect that and those making the offers manage or at least limit the market and liquidity risk of outstanding offers. Just because there is no trustless automated solution in sight, we should not assume things will not exist. In contrary, this imperfection will invite people offering a service for profit. Tamas Blummer > On Dec 28, 2018, at 22:22, Tamas Blummer wrote: > > Hi ZmnSCPxj, > > Making an asset swap offer using HTLC ties up funds and the offer may be > taken up-until the timelock expiry. > Therefore making such an offer implies both opportunity cost and a premium > for optional exercise. > > There is no mechanism in LN to require compensation for above costs, > therefore you imply that no sane person would make such an offer. > > I think, that instead exchanges will still make such offers but with an > exchange rate between the assets that compensate them for the cost they > incure by making the offer. > Exchanges will also limit the quantity of outstanding offers, so they can > manage the risk of options written. This might lead to making offers only to > known traders or to those, > who pay for receiving an offer with a regular LN payment in-advance. > > Tamas Blummer > > > >> On Dec 28, 2018, at 04:34, ZmnSCPxj wrote: >> >> Good morning Tamas, >> >>> 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. >> >> The option premium cannot be charged in the not-exercised branch. >> This is effectively a premium-free option. >> This means that rational entities who know of this technique will create >> options "for free" until the exchange runs out of liquidity. >> This is because, even if the exchange rate does not go beyond the bid-ask >> spread, the not-exercised branch is free of charge. >> >> Since all their liquidity is tied up in premium-free American Call Options, >> exchange nodes cannot usefully bridge between a BTC Lightning Network and >> any other asset. >> Routing attempts will usually fail. >> In a very practical sense, it would not be possible to create a multi-asset >> LN. >> >> >> -- >> >> I had long ago figured out that HTLCs can create American Call Options (more >> than a year ago). >> The problem was that they tied up the assets involved into the contract, so >> I never bothered to publish this insight. >> However, on LN, HTLCs are created "for free" with no payment, which is a >> significant advantage to the user of an American Call Option, who would be >> quite willing to tie up their funds in HTLCs since the not-exercised branch >> of the American Call Option formed was free of premium. >> Their only cost is opportunity cost, and on the LN, with tiny tiny tiny >> fees, opportunity cost of having the funds free is very small. >> One can say that the opportunity cost is the premium paid, but note that it >> is not paid to the exchange, since the exchange itself is also forced to tie >> up its other asset into another HTLC (meaning it also pays the opportunity >> cost). >> >> What I suspect will happen is that the LN on the weaker asset (i.e. less >> popular, fewer users, etc.) will find itself unable to be paid by the LN on >> the stronger asset. >> This will weaken the weaker asset even further (users will leave it for the >> stronger asset). >> This creates a shift in exchange rate, which is precisely what the American >> Call Options are waiting for. >> These American Call Options drain funds from the exchange, until the >> exchange stops being profitable and stops operating as an exchange, again >> further weakening the weaker asset as it is now even harder to pay from the >> stronger asset network to the weaker asset network, and so on. >> >> >> Regards, >> ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, Making an asset swap offer using HTLC ties up funds and the offer may be taken up-until the timelock expiry. Therefore making such an offer implies both opportunity cost and a premium for optional exercise. There is no mechanism in LN to require compensation for above costs, therefore you imply that no sane person would make such an offer. I think, that instead exchanges will still make such offers but with an exchange rate between the assets that compensate them for the cost they incure by making the offer. Exchanges will also limit the quantity of outstanding offers, so they can manage the risk of options written. This might lead to making offers only to known traders or to those, who pay for receiving an offer with a regular LN payment in-advance. Tamas Blummer > On Dec 28, 2018, at 04:34, ZmnSCPxj wrote: > > Good morning Tamas, > >> 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. > > The option premium cannot be charged in the not-exercised branch. > This is effectively a premium-free option. > This means that rational entities who know of this technique will create > options "for free" until the exchange runs out of liquidity. > This is because, even if the exchange rate does not go beyond the bid-ask > spread, the not-exercised branch is free of charge. > > Since all their liquidity is tied up in premium-free American Call Options, > exchange nodes cannot usefully bridge between a BTC Lightning Network and any > other asset. > Routing attempts will usually fail. > In a very practical sense, it would not be possible to create a multi-asset > LN. > > > -- > > I had long ago figured out that HTLCs can create American Call Options (more > than a year ago). > The problem was that they tied up the assets involved into the contract, so I > never bothered to publish this insight. > However, on LN, HTLCs are created "for free" with no payment, which is a > significant advantage to the user of an American Call Option, who would be > quite willing to tie up their funds in HTLCs since the not-exercised branch > of the American Call Option formed was free of premium. > Their only cost is opportunity cost, and on the LN, with tiny tiny tiny fees, > opportunity cost of having the funds free is very small. > One can say that the opportunity cost is the premium paid, but note that it > is not paid to the exchange, since the exchange itself is also forced to tie > up its other asset into another HTLC (meaning it also pays the opportunity > cost). > > What I suspect will happen is that the LN on the weaker asset (i.e. less > popular, fewer users, etc.) will find itself unable to be paid by the LN on > the stronger asset. > This will weaken the weaker asset even further (users will leave it for the > stronger asset). > This creates a shift in exchange rate, which is precisely what the American > Call Options are waiting for. > These American Call Options drain funds from the exchange, until the exchange > stops being profitable and stops operating as an exchange, again further > weakening the weaker asset as it is now even harder to pay from the stronger > asset network to the weaker asset network, and so on. > > > Regards, > ZmnSCPxj signature.asc Description: Message signed with OpenPGP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Good morning CJP, > > I think we've already addressed this issue before: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012 > 92.html > > and especially this proposal of me: > https://bitonic.nl/public/slowdown_prevention.pdf > > It's not completely trustless, but I tend to see trustlessness in a > very pragmatic sense anyway. Trust creates a risk, but if the > alternative trustless system is very impractical, and the risk is small > enough, the benefits might simply be worth the risks. Note that this is > a completely subjective trade-off, so it is only acceptable on an > individual, voluntary basis. Thank you very much your information! It seems to me "trust" is a five-letter word, so I am very hesitant to use it. I have only skimmed the paper thus far, so... 1. It seems to me that there is still friction here. RM, being a trusted third party, may very well charge as much as the market will bear. https://nakamotoinstitute.org/trusted-third-parties/ This seems to me to imply that OM (i.e. exchange nodes) will be unable to extract any sizable fee, i.e. any fees that the market would be willing to pay to exchange between assets will be taken by RM as rent, and not by the OM who actually makes the market exist in the first place. I worry this friction may be too much, so I am hesitant to support this, especially as trusted third parties have not behaved well historically, as per Szabo. However, if we can somehow make RM punishable for breaches in timing attacks, or some similar mechanism, then it may become workable. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, I think we've already addressed this issue before: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/0012 92.html and especially this proposal of me: https://bitonic.nl/public/slowdown_prevention.pdf It's not completely trustless, but I tend to see trustlessness in a very pragmatic sense anyway. Trust creates a risk, but if the alternative trustless system is very impractical, and the risk is small enough, the benefits might simply be worth the risks. Note that this is a completely subjective trade-off, so it is only acceptable on an individual, voluntary basis. CJP ZmnSCPxj via Lightning-dev schreef op do 27-12-2018 om 05:43 [+]: > 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 i
