On Mon, Apr 11, 2022 at 02:59:16PM -0400, Olaoluwa Osuntokun wrote: Thread necromancy, but hey.
> > anything about Taro or the way you plan to implement support for > > transferring fungible assets via asset-aware LN endpoints[1] will address > > the "free call option" problem, which I think was first discussed on this > > list by Corné Plooy[2] and was later extended by ZmnSCPxj[3], with Tamas > > Blummer[4] providing the following summary > > I agree w/ Tamas' quote there in that the problem doesn't exist for > transfers using the same asset. Consider a case of Alice sending to Bob, > with both of them using a hypothetical asset, USD-beef: if the final/last > hop withholds the HTLC, then they risk Bob not accepting the HTLC either due > to the payment timing out, or exchange rate fluctuations resulting in an > insufficient amount delivered to the destination (Bob wanted 10 USD-beef, > but the bound BTC in the onion route is only now 9 USD-beef), in either case > the payment would be cancelled. I don't think this defense actually works. If you have: Alice -> Bob -> Carol -> Dave -> Elizabeth with Alice/Bob and Dave/Elizabeth having USD channels, but Bob/Carol and Carol/Dave being BTC channels, then Dave has a reasonable opportunity to cheat: - he can be pretty confident that Elizabeth is the final recipient (since USD is meant to be at the edges, and this is a BTC to USD conversion) - he knows the expected USD value of the payment to Elizabeth - he knows what the on-chain timeout of the USD payment to Elizabeth will be, because he shares the channel, so can likely be confident Elizabeth won't cancel the tx as long as he forwards it to her by then - he can hold up the outbound USD payment while holding onto the inbound BTC payment, only forwarding the payment on to Elizabeth if the price of BTC stays the same or increases. I'm not an expert, but I tried a Black Scholes calculator with an estimate for Bitcoin's volatility, and it suggests that the fair price of an option like that that lasts an hour is about 0.3% of the par value (ie, for a $1000 payment, the ability to hold up the BTC/USD conversion for an hour and only do it when it's profitable, is worth about $3). That seems substantial compared to normal lightning fee rates, which I think are often in the 0.01% to 0.1% range? (Note that this way of analysing the free option problem means it's only an issue when the two assets have high volatility -- if they're sufficiently correlated, like USDT and USDC, or perhaps even USD and EUR, then the value of the free option is minimised, perhaps to the point where it's not worth trying to exploit) Bob may have a similar ability to interfere with the payment, but is much more constrained: he probably doesn't know Elizabeth's timeout; and if he's making a profit because the price of BTC has gone down, then Dave is likely to cancel the transaction rather than forwarding it to Elizabeth, since he'd be making a lock when converting the BTC amount to its pre-drop USD value. However, if there wasn't a followup conversion back from BTC to USD, and Bill was willing to guess at the final timeout of the payment, he could still make a profit from delaying payments. (Though it's also less harmful here: only the Alice/Bob funds are being held up indefinitely, not the funds from random channels) I think maybe a better approach might be: Alice -> Bob -BTC-> Carol -BTC-> Elizabeth -BTC-> Dave -USD-> Elizabeth That is, Alice sends $100 to Bob who forwards 0.004 BTC (or whatever) to Carol and then Elizabeth; then, before accepting the payment, Elizabeth extends the path with a BTC/USD exchange with Dave via a short loop. If Dave doesn't immediately forward the USD to Elizabeth, she can cancel the transaction, refunding Carol all the way back to Alice, even while waiting for Dave. She doesn't need to be concerned that Dave could claim funds from her, as all the transfers are conditional on a secret only Elizabeth knows, and that she has not yet revealed. If Dave tries exploiting the free option, Elizabeth can see he doesn't reliably finish the loop quickly, and try finding another, better, exchange. That approach also means Alice doesn't need to know what Elizabeth's currency preference is; she's just sending BTC, so she only needs to know about the exchange rate between BTC and her own currency, which seems like it means there's one less thing that could go wrong. Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
