Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

From: Olaoluwa Osuntokun <laolu32@gmail•com>
To: Bram Cohen <bram@chia•net>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Date: Mon, 11 Apr 2022 14:21:14 -0400	[thread overview]
Message-ID: <CAO3Pvs_MPLWb+8HMzJ4XgVvh_wzUgPpGpnciNCEyryDdUZi6YQ@mail.gmail.com> (raw)
In-Reply-To: <CAHUJnBCwkVA1etjBDLDCcfCJvVfKePzNCO0NYt=qMT8HL4PxJw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]

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? 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.

Future op codes that allow Scripts to push annex data onto the stack could
also be used to further bind higher level protocols while still allowing the
base Bitcoin consensus rules to not have to be explicitly aware of them.

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

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

-- Laolu

On Sun, Apr 10, 2022 at 9:10 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> From: Olaoluwa Osuntokun <laolu32@gmail•com>
>
>>
>> > Furthermore, the Taro script is not enforced by Bitcoin, meaning those
>> who
>> > control the Bitcoin script can always choose to ignore the Taro script
>> and
>> > destroy the Taro assets as a result.
>>
>> This is correct, as a result in most contexts, an incentive exists for the
>> holder of an asset to observe the Taro validation rules as otherwise,
>> their
>> assets are burnt in the process from the PoV of asset verifiers. In the
>> single
>> party case things are pretty straight forward, but more care needs to be
>> taken
>> in cases where one attempts to express partial application and permits
>> anyone
>> to spend a UTXO in question.
>>
>> By strongly binding all assets to Bitcoin UTXOs, we resolve issues related
>> to
>> double spending or duplicate assets, but needs to mind the fact that
>> assets
>> can
>> be burnt if a user doesn't supply a valid witness. There're likely ways to
>> get
>> around this by lessening the binding to Bitcoin UTXO's, but then the
>> system
>> would need to be able to collect, retain and order all the set of possible
>> spends, essentially requiring a parallel network. The core of the system
>> as
>> it
>> stands today is pretty simple (which was an explicit design goal to avoid
>> getting forever distracted by the large design space), with a minimal
>> implementation being relatively compact given all the Bitcoin
>> context/design
>> re-use.
>>
>
> The TARO set of tradeoffs is fairly coherent but is subject to certain
> limitations (modulo my understanding of it being off):
>
> The witnesses for transactions need to be put into Bitcoin transactions
> even though the Bitcoin layer doesn't understand them
>
> There needs to be a constraint on Taro transactions which is understood by
> the Bitcoin layer (which often/usually happens naturally because there's a
> user signature but sometimes doesn't. It's a limitation)
>
> Multiple Taro coins can't consolidate their value into a single output
> because they only support a single linear history
>
> Taro issuance is limited to a single event rather than potentially
> multiple events over time subject to special per-asset rules.
>
> This seems like a fairly logical approach (although my understanding of
> the limitations/tradeoffs could be wrong, especially with regards to
> consolidation). There's nothing wrong with a system having well documented
> limitations, 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6778 bytes --]