John Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-01 📝 Original message: For those who do not know ...
📅 Original date posted:2022-05-01
📝 Original message:
For those who do not know me, I have been pioneering the concept of "tokens
on Lightning" for roughly three years, first by researching Liquid, then by
securing funding for RGB and assisting that project for roughly 2 years,
then by researching and implementing OmniBOLT, etc, etc. I was pitching
tokens on Lightning back when Ryan Gentry (LL bizdev) still worked at
Multicoin Capital ;)
My general thinking was that if LN could scale Bitcoin, it could scale
tokens on Bitcoin too.
I am very familiar with Bitcoin sidechains and Bitcoin-anchored token
projects, and I think each has its own tradeoffs and arguments for
existing. I could easily argue the benefits of Taro over Liquid, or Liquid
over Taro, or Omni over Taro, or Taro over Omni, etc. In my estimation,
there is no clear winner, and all of them could be obsoleted by future tech
to come anyway.
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.
Taro is not LN-native in any particular way, as it is simply a new design
for using Taproot and M-sum trees to establish token abstractions on-chain.
In practice, there is no such thing as issuing a token "on" Lightning, but
instead the requirement to add several feature concepts to LN that would
allow tokens to interact with LN nodes and LN routing:
- 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
- ...probably other stuff :)
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, for the sake of Bitcoiners, and that LN standards by
flexible enough to support future advances in token tech, other sidechains
and Bitcoin layers like Omni, RGB, Rootstock, Liquid, 1WP sidechains, etc,
etc.
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.
Finally, I want to state that I do not represent any specific token
networks solutions, and our company has not finalized which token networks
it will support. If you are trying to assume where my loyalties are, you
will be wrong. I simply want *all* LN implementations and all current and
future token solutions to get fair play and maximum interoperability.
Thanks!
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220501/1f7ad737/attachment.html>;
📝 Original message:
For those who do not know me, I have been pioneering the concept of "tokens
on Lightning" for roughly three years, first by researching Liquid, then by
securing funding for RGB and assisting that project for roughly 2 years,
then by researching and implementing OmniBOLT, etc, etc. I was pitching
tokens on Lightning back when Ryan Gentry (LL bizdev) still worked at
Multicoin Capital ;)
My general thinking was that if LN could scale Bitcoin, it could scale
tokens on Bitcoin too.
I am very familiar with Bitcoin sidechains and Bitcoin-anchored token
projects, and I think each has its own tradeoffs and arguments for
existing. I could easily argue the benefits of Taro over Liquid, or Liquid
over Taro, or Omni over Taro, or Taro over Omni, etc. In my estimation,
there is no clear winner, and all of them could be obsoleted by future tech
to come anyway.
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.
Taro is not LN-native in any particular way, as it is simply a new design
for using Taproot and M-sum trees to establish token abstractions on-chain.
In practice, there is no such thing as issuing a token "on" Lightning, but
instead the requirement to add several feature concepts to LN that would
allow tokens to interact with LN nodes and LN routing:
- 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
- ...probably other stuff :)
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, for the sake of Bitcoiners, and that LN standards by
flexible enough to support future advances in token tech, other sidechains
and Bitcoin layers like Omni, RGB, Rootstock, Liquid, 1WP sidechains, etc,
etc.
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.
Finally, I want to state that I do not represent any specific token
networks solutions, and our company has not finalized which token networks
it will support. If you are trying to assume where my loyalties are, you
will be wrong. I simply want *all* LN implementations and all current and
future token solutions to get fair play and maximum interoperability.
Thanks!
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220501/1f7ad737/attachment.html>;