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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Precedence: list

--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 =
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=
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--