📅 Original date posted:2022-04-11
📝 Original message:On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun <laolu32 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220411/6e575c43/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:06:55
in reply to nevent1q…dzcj
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:06:55Event JSON
{
"id": "3ae65061d465d0f2bfb47eb05c6d198bbbdd8337e6e9259c5915b54c8b944c09",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686179215,
"kind": 1,
"tags": [
[
"e",
"7a6086c0582e5db94a6d7dcccec7de94bb339f8f0c81d87a622b3bb20e0cbe9c",
"",
"root"
],
[
"e",
"fc4b30dc35c8a0bcec157a3b0a0be83254cf817de498c32ebae4e220e4c3ee78",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-04-11\n📝 Original message:On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\nwrote:\n\n\u003e Hi Bram,\n\u003e\n\u003e \u003e The witnesses for transactions need to be put into Bitcoin transactions\n\u003e \u003e even though the Bitcoin layer doesn't understand them\n\u003e\n\u003e Is this related to Ruben's comment about invalid state transitions\n\u003e (published in the base chain) leading to burned assets?\n\u003e\n\nYes, or at least the concern that a valid transaction could have its\nrequired witness data not posted to the chain and be effectively bricked.\n\n\n\u003e In the past, I've\n\u003e considered using the existing annex field in taproot transactions to\n\u003e implement partial reveal of certain data. However, today bitcoind treats\n\u003e annex usage as non-standard, so those transactions may be harder to relay.\n\u003e IMO this is a great place to add minimal extra data, as it doesn't bleed\n\u003e over into\n\u003e the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures\n\u003e also include this field in the sighash, the sigs serve to further\n\u003e authenticate this data.\n\u003e\n\nThat leads to a bit of a philosophical question: Is the annex reserved for\npossible future Bitcoin script soft forks, or is it free to use for\nwhatever with confidence there won't be a future collision? But that might\nnot matter, because if the purpose is to force the extra witness\ninformation to be published it has to be in something signed in the\ntransaction, and barring a check sig from stack that probably means it has\nto be shoved into the transaction somewhere.\n\n\n\n\u003e \u003e Taro issuance is limited to a single event rather than potentially\n\u003e \u003e multiple events over time subject to special per-asset rules.\n\u003e\n\u003e There's a provision in the protocol that lets a party issuing assets to\n\u003e specify a special public key which is then tweaked with the genesis\n\u003e outpoint, similar to the way the asset IDs are generated. If this key is\n\u003e specified, then future issuance, if signed off by that key, will serve to\n\u003e associate assets of discrete IDs under a single identifier. This feature\n\u003e allows assets issued in multiple tranches to be fungible with one another.\n\u003e\n\nAh I see. That's still a fairly bespoke set of functionality instead of\nallowing an arbitrary script to be used for the issuance (but that again\nruns into Bitcoin script being fairly limited in its functionality).\n\n\n\u003e\n\u003e \u003e but I am puzzled by the announcement saying Taro assets are 'analogous\n\u003e \u003e with' colored coins. Taro assets are straightforwardly and unambiguously\n\u003e \u003e colored coins and that isn't something to be ashamed of.\n\u003e\n\u003e We've shied away from using the \"colored coins' terminology as at this\n\u003e point\n\u003e in the game it's pretty dated: new developers that joined in the last 3\n\u003e years or so have likely never heard of that term. Explaining the term also\n\u003e requires one to define \"coin coloring\", and what that actually means, etc,\n\u003e etc. IMO it's simpler to just use the familiar and widely used asset\n\u003e issuance/minting terminology.\n\u003e\n\nPeople mostly haven't heard of colored coins in a while because everything\nhas been based on ERC-20 style tokens, which are truly horrid. Coloring is\na meaningful technical term which means something good, although\nunfortunately the term 'colored' is a bit loaded in different ways around\nthe world so it's best to keep it in the technical docs.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220411/6e575c43/attachment.html\u003e",
"sig": "6674ff44670baf3f36a75d648c2ca10f002e1521ebac681d5a28b0adc58b6e058cdc430b49e5fd4bde16acfaa4a96e11057ae4188da0d6b0541b8212f25804a5"
}