diff options
| author | Bram Cohen <bram@chia.net> | 2022-04-11 14:29:31 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-04-11 21:29:45 +0000 |
| commit | bee1bb893cc96fcf904b971fdd7d8d286a3f3677 (patch) | |
| tree | 27cf2678b7615ccbae9cf598ed6cc367b135fffc | |
| parent | 364fb401a3fcf76a3d53c971835e962e642ce00f (diff) | |
| download | pi-bitcoindev-bee1bb893cc96fcf904b971fdd7d8d286a3f3677.tar.gz pi-bitcoindev-bee1bb893cc96fcf904b971fdd7d8d286a3f3677.zip | |
Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
| -rw-r--r-- | 47/fcd761349ea2679b63f07508b14d1c9dd3d3a4 | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/47/fcd761349ea2679b63f07508b14d1c9dd3d3a4 b/47/fcd761349ea2679b63f07508b14d1c9dd3d3a4 new file mode 100644 index 000000000..81c3ae2ed --- /dev/null +++ b/47/fcd761349ea2679b63f07508b14d1c9dd3d3a4 @@ -0,0 +1,227 @@ +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 <<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>>= +; The witnesses for transactions need to be put into Bitcoin transactions<b= +r>> even though the Bitcoin layer doesn't understand them<br><br>Is = +this related to Ruben'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'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'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'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">> Taro issuance is limited to a single event rather than potentially<= +br>> multiple events over time subject to special per-asset rules.<br><b= +r>There'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'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>> but I am puzzled by the announcement saying Taro assets are = +9;analogous<br>> with' colored coins. Taro assets are straightforwar= +dly and unambiguously<br>> colored coins and that isn't something to= + be ashamed of.<br><br>We've shied away from using the "colored co= +ins' terminology as at this point<br>in the game it'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", 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'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 'colored' is a bit loaded in different ways around the world= + so it's best to keep it in the technical docs.</div></div></div> + +--00000000000076c63d05dc67a4b3-- + |