From: Olaoluwa Osuntokun <laolu32@gmail•com>
To: Alex Schoof <alex.schoof@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
Date: Fri, 8 Apr 2022 13:49:28 -0400 [thread overview]
Message-ID: <CAO3Pvs-NU04doUd1LbmjBXz1TKKfN_8WLrBtpe0WS6hbOj5rFQ@mail.gmail.com> (raw)
In-Reply-To: <CA+2b5C058bdGfqB9uzSHkv3Q4=mC=fRdNJAuxErkXfKF2X-Siw@mail.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 --]
next prev parent reply other threads:[~2022-04-08 17:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 15:06 [bitcoin-dev] " Olaoluwa Osuntokun
2022-04-07 17:14 ` Ruben Somsen
2022-04-07 19:11 ` [bitcoin-dev] [Lightning-dev] " Alex Schoof
2022-04-08 17:49 ` Olaoluwa Osuntokun [this message]
2022-04-08 17:48 ` [bitcoin-dev] " Olaoluwa Osuntokun
2022-04-10 16:51 ` Ruben Somsen
2022-04-11 19:51 ` Olaoluwa Osuntokun
2022-04-15 13:14 ` Ruben Somsen
2022-11-03 9:26 ` [bitcoin-dev] [Lightning-dev] " Johan Torås Halseth
2022-11-05 0:35 ` Olaoluwa Osuntokun
2022-11-07 13:51 ` Johan Torås Halseth
2022-04-16 2:43 ` [bitcoin-dev] " Olaoluwa Osuntokun
[not found] ` <CAO6oAq2nC9_0GdoOQbmX3Qt4OsSYzMVBy-vyGczwn1GhLHN2Kw@mail.gmail.com>
2022-10-19 2:40 ` [bitcoin-dev] [Lightning-dev] " Olaoluwa Osuntokun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAO3Pvs-NU04doUd1LbmjBXz1TKKfN_8WLrBtpe0WS6hbOj5rFQ@mail.gmail.com \
--to=laolu32@gmail$(echo .)com \
--cc=alex.schoof@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox