Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay

[Olaoluwa Osuntokun <laolu32@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4474 bytes --]

(this might be a double post as I ran into the size limit)

Hi Alex,

Thanks for taking a look at things!

> If that's the case, did you look at other mechanisms to commit to a merkle
> root? For example, I believe mainstay[1] uses a
> pay-to-contract/bip175[2]-like scheme to commit sidechain merkle roots to
> p2pkh/p2sh addresses with signature tweaks. Are there other interesting
> (to taro) spend-paths that need to be allowed that led to the taproot
> script tree being particularly helpful?

I considered other approaches, but by relying on the existing taproot
commitment structure/derivation, Taro implementations are able to re-use
surrounding code/libraries, making a core implementation more compact.
Committing into the tapscript tree is also simpler than signature tweaks.
One nice trait about using the tapscript tree is that from a wallet's
perceptive, Taro just wants a particular opaque hash to be included in the
final tapscript tree. As a result, the wallet doesn't need to modify the way
they sign, or do key derivations or anything. In addition, using the
tapscript tree lets us separate the Bitcoin layer from the Taro layer as far
as scripts, and also enables easily verification of any sort of Script
mirroring between the layers that may be required for certain applications.

> This reminds me a lot of single-use-seals[3]. Is that the right way to
> think about what's going on here?

Yes a similar construct is used. I personally don't really like the
single-use-seals terminology, as I find it somewhat obtuse and trying to
bind the mechanics to the analogy/metaphor just makes it harder for people
to understand what's going on.

> If it is, then it looks like a Universe/Multiverse is an
> offload/aggregation mechanism that can keep track of asset lineages on
> behalf of users, which would be useful for light clients of heavily-used
> asset types (so your mobile client doesnt have to traverse the transfer
> lineage of some high-liquidity stablecoin or something).

So the provide a few different types of functionality:

 * A way to bootstrap genesis output provenance by maintaining a Universe
   which is just the set of asset issuance transactions (the Universe
MS-SMT is
   keyed by a prevOut at the lowest level). This can be done for several
   assets.

 * A way to collect+index a more complete view of the set of transfers
   related to assets. This can serve the basis for things like a block
   explorer for a single or several assets. Since the data structure is
   history independent, multiple explorers can publish their root hash which
   makes it easy to check that they have the same data, and a bisection
   protocol can be used to sync up distinct universe/multiverse instances.

 * A way to allow aggregation of transfers tied to a single to level UTXO
   chain, which would likely be used in cases like games where the actual
   game needs other servers or closed source functionality, but the game
   publisher wants the users to be able to prove ownership and also trade in
   game asset. This can be maintained by a single party, or a
   threshold/federation. The parties can't include invalid state transitions
   or proofs (can't forge the proper signature, etc).

> - There's been a lot of talk lately on the bitcoin-dev list about
> covenants, and I wonder if some of those designs (specifically TLUV or
> CTV) might be useful with Taro, to "lift" some of the taro conditions into
> covenants that encumber the underlying bitcoin. I don't have a design or
> anything, wondering if you've given this any thought.

Yep! I described a sketch of something like that using TLVU in my prior
reply to Rubin. At a high level, since Taro affect the tapscript root hash,
which affects the output key, by requiring a certain output key, or swapping
out the leaf elements, a covenant can further bind Taro rules without
needing to explicitly do validation/execution in Bitcoin script itself.

> My first thought was to have the "carrier utxo" for a taro asset be really
> small, like dust + some buffer.

Hmm, can you describe this in more detail? Do you mean an _extra_ UTXO, or
just mapping the Taro conditions as much as possible to the top-level
Bitcoin scripts?

> - was this originally named CMYK?

Maybe ;), a few versions were floating around before I published the current
draft, so some prior artifacts may still be floating around. Will do another
sweep to clean up anything else that was lingering.

-- Laolu

[-- Attachment #2: Type: text/html, Size: 4941 bytes --]