{"type":"rich","version":"1.0","author_name":"npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","author_url":"https://nostr.ae/npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-01\n📝 Original message:\nFor those who do not know me, I have been pioneering the concept of \"tokens\non Lightning\" for roughly three years, first by researching Liquid, then by\nsecuring funding for RGB and assisting that project for roughly 2 years,\nthen by researching and implementing OmniBOLT, etc, etc. I was pitching\ntokens on Lightning back when Ryan Gentry (LL bizdev) still worked at\nMulticoin Capital ;)\n\nMy general thinking was that if LN could scale Bitcoin, it could scale\ntokens on Bitcoin too.\n\nI am very familiar with Bitcoin sidechains and Bitcoin-anchored token\nprojects, and I think each has its own tradeoffs and arguments for\nexisting. I could easily argue the benefits of Taro over Liquid, or Liquid\nover Taro, or Omni over Taro, or Taro over Omni, etc. In my estimation,\nthere is no clear winner, and all of them could be obsoleted by future tech\nto come anyway.\n\nThat said, I believe that the correct approach to supporting \"tokens on\nLightning\" is to make it a separate concern from Taro, and that LL should\ncreate a separate BOLT proposal from the current Taro BIPs to ensure it LN\nstandards have a genericized protocol that all LN implementations would be\ninterested in supporting.\n\nTaro is not LN-native in any particular way, as it is simply a new design\nfor using Taproot and M-sum trees to establish token abstractions on-chain.\nIn practice, there is no such thing as issuing a token \"on\" Lightning, but\ninstead the requirement to add several feature concepts to LN that would\nallow tokens to interact with LN nodes and LN routing:\n\n - Making LN nodes aware of assets on other networks\n - Establishing commitments for (atomic) swapping for payments/routing\n - Supporting the ability to exchange and advertise exchange rates for\nasset pairs\n - Supporting other multi-asset routes when considering routing paths,\nbridging nodes with alternate assets\n - ...probably other stuff :)\n\nSo, I ask that Lightning Labs coordinate with the LN community to ensure\nsuch support for other networks and other assets not be dedicated only to\nTaro, and instead genericized enough so that other networks may compete\nfairly in the market, for the sake of Bitcoiners, and that LN standards by\nflexible enough to support future advances in token tech, other sidechains\nand Bitcoin layers like Omni, RGB, Rootstock, Liquid, 1WP sidechains, etc,\netc.\n\nOtherwise, we will be left with LL's advantage being that LND supports\nTaro, and weird narratives that Taro is somehow superior because LND\nspecifically added support for it, without creating a generic spec or BOLT\nthat all nodes could adopt for multi-network, multi-asset LN-as-rails use\ncases.\n\nFinally, I want to state that I do not represent any specific token\nnetworks solutions, and our company has not finalized which token networks\nit will support. If you are trying to assume where my loyalties are, you\nwill be wrong. I simply want *all* LN implementations and all current and\nfuture token solutions to get fair play and maximum interoperability.\n\nThanks!\n\n--\nJohn Carvalho\nCEO, Synonym.to \u003chttp://synonym.to/\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220501/1f7ad737/attachment.html\u003e"}