ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-02 📝 Original message: Good morning John, and ...
📅 Original date posted:2022-05-02
📝 Original message:
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
📝 Original message:
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