Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-11 📝 Original message: Hi Harding, Great ...
📅 Original date posted:2022-04-11
📝 Original message:
Hi Harding,
Great questions!
> 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 know several attempts at mitigation have previously been discussed on
> this list, such as barrier escrows[5], so I'm curious whether it's your
> plan to use one of those existing mitigations, suggest a new mitigation,
> or just not worry about it at this point (as Blummer mentioned, it
> probably doesn't matter for swaps where price volatility is lower than fee
> income).
I'd say our current plan is a combination of not worry about it at this
point, rely on proper pricing of the spread/fee-rate that exists at the
first/last mile, and potentially introducing an upfront payment as well if
issues pop up (precise option pricing would need to be worked out still).
One side benefit of introducing this upfront payment at the edges (the idea
is that the asset channels are all private chans from the LN perfective, so
a hophint/blinded path is needed to route to them), is that it presents a
controlled experiment where we can toy with the mechanics of such upfront
payment proposals (which are a lot simpler since there's just one hop to
factor in).
Another difference here vs past attempts/proposals is that since all the
assets are at the edges, identifying a party creating long lived HTLCs that
cross an asset boundary is much simpler: the origin party is likely the one
sending those payments. This makes it easier to detect abuse and stop
forwarding those HTLCs (or close the channel) as unlike the prior
generalized LN-DEX ideas, the origin will always be that first hop.
I think another open question was exactly how a nuisance party would take
advantage of this opportunity:
* Do they close out the channel and instead go to a traditional exchange
to make that arbitrage trade? What guarantee do they have that their
deposit gets there in time and they're able to profit.
* Do they instead attempt to re-route the swap to use some other market
maker elsewhere in the network? In this case, won't things just recurse
with each party in the chain attempting to exploit the arbitrage trade?
IMO as long as the spread/fees make sense at the last/first mile, then the
parties are inactivated to carry out the transfers as they have more
certainty w.r.t revenues from the fees vs needing to reply on an arbitrage
trade that may or may not exist when they go to actually exploit it.
> I'd also be curious to learn what you and others on this list think will
> be different about using Taro versus other attempts to get LN channels to
> cross assets, e.g. allowing payments to be routed from a BTC-based channel
> to a Liquid-BTC-based channel through an LN bridge node. I believe a fair
> amount of work in LN's early design and implementation was aimed at
> allowing cross-chain transfers but either because of the complexity, the
> free call option problem, or some other problem, it seemed to me that work
> on the problem was largely abandoned.
I think the main difference with our approach is that the LN Bitcoin
Backbone won't explicitly be aware of the existence of any of the assets. As
a result, we won't need core changes to the channel_update method, nor a
global value carved out in the "realm" field (instead w/ the scid alias
feature that can be used to identify which channel should be used to
complete the route), which was meant to be used to identify public LN routes
that crossed chains.
One other difference with our approach is that given all the assets are
presented on Bitcoin itself, we don't need to worry about things like the
other chain being down, translating time lock values, navigating forks
across several chains, etc. As a result, the software can be a lot simpler,
as everything is anchored in the Bitcoin chain, and we don't actually need
to build in N different wallets which would really blow up the complexity.
I think most of the other attempts were also focused on being able to
emulate DEX-like functionality over the network. In contrast, we're
concerned mainly with payments, though I can see others attempting to tackle
building out an off-chain DEX systems with this new protocol base.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220411/d3217ae4/attachment.html>;
📝 Original message:
Hi Harding,
Great questions!
> 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 know several attempts at mitigation have previously been discussed on
> this list, such as barrier escrows[5], so I'm curious whether it's your
> plan to use one of those existing mitigations, suggest a new mitigation,
> or just not worry about it at this point (as Blummer mentioned, it
> probably doesn't matter for swaps where price volatility is lower than fee
> income).
I'd say our current plan is a combination of not worry about it at this
point, rely on proper pricing of the spread/fee-rate that exists at the
first/last mile, and potentially introducing an upfront payment as well if
issues pop up (precise option pricing would need to be worked out still).
One side benefit of introducing this upfront payment at the edges (the idea
is that the asset channels are all private chans from the LN perfective, so
a hophint/blinded path is needed to route to them), is that it presents a
controlled experiment where we can toy with the mechanics of such upfront
payment proposals (which are a lot simpler since there's just one hop to
factor in).
Another difference here vs past attempts/proposals is that since all the
assets are at the edges, identifying a party creating long lived HTLCs that
cross an asset boundary is much simpler: the origin party is likely the one
sending those payments. This makes it easier to detect abuse and stop
forwarding those HTLCs (or close the channel) as unlike the prior
generalized LN-DEX ideas, the origin will always be that first hop.
I think another open question was exactly how a nuisance party would take
advantage of this opportunity:
* Do they close out the channel and instead go to a traditional exchange
to make that arbitrage trade? What guarantee do they have that their
deposit gets there in time and they're able to profit.
* Do they instead attempt to re-route the swap to use some other market
maker elsewhere in the network? In this case, won't things just recurse
with each party in the chain attempting to exploit the arbitrage trade?
IMO as long as the spread/fees make sense at the last/first mile, then the
parties are inactivated to carry out the transfers as they have more
certainty w.r.t revenues from the fees vs needing to reply on an arbitrage
trade that may or may not exist when they go to actually exploit it.
> I'd also be curious to learn what you and others on this list think will
> be different about using Taro versus other attempts to get LN channels to
> cross assets, e.g. allowing payments to be routed from a BTC-based channel
> to a Liquid-BTC-based channel through an LN bridge node. I believe a fair
> amount of work in LN's early design and implementation was aimed at
> allowing cross-chain transfers but either because of the complexity, the
> free call option problem, or some other problem, it seemed to me that work
> on the problem was largely abandoned.
I think the main difference with our approach is that the LN Bitcoin
Backbone won't explicitly be aware of the existence of any of the assets. As
a result, we won't need core changes to the channel_update method, nor a
global value carved out in the "realm" field (instead w/ the scid alias
feature that can be used to identify which channel should be used to
complete the route), which was meant to be used to identify public LN routes
that crossed chains.
One other difference with our approach is that given all the assets are
presented on Bitcoin itself, we don't need to worry about things like the
other chain being down, translating time lock values, navigating forks
across several chains, etc. As a result, the software can be a lot simpler,
as everything is anchored in the Bitcoin chain, and we don't actually need
to build in N different wallets which would really blow up the complexity.
I think most of the other attempts were also focused on being able to
emulate DEX-like functionality over the network. In contrast, we're
concerned mainly with payments, though I can see others attempting to tackle
building out an off-chain DEX systems with this new protocol base.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220411/d3217ae4/attachment.html>;