Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-02 🗒️ Summary of this message: Proposal to ...
📅 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>;
🗒️ 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>;