John Carvalho [ARCHIVE] on Nostr: ð Original date posted:2022-05-03 ð Original message: Zman, I was not arguing ...
ð
Original date posted:2022-05-03
ð Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220503/d3b236c6/attachment-0001.html>;
ð Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220503/d3b236c6/attachment-0001.html>;