path: root/f3/e59f02a7f9bde20096d9520307a6fa7f35df79

Return-Path: <laolu32@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B9863C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Apr 2022 17:49:41 +0000 (UTC)
Received: by mail-wm1-x329.google.com with SMTP id
 v20-20020a05600c15d400b0038e9a88aee7so2933768wmf.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com>
 <CAPv7TjYTjvSV7UFgOwif6tFj3jVxDfJdW-p_cyPoAGGWKQbwRQ@mail.gmail.com>
 <CA+2b5C058bdGfqB9uzSHkv3Q4=mC=fRdNJAuxErkXfKF2X-Siw@mail.gmail.com>
In-Reply-To: <CA+2b5C058bdGfqB9uzSHkv3Q4=mC=fRdNJAuxErkXfKF2X-Siw@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 8 Apr 2022 13:49:28 -0400
Message-ID: <CAO3Pvs-NU04doUd1LbmjBXz1TKKfN_8WLrBtpe0WS6hbOj5rFQ@mail.gmail.com>
To: Alex Schoof <alex.schoof@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fdc1d405dc2837db"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div>(this might be a double post as I ran into the size l=
imit)=C2=A0</div><div><br></div>Hi Alex,<br><br>Thanks for taking a look at=
 things!<br><br>&gt; If that&#39;s the case, did you look at other mechanis=
ms to commit to a merkle<br>&gt; root? For example, I believe mainstay[1] u=
ses a<br>&gt; pay-to-contract/bip175[2]-like scheme to commit sidechain mer=
kle roots to<br>&gt; p2pkh/p2sh addresses with signature tweaks. Are there =
other interesting<br>&gt; (to taro) spend-paths that need to be allowed tha=
t led to the taproot<br>&gt; script tree being particularly helpful?<br><br=
>I considered other approaches, but by relying on the existing taproot<br>c=
ommitment structure/derivation, Taro implementations are able to re-use<br>=
surrounding code/libraries, making a core implementation more compact.<br>C=
ommitting into the tapscript tree is also simpler than signature tweaks.<br=
>One nice trait about using the tapscript tree is that from a wallet&#39;s<=
br>perceptive, Taro just wants a particular opaque hash to be included in t=
he<br>final tapscript tree. As a result, the wallet doesn&#39;t need to mod=
ify the way<br>they sign, or do key derivations or anything. In addition, u=
sing the<br>tapscript tree lets us separate the Bitcoin layer from the Taro=
 layer as far<br>as scripts, and also enables easily verification of any so=
rt of Script<br>mirroring between the layers that may be required for certa=
in applications.<br><br>&gt; This reminds me a lot of single-use-seals[3]. =
Is that the right way to<br>&gt; think about what&#39;s going on here? <br>=
<br>Yes a similar construct is used. I personally don&#39;t really like the=
<br>single-use-seals terminology, as I find it somewhat obtuse and trying t=
o<br>bind the mechanics to the analogy/metaphor just makes it harder for pe=
ople<br>to understand what&#39;s going on.<br><br>&gt; If it is, then it lo=
oks like a Universe/Multiverse is an<br>&gt; offload/aggregation mechanism =
that can keep track of asset lineages on<br>&gt; behalf of users, which wou=
ld be useful for light clients of heavily-used<br>&gt; asset types (so your=
 mobile client doesnt have to traverse the transfer<br>&gt; lineage of some=
 high-liquidity stablecoin or something). <br><br>So the provide a few diff=
erent types of functionality:<br><br>=C2=A0* A way to bootstrap genesis out=
put provenance by maintaining a Universe<br>=C2=A0 =C2=A0which is just the =
set of asset issuance transactions (the Universe MS-SMT is<br>=C2=A0 =C2=A0=
keyed by a prevOut at the lowest level). This can be done for several<br>=
=C2=A0 =C2=A0assets.<br><br>=C2=A0* A way to collect+index a more complete =
view of the set of transfers<br>=C2=A0 =C2=A0related to assets. This can se=
rve the basis for things like a block<br>=C2=A0 =C2=A0explorer for a single=
 or several assets. Since the data structure is<br>=C2=A0 =C2=A0history ind=
ependent, multiple explorers can publish their root hash which<br>=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.<br><br>=C2=A0* A way to allow aggregation of transfers tied to=
 a single to level UTXO<br>=C2=A0 =C2=A0chain, which would likely be used i=
n cases like games where the actual<br>=C2=A0 =C2=A0game needs other server=
s or closed source functionality, but the game<br>=C2=A0 =C2=A0publisher wa=
nts the users to be able to prove ownership and also trade in<br>=C2=A0 =C2=
=A0game asset. This can be maintained by a single party, or a<br>=C2=A0 =C2=
=A0threshold/federation. The parties can&#39;t include invalid state transi=
tions<br>=C2=A0 =C2=A0or proofs (can&#39;t forge the proper signature, etc)=
.<br><br>&gt; - There&#39;s been a lot of talk lately on the bitcoin-dev li=
st about<br>&gt; covenants, and I wonder if some of those designs (specific=
ally TLUV or<br>&gt; CTV) might be useful with Taro, to &quot;lift&quot; so=
me of the taro conditions into<br>&gt; covenants that encumber the underlyi=
ng bitcoin. I don&#39;t have a design or<br>&gt; anything, wondering if you=
&#39;ve given this any thought. <br><br>Yep! I described a sketch of someth=
ing like that using TLVU in my prior<br>reply to Rubin. At a high level, si=
nce Taro affect the tapscript root hash,<br>which affects the output key, b=
y requiring a certain output key, or swapping<br>out the leaf elements, a c=
ovenant can further bind Taro rules without<br>needing to explicitly do val=
idation/execution in Bitcoin script itself.<br><br>&gt; My first thought wa=
s to have the &quot;carrier utxo&quot; for a taro asset be really<br>&gt; s=
mall, like dust + some buffer. <br><br>Hmm, can you describe this in more d=
etail? Do you mean an _extra_ UTXO, or<br>just mapping the Taro conditions =
as much as possible to the top-level<br>Bitcoin scripts?<br><br>&gt; - was =
this originally named CMYK? <br><br>Maybe ;), a few versions were floating =
around before I published the current<br>draft, so some prior artifacts may=
 still be floating around. Will do another<br>sweep to clean up anything el=
se that was lingering.<br><br>-- Laolu<br></div>

--000000000000fdc1d405dc2837db--