rich1.0npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4rhttps://nostr.ae/npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4rnjumphttps://nostr.ae📅 Original date posted:2022-05-01 📝 Original message: For those who do not know me, I have been pioneering the concept of "tokens on Lightning" for roughly three years, first by researching Liquid, then by securing funding for RGB and assisting that project for roughly 2 years, then by researching and implementing OmniBOLT, etc, etc. I was pitching tokens on Lightning back when Ryan Gentry (LL bizdev) still worked at Multicoin Capital ;) My general thinking was that if LN could scale Bitcoin, it could scale tokens on Bitcoin too. I am very familiar with Bitcoin sidechains and Bitcoin-anchored token projects, and I think each has its own tradeoffs and arguments for existing. I could easily argue the benefits of Taro over Liquid, or Liquid over Taro, or Omni over Taro, or Taro over Omni, etc. In my estimation, there is no clear winner, and all of them could be obsoleted by future tech to come anyway. That said, I believe that the correct approach to supporting "tokens on Lightning" is to make it a separate concern from Taro, and that LL should create a separate BOLT proposal from the current Taro BIPs to ensure it LN standards have a genericized protocol that all LN implementations would be interested in supporting. Taro is not LN-native in any particular way, as it is simply a new design for using Taproot and M-sum trees to establish token abstractions on-chain. In practice, there is no such thing as issuing a token "on" Lightning, but instead the requirement to add several feature concepts to LN that would allow tokens to interact with LN nodes and LN routing: - Making LN nodes aware of assets on other networks - Establishing commitments for (atomic) swapping for payments/routing - Supporting the ability to exchange and advertise exchange rates for asset pairs - Supporting other multi-asset routes when considering routing paths, bridging nodes with alternate assets - ...probably other stuff :) So, I ask that Lightning Labs coordinate with the LN community to ensure such support for other networks and other assets not be dedicated only to Taro, and instead genericized enough so that other networks may compete fairly in the market, for the sake of Bitcoiners, and that LN standards by flexible enough to support future advances in token tech, other sidechains and Bitcoin layers like Omni, RGB, Rootstock, Liquid, 1WP sidechains, etc, etc. Otherwise, we will be left with LL's advantage being that LND supports Taro, and weird narratives that Taro is somehow superior because LND specifically added support for it, without creating a generic spec or BOLT that all nodes could adopt for multi-network, multi-asset LN-as-rails use cases. Finally, I want to state that I do not represent any specific token networks solutions, and our company has not finalized which token networks it will support. If you are trying to assume where my loyalties are, you will be wrong. I simply want *all* LN implementations and all current and future token solutions to get fair play and maximum interoperability. Thanks! -- John Carvalho CEO, Synonym.to <http://synonym.to/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220501/1f7ad737/attachment.html>