📅 Original date posted:2023-06-02
🗒️ Summary of this message: Proposal to make the taproot annex available in a non-structured form by defining any annex that begins with '0' as free-form, allowing immediate utilization and future flexibility.
📝 Original message:Hi,
As it stands, the taproot annex is consensus valid but non-standard. The
conversations around standardization seem to be leaning towards the
adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
that this approach has considerable potential. However, settling on an
exact format may require a significant amount of time.
In the interim, the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing developers
to utilize the taproot annex without delay, we can take advantage of its
features today, without the need to wait for the finalization of a more
lengthy standardization process.
With this in view, I am proposing that we define any annex that begins with
'0' as free-form, without any additional constraints. This strategy offers
several distinct benefits:
Immediate utilization: This opens the door for developers to make use of
the taproot annex for a variety of applications straight away, thus
eliminating the need to wait for the implementation of TLV or any other
structured format.
Future flexibility: Assigning '0'-beginning annexes as free-form keeps our
options open for future developments and structure improvements. As we
forge ahead in determining the best way to standardize the annex, this
strategy ensures we do not limit ourselves by setting its structure in
stone prematurely.
Chainspace efficiency: Non-structured data may require fewer bytes compared
to a probable TLV format, which would necessitate the encoding of length
even when there's only a single field.
In conclusion, adopting this approach will immediately broaden the
utilization scope of the taproot annex while preserving the possibility of
transitioning to a more structured format in the future. I believe this is
a pragmatic and efficient route, one that can yield substantial benefits in
both the short and long term.
Joost
[1] https://github.com/bitcoin/bips/pull/1381
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/4411b85b/attachment-0001.html>;
Joost Jager [ARCHIVE] /
npub1as…wfqmx
2023-06-08 01:22:06
in reply to nevent1q…rtvy
Author Public Key
npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxPublished at
2023-06-08 01:22:06Event JSON
{
"id": "27fc8374b7e55ec05471b925087a9669b81ced616b24a7424699690c984075e9",
"pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3",
"created_at": 1686180126,
"kind": 1,
"tags": [
[
"e",
"b686717ee8b6c1778c5cebee48da470faaa2069000c176619f95f986554460f4",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2023-06-02\n🗒️ Summary of this message: Proposal to make the taproot annex available in a non-structured form by defining any annex that begins with '0' as free-form, allowing immediate utilization and future flexibility.\n📝 Original message:Hi,\n\nAs it stands, the taproot annex is consensus valid but non-standard. The\nconversations around standardization seem to be leaning towards the\nadoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt\nthat this approach has considerable potential. However, settling on an\nexact format may require a significant amount of time.\n\nIn the interim, the benefits of making the annex available in a\nnon-structured form are both evident and immediate. By allowing developers\nto utilize the taproot annex without delay, we can take advantage of its\nfeatures today, without the need to wait for the finalization of a more\nlengthy standardization process.\n\nWith this in view, I am proposing that we define any annex that begins with\n'0' as free-form, without any additional constraints. This strategy offers\nseveral distinct benefits:\n\nImmediate utilization: This opens the door for developers to make use of\nthe taproot annex for a variety of applications straight away, thus\neliminating the need to wait for the implementation of TLV or any other\nstructured format.\n\nFuture flexibility: Assigning '0'-beginning annexes as free-form keeps our\noptions open for future developments and structure improvements. As we\nforge ahead in determining the best way to standardize the annex, this\nstrategy ensures we do not limit ourselves by setting its structure in\nstone prematurely.\n\nChainspace efficiency: Non-structured data may require fewer bytes compared\nto a probable TLV format, which would necessitate the encoding of length\neven when there's only a single field.\n\nIn conclusion, adopting this approach will immediately broaden the\nutilization scope of the taproot annex while preserving the possibility of\ntransitioning to a more structured format in the future. I believe this is\na pragmatic and efficient route, one that can yield substantial benefits in\nboth the short and long term.\n\nJoost\n\n[1] https://github.com/bitcoin/bips/pull/1381\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/4411b85b/attachment-0001.html\u003e",
"sig": "2b906a684fe384d937294e7e410b714e7a16e5e5017624ac06dd247c3d99861969c1ac79d3d306de53ba18aba511d21bbb6588a5eb7d222547456abea519f139"
}