Re: [Lightning-dev] Taro - Separating Taro concerns from LN token concerns
Good morning John, Thank you for clarifying. > Zman, > I was not arguing for moving things from the edge, nor was I arguing to make > Taro a BOLT. Laolu is misinterpreting my message. > I was explaining that the capabilities that would allow Taro to interact with > LN have no special relationship to Taro alone and should be designed to > accommodate any outside layer/network. > I gave specific examples of requirements that LL is portraying as Taro Layer > design, that are really just new features for LN nodes that do not need to be > network/layer-specific: > - 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 > I don't care whether this is framed as BOLT or BLIP content, as in the end > each implementation will do what it needs to stay relevant in the market. I > care that this is framed and designed correctly, so we aren't locked into one > specific outside layer. You could argue the degree to which the above > features need to exist in the network, and whether to restrict such features > to the "edge," but my point is that an LN node that wants to be aware of an > outside network, and extra assets in addition to Bitcoin, will need such > features, and such features are not Taro-specific. My understanding here of "the edge" vs "the core" is that the core is responsible for multi-hop routes and advertisements for channels. Thus the below: > - 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 ... would be considered part of "the core". Notwithstanding the previously linked objection against a multi-asset Lightning Network, we can discuss these as two topics: * Advertising exchange rates. * Routing between channels of different asset types. ### Advertising Exchange Rates Without changing the BOLT protocol, we can define a particular odd featurebit that cross-asset exchanges can set. Then, odd-numbered messages can be defined, such that I can ask that node: * What assets it has on what channels. * Exchange rates of each asset to Bitcoin in msats (to serve as a common exchange rate to allow conversion from any one asset to any other asset, specifying only N exchange rates instead of N^2). * We also need to spec out any rounding algorithm, in order to have the same calculation across implementations. BOLT is flexible enough that this does not need to be "blessed" until more than one LN implementation agrees on the new spec. ### Routing Between Channnels Of Different Asset Types I was the one who first suggested dropping the `realm` byte. Originally, `realm` was a 1-byte identifier for the asset type. However, I pointed out that `realm` was simultaneously too large and too small. * Too Large: We needed a byte in order to allow the new "TLV" thing to be used in routing onions. so that we could specify how many sections the TLV thing would take up, and we had already taken up all the space in a typical IP packet for the onion. * Too Small: If multi-asset actually materializes, it is hard to imagine that there would be only 255 of them (`realm = 0` was already for Bitcoin, so there were only 255 possible identifiers left). The idea in my mind basically was that instead of using the `realm` byte for identifying asset, we would instead add a new type for TLV, which would have 20 bytes. These 20 bytes would be, say, RIPEMD160 . SHA256 of the name of the asset. Odd TLV types are ignored, but individual onion layers are targeted to specific nodes anyway, so it should be safe to use an even TLV type instead for this. -- Again, note that this is a change in "the core" (and thus, pedantically, you *are* arguing for moving it from the edge, if you want these two items you specified). I personally think it dubious to consider, for the reason that I already linked to in the previous reply, but in any case, it is indeed possible to do. Generally, the path towards updating the BOLT is for at least one implementation to actually implement this, then convince at least one other implementation that this makes sense (possibly via this mailing list), and *then* maybe you have a chance of it getting into the BOLT spec. You may find it more useful to e.g. hire a freelancer to work on this for`lnd` and get it merged. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Taro - Separating Taro concerns from LN token concerns
Zman, I was not arguing for moving things from the edge, nor was I arguing to make Taro a BOLT. Laolu is misinterpreting my message. I was explaining that the capabilities that would allow Taro to interact with LN have no special relationship to Taro alone and should be designed to accommodate any outside layer/network. I gave specific examples of requirements that LL is portraying as Taro Layer design, that are really just new features for LN nodes that do not need to be network/layer-specific: - 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 I don't care whether this is framed as BOLT or BLIP content, as in the end each implementation will do what it needs to stay relevant in the market. I care that this is framed and designed correctly, so we aren't locked into one specific outside layer. You could argue the degree to which the above features need to exist in the network, and whether to restrict such features to the "edge," but my point is that an LN node that wants to be aware of an outside network, and extra assets in addition to Bitcoin, will need such features, and such features are not Taro-specific. Good morning John, and Laolu, > > > > 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). > > Adding on to this, the American Call Option problem that arises when using > H/PTLCs: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html > > The above objection seems to be one reason for proposing multi-asset "on > the edge" rather than have it widely deployed in the published Lightning > Network. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Taro - Separating Taro concerns from LN token concerns
Good morning John, and Laolu, > > 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). Adding on to this, the American Call Option problem that arises when using H/PTLCs: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html The above objection seems to be one reason for proposing multi-asset "on the edge" rather than have it widely deployed in the published Lightning Network. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Taro - Separating Taro concerns from LN token concerns
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.
