Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-02 📝 Original message: Hi John, > That said, I ...
📅 Original date posted:2022-05-02
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220502/d9b6768e/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220502/d9b6768e/attachment.html>;