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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
