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.