Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9863C002C for ; Fri, 8 Apr 2022 17:49:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 981F060B1D for ; Fri, 8 Apr 2022 17:49:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJNE04oywpOt for ; Fri, 8 Apr 2022 17:49:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by smtp3.osuosl.org (Postfix) with ESMTPS id 85A43605AD for ; Fri, 8 Apr 2022 17:49:41 +0000 (UTC) Received: by mail-wm1-x329.google.com with SMTP id v20-20020a05600c15d400b0038e9a88aee7so2933768wmf.3 for ; Fri, 08 Apr 2022 10:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vS3EwHGyVQ1ui/XRQLqSt8If+1+oxvv9zuwx32hDFq4=; b=CpHgKCfPEFYmsO1YtY8+6VVA89pL2u0xZ4hVdv0pG61k4f5GQDPmNy3Ck+f5je/2AY ONtEvRAJzH4lBKk4ywR+xT2cceJGHbCtmRDYKc3MCOHb0IvF+1MWhXCq9cOkTQLtXhS8 lEhwbxu9pMU87QKbcXWDNQDl+RrN9e1URhk7wpfpXjkiujaflaau/28RGgLGTCyQdRkz E5YXVDe5TcvTkx2MZl2vScv+hLM/BI7TJE8qDrSQPcVOP7xN9aVZUjzCXr+IFP10GX+8 aMvzg8kU+w0Ix6GbzVwcAOOaayVs1Ra2L7hILr18Lt3CdJTR/5E/WaRlHzcIJDDGawFy X2cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vS3EwHGyVQ1ui/XRQLqSt8If+1+oxvv9zuwx32hDFq4=; b=eyPEhIDVTWmn900SS7jsFVOKlmbkWtDwgnN/YL1je09XKI/F+WQzDXNWiDf4Hn8B2Q h8Jb5hQRXubFYZKHnPOU/m15DNQi1AbIU0pD/0j8Yo/oBqoK35vU/jCEe+VJDlam73uI OttxdMZIhAxaXfsgNY8DjrfYzX3E4ZJ3NmEIPynMNziFrXxgzCh+6Zrmry6O7LLWRcFS iksqMyzW9/73OfoR2V0nf/lMPT0nPgl4qkX9R64UxIPFOIBpu7opc0ndqFjdHupUS6n3 TXq4ivnqBk2UPnpUYp2wiwc9Npuvx5WEx+dbLAGryzQuKRw2uLq9oLPqL+CjcB5P266Y rh6A== X-Gm-Message-State: AOAM530iZnKSNNhx71s29ZcloA9HZwP+x9eKjp55Mvx+htRrePDssiAV jbYh81L7uzVkRGhn9e1e+TGZI6rTDiH2QrLdV3tBBGARtas= X-Google-Smtp-Source: ABdhPJzrZMvHz/cj0b0RyPGSw2c1LNKXbvqH3RHPeXSyZ5O17rZH/cMNHt1QbPffTuaPX/MPJNCsdLCmN1HU4Y8C05w= X-Received: by 2002:a1c:e911:0:b0:38e:6c5d:40e5 with SMTP id q17-20020a1ce911000000b0038e6c5d40e5mr18022474wmc.116.1649440179731; Fri, 08 Apr 2022 10:49:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olaoluwa Osuntokun Date: Fri, 8 Apr 2022 13:49:28 -0400 Message-ID: To: Alex Schoof Content-Type: multipart/alternative; boundary="000000000000fdc1d405dc2837db" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 17:49:42 -0000 --000000000000fdc1d405dc2837db Content-Type: text/plain; charset="UTF-8" (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 --000000000000fdc1d405dc2837db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(this might be a double post as I ran into the size l= imit)=C2=A0

Hi Alex,

Thanks for taking a look at= things!

> If that's the case, did you look at other mechanis= ms to commit to a merkle
> root? For example, I believe mainstay[1] u= ses a
> pay-to-contract/bip175[2]-like scheme to commit sidechain mer= kle roots to
> p2pkh/p2sh addresses with signature tweaks. Are there = other interesting
> (to taro) spend-paths that need to be allowed tha= t led to the taproot
> script tree being particularly helpful?
I considered other approaches, but by relying on the existing taproot
c= ommitment structure/derivation, Taro implementations are able to re-use
= surrounding code/libraries, making a core implementation more compact.
C= ommitting into the tapscript tree is also simpler than signature tweaks.One nice trait about using the tapscript tree is that from a wallet's<= br>perceptive, Taro just wants a particular opaque hash to be included in t= he
final tapscript tree. As a result, the wallet doesn't need to mod= ify the way
they sign, or do key derivations or anything. In addition, u= sing the
tapscript tree lets us separate the Bitcoin layer from the Taro= layer as far
as scripts, and also enables easily verification of any so= rt of Script
mirroring between the layers that may be required for certa= in 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 t= o
bind the mechanics to the analogy/metaphor just makes it harder for pe= ople
to understand what's going on.

> If it is, then it lo= oks like a Universe/Multiverse is an
> offload/aggregation mechanism = that can keep track of asset lineages on
> behalf of users, which wou= ld 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 diff= erent types of functionality:

=C2=A0* A way to bootstrap genesis out= put provenance by maintaining a Universe
=C2=A0 =C2=A0which is just the = set of asset issuance transactions (the Universe MS-SMT is
=C2=A0 =C2=A0= keyed by a prevOut at the lowest level). This can be done for several
= =C2=A0 =C2=A0assets.

=C2=A0* A way to collect+index a more complete = view of the set of transfers
=C2=A0 =C2=A0related to assets. This can se= rve the basis for things like a block
=C2=A0 =C2=A0explorer for a single= or several assets. Since the data structure is
=C2=A0 =C2=A0history ind= ependent, multiple explorers can publish their root hash which
=C2=A0 = =C2=A0makes it easy to check that they have the same data, and a bisection<= br>=C2=A0 =C2=A0protocol can be used to sync up distinct universe/multivers= e instances.

=C2=A0* A way to allow aggregation of transfers tied to= a single to level UTXO
=C2=A0 =C2=A0chain, which would likely be used i= n cases like games where the actual
=C2=A0 =C2=A0game needs other server= s or closed source functionality, but the game
=C2=A0 =C2=A0publisher wa= nts the users to be able to prove ownership and also trade in
=C2=A0 =C2= =A0game asset. This can be maintained by a single party, or a
=C2=A0 =C2= =A0threshold/federation. The parties can't include invalid state transi= tions
=C2=A0 =C2=A0or proofs (can't forge the proper signature, etc)= .

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

Yep! I described a sketch of someth= ing like that using TLVU in my prior
reply to Rubin. At a high level, si= nce Taro affect the tapscript root hash,
which affects the output key, b= y requiring a certain output key, or swapping
out the leaf elements, a c= ovenant can further bind Taro rules without
needing to explicitly do val= idation/execution in Bitcoin script itself.

> My first thought wa= s to have the "carrier utxo" for a taro asset be really
> s= mall, like dust + some buffer.

Hmm, can you describe this in more d= etail? 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 el= se that was lingering.

-- Laolu
--000000000000fdc1d405dc2837db--