{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-02\n📝 Original message:\nHi John,\n\n\u003e That said, I believe that the correct approach to supporting \"tokens on\n\u003e Lightning\" is to make it a separate concern from Taro, and that LL should\n\u003e create a separate BOLT proposal from the current Taro BIPs to ensure it LN\n\u003e standards have a genericized protocol that all LN implementations would be\n\u003e interested in supporting.\n\nThe current Taro BIPs describe just about everything needed in order to\ncreate, validate, and interact with assets on chain. Naturally, the system\nneeds to exist on-chain before any off-chain constructs can be built on top\nof it.\n\nOn the topic of a BOLT, I don't think something like Taro (particularly our\nvision for the deployment path) should exist at the _BOLT level_. Instead,\nwe aim to create a bLIP that fully specifies the _optional_ series of TLV\nextensions needed to open channels using Taro assets, and send them\noff-chain. IMO this isn't something that needs to be a BOLT as: it isn't\nintended to be 100% universal (most LN routing nodes and users will only\nknow of the core bitcoin backbone), isn't critical to the operation of the\ncore LN network, and it's something that will only initial be deployed at\nthe edges (sender+receiver).\n\nOn the BOLT side, there're a number of important upgrades/extensions being\nproposed, and imo it doesn't make sense to attempt to soak up the already\nscarce review bandwidth into something like Taro that will live purely at\nthe edges of the network. I also don't want to speak for the other LN devs,\nbut I think most would prefer to just focus on the core LN protocol and\nignore anything non-bitcoin on the sides. The implementations/developers\nthat think this is something worth implementing will be able to contribute\nto and review the bLIPs as they wish.\n\nA few implementations support LTC today, but that was mainly an exercise in\nhelping to build consensus for segwit so we could ultimately deploy LN on\nBitcoin's mainnet (iirc some implementations are in the process of even\nremoving support).  A prior version of the onion payload (now called the\nlegacy payload) had a \"realm\" field that was intended to be used for\nmulti-chain stuff. The newer modern TLV payload dropped that field as it\nwasn't being used anywhere.  IMO that was the right move as it allows us to\nkeep the core protocol simple and let other ppl be concerned w/ building\nmulti-asset stuff on top of the base protocol.\n\n\u003e but instead the requirement to add several feature concepts to LN that\n\u003e would allow tokens to interact with LN nodes and LN routing:\n\n\u003eFrom this list of items, I gather that your vision is actually pretty\ndifferent from ours. Rather than update the core network to understand the\nexistence of the various Taro assets, instead we plan on leaving the core\nprotocol essentially unchanged, with the addition of new TLV extensions to\nallow the edges to be aware of and interact w/ the Taro assets. As an\nexample, we wouldn't need to do anything like advertise exchange rates in\nthe core network over the existing gossip protocol (which doesn't seem like\nthe best idea in any case given how quickly they can change and the existing\nchallenges we have today in ensuring speedy update propagation).\n\n\u003e So, I ask that Lightning Labs coordinate with the LN community to ensure\n\u003e such support for other networks and other assets not be dedicated only to\n\u003e Taro, and instead genericized enough so that other networks may compete\n\u003e fairly in the market,\n\nIf you're eager to create a generalized series of extensions to enable your\nvision, then of course you're welcome to pursue that. However, I don't think\nthe other LN developers will really care much about building some\ngeneralized multi-chain/multi-asset system given all the existing work we\nstill need to do to make sure the bitcoin backbone works properly and can\nscale up sufficiently. I'd also caution you against making the same mistakes\nthat Interledger did: they set out to build a generalized off-chain system\nwhich abstracts over the assets/chains entirely, but years later, and\nseveral hundred wc3 mailing list posts later, virtually nothing uses it.\nWhy? IMO, because it was overly generalized and they assumed that if they\nbuilt it, the entities that actually needed it would magically pop up\n(spoiler alert -- *SpongeBob narrator voice*: several years later, they\ndidn't).\n\n\u003e Otherwise, we will be left with LL's advantage being that LND supports\n\u003e Taro, and weird narratives that Taro is somehow superior because LND\n\u003e specifically added support for it, without creating a generic spec or BOLT\n\u003e that all nodes could adopt for multi-network, multi-asset LN-as-rails use\n\u003e cases.\n\nGiven that all the specs so far are in the open, and we opted to first build\nout the specifications before releasing our own implementation, I don't\nforesee Taro being something that only LL or lnd implements. All the BIPs\nare public, and the bLIP will be soon as well, so any motivated individual\nor set of individuals will also be able to implement and adopt the protocol.\nIf you or anyone else reading this is interested in contributing: I'm\naccepting PRs to my fork of the BIP repo [1] (where I've already made\nseveral modifications based on feedback from the wider community, and merged\na few PRs as well), and I'm also hanging out on IRC at ##taro on Libera.\n\n[1]: https://github.com/Roasbeef/bips/tree/bip-taro\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220502/d9b6768e/attachment.html\u003e"}