(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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
