path: root/47/fcd761349ea2679b63f07508b14d1c9dd3d3a4

Return-Path: <bram@chia.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C624AC002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Apr 2022 21:29:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id AEF7983187
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Apr 2022 21:29:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id D3-eKWqbeHI7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Apr 2022 21:29:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [IPv6:2a00:1450:4864:20::12f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id A21E183118
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Apr 2022 21:29:44 +0000 (UTC)
Received: by mail-lf1-x12f.google.com with SMTP id z17so4410872lfj.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Apr 2022 14:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=mph1E6ckasG5SM0DAuDwbesPJ5V7XGXUQAeuRqD11bc=;
 b=2SKmjfzYJBSANZsibDz80iUX8jzPJeoFfDq50DvmlEYHDiSCT9ESzjpmBUGgGPiS25
 fscEg83oNPuN3XkPj67Rzi6R35wgLWdU3SkrdrsXG3DcvaKQ7KlkznXes4HPoNPlD3e1
 N90T/UJlbOhDyZ1VboGK9TRbikAabOHmyJcqU0C5sULI0HGCKHvZ395L06fLbzvfK0IH
 s5hpxsWcZHYdWY/ZOOJCZCdcFr/AclfinNCcXLXSpev1WXY8szNM6Aq3pgYit+uLDgFH
 0kps0FyitjCdzmSphbxywTaTvZNtG7Hpz5Kkcx2LbLftv0HofZ+RKVcoXzJk3BVgdcd/
 T5ag==
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=mph1E6ckasG5SM0DAuDwbesPJ5V7XGXUQAeuRqD11bc=;
 b=YtpoEk/+NnJ5L7sYtGJh2clqAbc7ybjmndzbEcoNQU7PsrUG3jMm3hNMbfqCCeDUQk
 jrgRezXCRiAwoe0a8jA8O6Jvw6OVq4Qq+41+wwgL9kDG01PB2Xfqz3XHdEgZxNT0y4wn
 gKwgGt+lQqjwgQngIZ7Xi3Tcn7xDyZKlLRmaCD0Csq2jOHn2ymnsRuQpNuLSgcKDCsF5
 tPQIERLub8GCvs/SDH1YLebcq0CykSb7jW4dPA5RpeUif6utox+iSCHDLfWRTQxzhH3i
 uoDhEWecBnQjLajDx1VgkfICDR/LG2Cxrfsks5o0aKySfsojcJcnIIgXQboZy2ct1Z17
 nLpw==
X-Gm-Message-State: AOAM5331cMddYg7ZwjyeAb7eVTrq1R90YyKH0qZBU98P/VgetVFiT5Ey
 V/2fO1ElvRx65oaeV8bXm1wZPEYggJiQlpQv0HfaGxDOqXY=
X-Google-Smtp-Source: ABdhPJwArL8AKudwzas5Y6R4QYPFY0rVnnPPcDw2AFqVp7dZdC0F4KLuXlW84cMcq4BHCHHDz6SEHWSYwH4JCmkBENU=
X-Received: by 2002:a19:ad08:0:b0:46b:ae4d:2861 with SMTP id
 t8-20020a19ad08000000b0046bae4d2861mr2867865lfc.228.1649712582537; Mon, 11
 Apr 2022 14:29:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAHUJnBCwkVA1etjBDLDCcfCJvVfKePzNCO0NYt=qMT8HL4PxJw@mail.gmail.com>
 <CAO3Pvs_MPLWb+8HMzJ4XgVvh_wzUgPpGpnciNCEyryDdUZi6YQ@mail.gmail.com>
In-Reply-To: <CAO3Pvs_MPLWb+8HMzJ4XgVvh_wzUgPpGpnciNCEyryDdUZi6YQ@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Mon, 11 Apr 2022 14:29:31 -0700
Message-ID: <CAHUJnBC2AiOyyNGNtjnQFsS74tEf7MQO9K1FrOJ_TZjVDH7ifw@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000076c63d05dc67a4b3"
X-Mailman-Approved-At: Mon, 11 Apr 2022 22:01:46 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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: Mon, 11 Apr 2022 21:29:45 -0000

--00000000000076c63d05dc67a4b3
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun <laolu32@gmail.com>
wrote:

> Hi Bram,
>
> > The witnesses for transactions need to be put into Bitcoin transactions
> > even though the Bitcoin layer doesn't understand them
>
> Is this related to Ruben's comment about invalid state transitions
> (published in the base chain) leading to burned assets?
>

Yes, or at least the concern that a valid transaction could have its
required witness data not posted to the chain and be effectively bricked.


> In the past, I've
> considered using the existing annex field in taproot transactions to
> implement partial reveal of certain data. However, today bitcoind treats
> annex usage as non-standard, so those transactions may be harder to relay.
> IMO this is a great place to add minimal extra data, as it doesn't bleed
> over into
> the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures
> also include this field in the sighash, the sigs serve to further
> authenticate this data.
>

That leads to a bit of a philosophical question: Is the annex reserved for
possible future Bitcoin script soft forks, or is it free to use for
whatever with confidence there won't be a future collision? But that might
not matter, because if the purpose is to force the extra witness
information to be published it has to be in something signed in the
transaction, and barring a check sig from stack that probably means it has
to be shoved into the transaction somewhere.



> > Taro issuance is limited to a single event rather than potentially
> > multiple events over time subject to special per-asset rules.
>
> There's a provision in the protocol that lets a party issuing assets to
> specify a special public key which is then tweaked with the genesis
> outpoint, similar to the way the asset IDs are generated. If this key is
> specified, then future issuance, if signed off by that key, will serve to
> associate assets of discrete IDs under a single identifier. This feature
> allows assets issued in multiple tranches to be fungible with one another.
>

Ah I see. That's still a fairly bespoke set of functionality instead of
allowing an arbitrary script to be used for the issuance (but that again
runs into Bitcoin script being fairly limited in its functionality).


>
> > but I am puzzled by the announcement saying Taro assets are 'analogous
> > with' colored coins. Taro assets are straightforwardly and unambiguously
> > colored coins and that isn't something to be ashamed of.
>
> We've shied away from using the "colored coins' terminology as at this
> point
> in the game it's pretty dated: new developers that joined in the last 3
> years or so have likely never heard of that term. Explaining the term also
> requires one to define "coin coloring", and what that actually means, etc,
> etc. IMO it's simpler to just use the familiar and widely used asset
> issuance/minting terminology.
>

People mostly haven't heard of colored coins in a while because everything
has been based on ERC-20 style tokens, which are truly horrid. Coloring is
a meaningful technical term which means something good, although
unfortunately the term 'colored' is a bit loaded in different ways around
the world so it's best to keep it in the technical docs.

--00000000000076c63d05dc67a4b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa=
 Osuntokun &lt;<a href=3D"mailto:laolu32@gmail.com">laolu32@gmail.com</a>&g=
t; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi Bram, <br><br>&gt=
; The witnesses for transactions need to be put into Bitcoin transactions<b=
r>&gt; even though the Bitcoin layer doesn&#39;t understand them<br><br>Is =
this related to Ruben&#39;s comment about invalid state transitions<br>(pub=
lished in the base chain) leading to burned assets?</div></div></blockquote=
><div><br></div><div>Yes, or at least the concern that a valid transaction =
could have its required witness data not posted to the chain and be effecti=
vely bricked.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"> In the past, I&#39;ve<br>cons=
idered using the existing annex field in taproot transactions to<br>impleme=
nt partial reveal of certain data. However, today bitcoind treats<br>annex =
usage as non-standard, so those transactions may be harder to relay.<br>IMO=
 this is a great place to add minimal extra data, as it doesn&#39;t bleed o=
ver into<br>the scripting layer (via OP_DROP usages) and since Bitcoin-leve=
l signatures<br>also include this field in the sighash, the sigs serve to f=
urther<br>authenticate this data.<br></div></div></blockquote><div><br></di=
v><div>That leads to a bit of a philosophical question: Is the annex reserv=
ed for possible future Bitcoin script soft forks, or is it free to use for =
whatever with confidence there won&#39;t be a future collision? But that mi=
ght not matter, because if the purpose is to force the extra witness inform=
ation to be published it has to be in something signed in the transaction, =
and barring a check sig from stack that probably means it has to be shoved =
into the transaction somewhere.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r">&gt; Taro issuance is limited to a single event rather than potentially<=
br>&gt; multiple events over time subject to special per-asset rules.<br><b=
r>There&#39;s a provision in the protocol that lets a party issuing assets =
to<br>specify a special public key which is then tweaked with the genesis<b=
r>outpoint, similar to the way the asset IDs are generated. If this key is<=
br>specified, then future issuance, if signed off by that key, will serve t=
o<br>associate assets of discrete IDs under a single identifier. This featu=
re<br>allows assets issued in multiple tranches to be fungible with one ano=
ther.<br></div></div></blockquote><div><br></div><div>Ah I see. That&#39;s =
still a fairly bespoke set of functionality instead of allowing an arbitrar=
y script to be used for the issuance (but that again runs into Bitcoin scri=
pt being fairly limited in its functionality).</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r"><br>&gt; but I am puzzled by the announcement saying Taro assets are &#3=
9;analogous<br>&gt; with&#39; colored coins. Taro assets are straightforwar=
dly and unambiguously<br>&gt; colored coins and that isn&#39;t something to=
 be ashamed of.<br><br>We&#39;ve shied away from using the &quot;colored co=
ins&#39; terminology as at this point<br>in the game it&#39;s pretty dated:=
 new developers that joined in the last 3<br>years or so have likely never =
heard of that term. Explaining the term also<br>requires one to define &quo=
t;coin coloring&quot;, and what that actually means, etc,<br>etc. IMO it&#3=
9;s simpler to just use the familiar and widely used asset<br>issuance/mint=
ing terminology.<br></div></div></blockquote><div><br></div><div>People mos=
tly haven&#39;t heard of colored coins in a while because everything has be=
en based on ERC-20 style tokens, which are truly horrid. Coloring is a mean=
ingful technical term which means something good, although unfortunately th=
e term &#39;colored&#39; is a bit loaded in different ways around the world=
 so it&#39;s best to keep it in the technical docs.</div></div></div>

--00000000000076c63d05dc67a4b3--