From: Bram Cohen <bram@chia•net>
To: Olaoluwa Osuntokun <laolu32@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Date: Mon, 11 Apr 2022 14:29:31 -0700 [thread overview]
Message-ID: <CAHUJnBC2AiOyyNGNtjnQFsS74tEf7MQO9K1FrOJ_TZjVDH7ifw@mail.gmail.com> (raw)
In-Reply-To: <CAO3Pvs_MPLWb+8HMzJ4XgVvh_wzUgPpGpnciNCEyryDdUZi6YQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4369 bytes --]
next prev parent reply other threads:[~2022-04-11 21:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 0:30 Bram Cohen
2022-04-11 18:21 ` Olaoluwa Osuntokun
2022-04-11 21:29 ` Bram Cohen [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-04-05 20:23 vjudeu
2022-04-06 0:43 ` ZmnSCPxj
2022-04-05 15:06 Olaoluwa Osuntokun
2022-04-07 17:14 ` Ruben Somsen
2022-04-08 17:48 ` Olaoluwa Osuntokun
2022-04-10 16:51 ` Ruben Somsen
2022-04-11 19:51 ` Olaoluwa Osuntokun
2022-04-15 13:14 ` Ruben Somsen
2022-04-16 2:43 ` Olaoluwa Osuntokun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHUJnBC2AiOyyNGNtjnQFsS74tEf7MQO9K1FrOJ_TZjVDH7ifw@mail.gmail.com \
--to=bram@chia$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox