Good morning ZmnSCPxj, > I heard before that the RGB colored coin project had plans to be compatible > with Lightning so that channels could be denominated in an issued asset.
RGB will address lot of things but I was wondering if such things should exist in LN implementations by default. Example: If we had two ways to issue assets LA1 and LA2, the user can issue asset using a command: lightning-cli -named issueassets -type=LA1 -number=1000 > Blockstream I believe has plans to include support for Liquid-issued assets > in C-Lightning somehow; C-Lightning already supports running on top of Liquid > instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin > for the channel asset type) This is interesting. > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html Still trying to understand this problem and possible solutions. Interesting email though (TIL), thanks for sharing the link. Found related things explained Suredbits blog as well. -- Prayank A3B1 E430 2298 178F Oct 13, 2021, 09:29 by [email protected]: > Good morning Prayank, > >> Hello everyone, >> >> I wanted to know few things related to asset issuance on lightning: >> >> 1.Is it possible to issue assets on LN right now? If yes, what's the process >> and is it as easy as few commands in liquid: >> https://help.blockstream.com/hc/en-us/articles/900005127583-How-do-I-issue-an-asset-on-Liquid- >> >> 2.If no, is anyone working or planning to work on it? >> >> 3.I had read few things about Omni BOLT which could solve this problem but >> not sure about status of project and development: >> https://github.com/omnilaboratory/OmniBOLT-spec >> >> Few use cases for tokens on lightning: >> >> 1.DEX >> 2.Stablecoins >> 3.Liquidity: If projects could incentivize users with native tokens that are >> associated with the project on every LN channel opened it would improve >> liquidity. >> > > I heard before that the RGB colored coin project had plans to be compatible > with Lightning so that channels could be denominated in an issued asset. > > Most plans for colored coins on Lightning generally assume that each channel > has just a single asset, as that seems to be simpler, at least as a start. > However, this complicates the use of such channels for forwarding, as we > would like to restrict channel gossip to channels that *any* node can easily > prove actually exist as a UTXO onchain. > Thus, colored coins would need to somehow be provable as existing to *any* > node (or at least those that support colored coins somehow) on the LN. > > Blockstream I believe has plans to include support for Liquid-issued assets > in C-Lightning somehow; C-Lightning already supports running on top of Liquid > instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin > for the channel asset type). > > Generally, the assumption is that there would be a Lightning Network where > channels have different asset types, and you can forward via any channel, > suffering some kind of asset conversion fee if you have a hop where the > incoming asset is different from the outgoing asset. > > > However, do note that some years ago I pointed out that swaps between two > *different* assets are a form of very lousy American Call Option: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html > > Due to this, issued assets may not be usable on Lightning after all, even if > someone makes the work to make non-Bitcoin assets on Lightning channels. > > I am unaware of any actual decent solutions to the American Call Option > problem, but it has been a few years since then and someone might have come > up with a solution by now (we hope, maybe). > I believe CJP had a trust-requiring solution: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html > and https://bitonic.nl/public/slowdown_prevention.pdf > Here is a paper which requires Ethereum (I have not read it because it > required Ethereum): https://eprint.iacr.org/2019/896.pdf > > It may be possible to use Barrier Escrows: > https://suredbits.com/payment-points-implementing-barrier-escrows/ > Barrier Escrows are still trusted (and I think they can serve as the RM role > in the CJP paper?) to operate correctly, but the exact use of their service > is blinded to them. > Of course, any single participant of a multi-participant protocol can > probably unblind the Barrier Escrow, so still not a perfectly trustless > solution. > > > > Regards, > ZmnSCPxj >
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
