📅 Original date posted:2023-06-09
🗒️ Summary of this message: Proposal to define any taproot annex that begins with '0' as free-form, allowing immediate utilization and future flexibility for unstructured data use-cases.
📝 Original message:
Hi Joost,
Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.
>From a taproot annex design perspective, I think this could be very
valuable if you have a list of unstructured data use-cases you're thinking
about ? As raised on the BIP proposal, those unstructured data use-cases
could use annex tags with the benefit to combine multiple "types" of
unstructured data in a single annex payload. As you're raising smaller bits
of unstructured data might not afford the overhead though my answer with
this observation would be to move this traffic towards some L2 systems ? In
my mind, the default of adding a version byte for the usage of unstructured
data comes with the downside of having future consensus enabled use-cases
encumbering by the extended witness economic cost.
About the annex payload extension attack described by Greg. If my
understanding of this transaction-relay jamming griefing issue is correct,
we can have an annex tag in the future where the signer is committing to
the total weight of the transaction, or even the max per-input annex size ?
This should prevent a coinjoin or aggregated commitment transaction
counterparty to inflate its annex space to downgrade the overall
transaction feerate, I guess. And I think this could benefit unstructured
data use-cases too.
Best,
Antoine
Le ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230610/2249fe52/attachment.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-19 20:19:54
in reply to nevent1q…5g55
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-19 20:19:54Event JSON
{
"id": "e6362b4065e638c33ccd5bf7a77f9477ed445a90274ce2a87dc908a0e3dc6157",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1687198794,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"66101f6198f6b980028534951fe311d43a31fe0a8f45ae6b0b0e1d0251902823",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2023-06-09\n🗒️ Summary of this message: Proposal to define any taproot annex that begins with '0' as free-form, allowing immediate utilization and future flexibility for unstructured data use-cases.\n📝 Original message:\nHi Joost,\n\nThanks for detailing why a '0' as free-form, without any additional\nconstraints offers valuable engineering properties as of today.\n\n\u003eFrom a taproot annex design perspective, I think this could be very\nvaluable if you have a list of unstructured data use-cases you're thinking\nabout ? As raised on the BIP proposal, those unstructured data use-cases\ncould use annex tags with the benefit to combine multiple \"types\" of\nunstructured data in a single annex payload. As you're raising smaller bits\nof unstructured data might not afford the overhead though my answer with\nthis observation would be to move this traffic towards some L2 systems ? In\nmy mind, the default of adding a version byte for the usage of unstructured\ndata comes with the downside of having future consensus enabled use-cases\nencumbering by the extended witness economic cost.\n\nAbout the annex payload extension attack described by Greg. If my\nunderstanding of this transaction-relay jamming griefing issue is correct,\nwe can have an annex tag in the future where the signer is committing to\nthe total weight of the transaction, or even the max per-input annex size ?\nThis should prevent a coinjoin or aggregated commitment transaction\ncounterparty to inflate its annex space to downgrade the overall\ntransaction feerate, I guess. And I think this could benefit unstructured\ndata use-cases too.\n\nBest,\nAntoine\n\nLe ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Hi,\n\u003e\n\u003e As it stands, the taproot annex is consensus valid but non-standard. The\n\u003e conversations around standardization seem to be leaning towards the\n\u003e adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt\n\u003e that this approach has considerable potential. However, settling on an\n\u003e exact format may require a significant amount of time.\n\u003e\n\u003e In the interim, the benefits of making the annex available in a\n\u003e non-structured form are both evident and immediate. By allowing developers\n\u003e to utilize the taproot annex without delay, we can take advantage of its\n\u003e features today, without the need to wait for the finalization of a more\n\u003e lengthy standardization process.\n\u003e\n\u003e With this in view, I am proposing that we define any annex that begins\n\u003e with '0' as free-form, without any additional constraints. This strategy\n\u003e offers several distinct benefits:\n\u003e\n\u003e Immediate utilization: This opens the door for developers to make use of\n\u003e the taproot annex for a variety of applications straight away, thus\n\u003e eliminating the need to wait for the implementation of TLV or any other\n\u003e structured format.\n\u003e\n\u003e Future flexibility: Assigning '0'-beginning annexes as free-form keeps our\n\u003e options open for future developments and structure improvements. As we\n\u003e forge ahead in determining the best way to standardize the annex, this\n\u003e strategy ensures we do not limit ourselves by setting its structure in\n\u003e stone prematurely.\n\u003e\n\u003e Chainspace efficiency: Non-structured data may require fewer bytes\n\u003e compared to a probable TLV format, which would necessitate the encoding of\n\u003e length even when there's only a single field.\n\u003e\n\u003e In conclusion, adopting this approach will immediately broaden the\n\u003e utilization scope of the taproot annex while preserving the possibility of\n\u003e transitioning to a more structured format in the future. I believe this is\n\u003e a pragmatic and efficient route, one that can yield substantial benefits in\n\u003e both the short and long term.\n\u003e\n\u003e Joost\n\u003e\n\u003e [1] https://github.com/bitcoin/bips/pull/1381\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230610/2249fe52/attachment.html\u003e",
"sig": "99f44bcd118d516f38997dfed8a44f39d28420df4488dc93a147370c6fffc41c010e70640e0d0bd290929c18ff01fc485413919700e338254b474ab947cb32fa"
}