Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-06 🗒️ Summary of this message: A potential ...
📅 Original date posted:2023-02-06
🗒️ Summary of this message: A potential issue with Lightning Network's asset-aware endpoints is the "free call option" problem, where a node can hold up a payment to profit from price fluctuations. This is more of an issue with assets of high volatility.
📝 Original message:
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
🗒️ Summary of this message: A potential issue with Lightning Network's asset-aware endpoints is the "free call option" problem, where a node can hold up a payment to profit from price fluctuations. This is more of an issue with assets of high volatility.
📝 Original message:
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