Hi John, > 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.
The current Taro BIPs describe just about everything needed in order to create, validate, and interact with assets on chain. Naturally, the system needs to exist on-chain before any off-chain constructs can be built on top of it. On the topic of a BOLT, I don't think something like Taro (particularly our vision for the deployment path) should exist at the _BOLT level_. Instead, we aim to create a bLIP that fully specifies the _optional_ series of TLV extensions needed to open channels using Taro assets, and send them off-chain. IMO this isn't something that needs to be a BOLT as: it isn't intended to be 100% universal (most LN routing nodes and users will only know of the core bitcoin backbone), isn't critical to the operation of the core LN network, and it's something that will only initial be deployed at the edges (sender+receiver). On the BOLT side, there're a number of important upgrades/extensions being proposed, and imo it doesn't make sense to attempt to soak up the already scarce review bandwidth into something like Taro that will live purely at the edges of the network. I also don't want to speak for the other LN devs, but I think most would prefer to just focus on the core LN protocol and ignore anything non-bitcoin on the sides. The implementations/developers that think this is something worth implementing will be able to contribute to and review the bLIPs as they wish. A few implementations support LTC today, but that was mainly an exercise in helping to build consensus for segwit so we could ultimately deploy LN on Bitcoin's mainnet (iirc some implementations are in the process of even removing support). A prior version of the onion payload (now called the legacy payload) had a "realm" field that was intended to be used for multi-chain stuff. The newer modern TLV payload dropped that field as it wasn't being used anywhere. IMO that was the right move as it allows us to keep the core protocol simple and let other ppl be concerned w/ building multi-asset stuff on top of the base protocol. > but instead the requirement to add several feature concepts to LN that > would allow tokens to interact with LN nodes and LN routing: >From this list of items, I gather that your vision is actually pretty different from ours. Rather than update the core network to understand the existence of the various Taro assets, instead we plan on leaving the core protocol essentially unchanged, with the addition of new TLV extensions to allow the edges to be aware of and interact w/ the Taro assets. As an example, we wouldn't need to do anything like advertise exchange rates in the core network over the existing gossip protocol (which doesn't seem like the best idea in any case given how quickly they can change and the existing challenges we have today in ensuring speedy update propagation). > 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, If you're eager to create a generalized series of extensions to enable your vision, then of course you're welcome to pursue that. However, I don't think the other LN developers will really care much about building some generalized multi-chain/multi-asset system given all the existing work we still need to do to make sure the bitcoin backbone works properly and can scale up sufficiently. I'd also caution you against making the same mistakes that Interledger did: they set out to build a generalized off-chain system which abstracts over the assets/chains entirely, but years later, and several hundred wc3 mailing list posts later, virtually nothing uses it. Why? IMO, because it was overly generalized and they assumed that if they built it, the entities that actually needed it would magically pop up (spoiler alert -- *SpongeBob narrator voice*: several years later, they didn't). > 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. Given that all the specs so far are in the open, and we opted to first build out the specifications before releasing our own implementation, I don't foresee Taro being something that only LL or lnd implements. All the BIPs are public, and the bLIP will be soon as well, so any motivated individual or set of individuals will also be able to implement and adopt the protocol. If you or anyone else reading this is interested in contributing: I'm accepting PRs to my fork of the BIP repo [1] (where I've already made several modifications based on feedback from the wider community, and merged a few PRs as well), and I'm also hanging out on IRC at ##taro on Libera. [1]: https://github.com/Roasbeef/bips/tree/bip-taro -- Laolu
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
