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
