1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <joost.jager@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 07CBCC0029
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2023 15:01:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id D24EB844B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2023 15:01:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D24EB844B4
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=ose6+Xkq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aUBJpcLpFRKT
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2023 15:01:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ADF8A84497
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
[IPv6:2a00:1450:4864:20::636])
by smtp1.osuosl.org (Postfix) with ESMTPS id ADF8A84497
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2023 15:01:15 +0000 (UTC)
Received: by mail-ej1-x636.google.com with SMTP id
a640c23a62f3a-96f5d651170so723846466b.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 02 Jun 2023 08:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685718074; x=1688310074;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=YFywPDv0LgbvyLrF9LjR+XVXnhQt/aaJbmbZr0DEVYA=;
b=ose6+Xkq8YRF/RKE9BUJ6Dr7B7RdoSa45rOkKBL35H0g8o0GwsoPZcq5dqAEG9ac0K
r/U9x2C1sp0AurtNaPlnorLMrfjNwmYRf+J2cKwk63Ia9TvM65WALpYkbWg32AElGB55
iySP7FN9i/dGL7fUlUU9IBHrLoAfioVIaW6N3bT5EWIIjp3nPG/oXIeY/p2PO7U5nOVv
DM2bo9bhJwVFKbKP0jGk72NVqlj2tLLLmWkLfXnMDTdifaxAAXt3+ETnfHqAqsJnsjp2
dlL00DOmddOJGs72feSmHoauQ++K91kLGc7ymXskyY3l36z3EdCsrML6sjmOmKeX7zUx
jpaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685718074; x=1688310074;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=YFywPDv0LgbvyLrF9LjR+XVXnhQt/aaJbmbZr0DEVYA=;
b=Ba6gYCpA0KXjpGO36AApAmlWXXPBEOtCb1f0FfBzbiB78lJUu76XxfHGJute6zGcjX
+taYSIQBGGlXIA9PTc4ru45Bw1kKgKESNyBqq4fDHNizvX5hOsmB2Ret/ypTglkV3yg/
m7jwk0wk0gzv0o5RywvHinv4s5XhrRgtZxZ2Zw/3U4FdXcXnlBOBLkGr4j9zmdwFqdPw
OgHQtC1CaML2qCe+WEA4jV8ft0VDhpYB8ziLzHfh1/Lj8FtVL8JzZqmpGKDVCF9eUqFL
d938W071/6Nw4cHnd7IJDb3r7LaA2/wsOMmzmmrN+y5KWL1faxvvvkyy6kLADBS1GCvY
6HJA==
X-Gm-Message-State: AC+VfDw4k8pm5CdEVbHQQpuvGErihL5s6wjKBqh68FJX94YO9VsmGxhn
2J7mVqJqYCeOgdxNIATA4InAZNVhvKdlmtU0tDKi5Bqqkjs=
X-Google-Smtp-Source: ACHHUZ76vgCDOMwPBkDQyijTWhGT59K2P5SQltdJK7uOZ7G+lHTRDaG4g4AFsos92tj1jWfPmqNWgj0YKn0pJ4kZMgw=
X-Received: by 2002:a17:907:9484:b0:973:e5bf:281e with SMTP id
dm4-20020a170907948400b00973e5bf281emr5128069ejc.27.1685718073538; Fri, 02
Jun 2023 08:01:13 -0700 (PDT)
MIME-Version: 1.0
From: Joost Jager <joost.jager@gmail.com>
Date: Fri, 2 Jun 2023 17:00:37 +0200
Message-ID: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f6fe9305fd26d2d3"
X-Mailman-Approved-At: Fri, 02 Jun 2023 21:17:56 +0000
Subject: [bitcoin-dev] Standardisation of an unstructured taproot annex
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2023 15:01:17 -0000
--000000000000f6fe9305fd26d2d3
Content-Type: text/plain; charset="UTF-8"
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
--000000000000f6fe9305fd26d2d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>As it stands, the taproot annex is consensus va=
lid but non-standard. The conversations around standardization seem to be l=
eaning towards the adoption of a flexible Type-Length-Value (TLV) format [1=
]. There's no doubt that this approach has considerable potential. Howe=
ver, settling on an exact format may require a significant amount of time.<=
br><br>In the interim, the benefits of making the annex available in a non-=
structured form are both evident and immediate. By allowing developers to u=
tilize the taproot annex without delay, we can take advantage of its featur=
es today, without the need to wait for the finalization of a more lengthy s=
tandardization process.<br><br>With this in view, I am proposing that we de=
fine any annex that begins with '0' as free-form, without any addit=
ional constraints. This strategy offers several distinct benefits:<br><br>I=
mmediate utilization: This opens the door for developers to make use of the=
taproot annex for a variety of applications straight away, thus eliminatin=
g the need to wait for the implementation of TLV or any other structured fo=
rmat.<br><br>Future flexibility: Assigning '0'-beginning annexes as=
free-form keeps our options open for future developments and structure imp=
rovements. As we forge ahead in determining the best way to standardize the=
annex, this strategy ensures we do not limit ourselves by setting its stru=
cture in stone prematurely.<br><br>Chainspace efficiency: Non-structured da=
ta may require fewer bytes compared to a probable TLV format, which would n=
ecessitate the encoding of length even when there's only a single field=
. <br><br>In conclusion, adopting this approach will immediately broaden th=
e utilization scope of the taproot annex while preserving the possibility o=
f transitioning to a more structured format in the future. I believe this i=
s a pragmatic and efficient route, one that can yield substantial benefits =
in both the short and long term.<br><br>Joost<br><br>[1] <a href=3D"https:/=
/github.com/bitcoin/bips/pull/1381">https://github.com/bitcoin/bips/pull/13=
81</a></div>
--000000000000f6fe9305fd26d2d3--
|
