Taro: A Taproot Asset Representation Overlay



Summary:

The email thread discusses the "free call option" problem in transferring fungible assets via asset-aware LN endpoints and how implementing support for it can mitigate the issue. It is noted that the problem doesn't exist for transfers using the same asset. Several attempts at mitigation have been discussed, including barrier escrows, but the current plan is to 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 arise. The use of upfront payment presents a controlled experiment where the mechanics of such proposals can be toyed with. Since all assets are at the edges, identifying a party creating long-lived HTLCs that cross an asset boundary is much simpler than prior generalized LN-DEX ideas. The email also discusses the difference between using Taro and other attempts to get LN channels to cross assets. The main difference with the approach is that the LN Bitcoin Backbone won't explicitly be aware of the existence of any of the assets. Therefore, there won't be core changes to the channel_update method nor a global value carved out in the "realm" field. Another difference is that given all the assets are presented on Bitcoin itself, there's no 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 there's no need to build in N different wallets which would increase complexity. Finally, the group is concerned mainly with payments, though others may attempt to tackle building out an off-chain DEX system with this new protocol base.


Updated on: 2023-06-03T08:15:08.863846+00:00