From laolu32 at gmail.com Mon Apr 11 18:59:16 2022 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 11 Apr 2022 14:59:16 -0400 Subject: [Lightning-dev] Taro: A Taproot Asset Representation Overlay In-Reply-To: <b24d9acc88dbeada62321eaf2ad9cc03@dtrt.org> References: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com> <b24d9acc88dbeada62321eaf2ad9cc03@dtrt.org> Message-ID: <CAO3Pvs-fVHmw1eZmTyn2LYXPJfXF=XHxd1nwOEgzAPcTkUZzTQ@mail.gmail.com> 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>