summaryrefslogtreecommitdiff
path: root/d4/1af634b32107e31d71f5306199575a728775bc
blob: 8425c62b38c9072914895bab84e761e7806f05db (plain)
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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
Return-Path: <joost.jager@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 049DFC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Jun 2023 09:17:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id BEF9961412
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Jun 2023 09:17:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BEF9961412
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=EC8688o7
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LMNXAdw0Dg0G
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Jun 2023 09:17:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 842B860AD6
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [IPv6:2a00:1450:4864:20::52b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 842B860AD6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  8 Jun 2023 09:17:04 +0000 (UTC)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5151934a4e3so531946a12.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 08 Jun 2023 02:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1686215822; x=1688807822;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=HDCQAesq49wFWdH6l6xJB6jOa1uLI3sDDY+/KUZss0k=;
 b=EC8688o7bVrzAb3nsGDPqsnM4T0LxZafxGlTQ/CjlXU2GIOIAHT+9YTfIt+Q7geLM4
 w6IsZ/FRiwPZuzsMI1AVi1FPb6rjOrryp2Ks2IXMGo2hy+GsCL6RDw2nNvtGmJWd10qc
 VBdziMzFTa6GVJG0hHEnxg7AGhyUqJlJLcVWyEoCYe/mJoUlsvIylLRsnxS9A2dU8S2e
 /LWPYwQoszNwSkfZur79xp6RiAou7SyAQCpEia/E2NZvUxskZB949v6/nMbs4BAnJlwG
 4MBjK4ZlLtLpvXE/R7rQ5RzDQ6bIW1Tecfq8yAAWoG7DcWkycCpZbp/MKuEeZYMPbQZa
 LywA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1686215822; x=1688807822;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=HDCQAesq49wFWdH6l6xJB6jOa1uLI3sDDY+/KUZss0k=;
 b=K9/T116+D9jfQDjlJZThfQV5O5sn0w8WTP0DKdAJYMLF8Ab+NoVOJBy4dLZlUUAfZz
 vZmj4ocXabS4fZ//g4J1G0eecrhxGKA6t/AWgPBRZFnsTJlayMasQ9nzrmZxCikl/jii
 VKqUuU1qZmBrRQ1Psr2Csj3Xl+jzIJpTXK31tvNPmxjWVF0luikgRqILlNpCxqBdoTFm
 45u0fqqu2DSCleXOfhT1l8DZmEeWXoMsB3RRuBmrPbSnKI7u+slnvXWGUh4yoIzTWMyw
 kTGgOh6zuSwBguj2AAPQzkGbp2EAp/AtoM7Pxt92Aa+jtHXjFQwDPSxI7vuyK6m0xBKr
 sFhQ==
X-Gm-Message-State: AC+VfDwgcgAjVQtyVqzxaWad+j28F7yhULONnmR68EK/K8NkyiffcDQT
 2Kikeljpwiii1tbVtujy2X1ZSvLsjdR7aChNwaF4dkjo
X-Google-Smtp-Source: ACHHUZ7WFgZ3ehLr653TQzO3i4YLIJth6XBAHEFbPWaGD1A/1/QcPSBhrhCzHE47m7z098sGbUYhspfuaz3eHcWNu6M=
X-Received: by 2002:a17:907:961d:b0:977:b397:bbfa with SMTP id
 gb29-20020a170907961d00b00977b397bbfamr11094461ejc.6.1686215822473; Thu, 08
 Jun 2023 02:17:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
In-Reply-To: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Thu, 8 Jun 2023 11:16:26 +0200
Message-ID: <CAJBJmV_s_txnaSuZYNwBQv=VvbA6PdFzp7uEKnSNt40LCQDh=w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001d00c905fd9ab7b1"
X-Mailman-Approved-At: Thu, 08 Jun 2023 11:02:36 +0000
Subject: Re: [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: Thu, 08 Jun 2023 09:17:07 -0000

--0000000000001d00c905fd9ab7b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

In the proposal below, any annex that begins with `0x00` is defined as
free-form. This isn't the most efficient format though because there is
always one byte lost on signalling. In a future where unstructured annex
data turns out to be the predominant use case, this may be relevant. Also
for very short annexes, the lost byte may weigh relatively heavy.

Without sacrificing future extensions to structured annex data, one could
also store the annex data as is except for the case where the data starts
with `0x21` (or any other 'uncommon' byte). If the data starts with `0x21`,
this byte needs to be repeated first and then followed by the remainder of
the data.

Examples:

Data: [01 02 03]
Encoding [01 02 03]

Data: [21 22 23]
Encoding: [21 21 22 23]

The prefixes [21 (not 21)] are available for future upgrades.

Joost

On Fri, Jun 2, 2023 at 5:00=E2=80=AFPM Joost Jager <joost.jager@gmail.com> =
wrote:

> 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 dou=
bt
> 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 developer=
s
> 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 ou=
r
> 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 o=
f
> 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 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.
>
> Joost
>
> [1] https://github.com/bitcoin/bips/pull/1381
>

--0000000000001d00c905fd9ab7b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>In the proposal below, a=
ny annex that begins with `0x00` is defined as free-form. This isn&#39;t th=
e most efficient format though because there is always one byte lost on sig=
nalling. In a future where unstructured annex data turns out to be the pred=
ominant use case, this may be relevant. Also for very short annexes, the lo=
st byte may weigh relatively heavy.</div><div><br></div><div>Without sacrif=
icing future extensions to structured annex data, one could also store the =
annex data as is except for the case where the data starts with `0x21` (or =
any other &#39;uncommon&#39; byte). If the data starts with `0x21`, this by=
te needs to be repeated first and then followed by the remainder of the dat=
a.</div><div><br></div><div>Examples:</div><div><br></div><div>Data: [01 02=
 03]</div><div>Encoding [01 02 03]</div><div><br></div><div>Data: [21 22 23=
]</div><div>Encoding: [21 21 22 23]</div><div><br></div><div>The prefixes [=
21 (not 21)] are available for future upgrades.</div><div><br></div><div>Jo=
ost</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Fri, Jun 2, 2023 at 5:00=E2=80=AFPM Joost Jager &lt;<a href=3D"mailto=
:joost.jager@gmail.com">joost.jager@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>As=
 it stands, the taproot annex is consensus valid but non-standard. The conv=
ersations around standardization seem to be leaning towards the adoption of=
 a flexible Type-Length-Value (TLV) format [1]. There&#39;s no doubt that t=
his approach has considerable potential. However, settling on an exact form=
at may require a significant amount of time.<br><br>In the interim, the ben=
efits of making the annex available in a non-structured form are both evide=
nt and immediate. By allowing developers to utilize the taproot annex witho=
ut delay, we can take advantage of its features today, without the need to =
wait for the finalization of a more lengthy standardization process.<br><br=
>With this in view, I am proposing that we define any annex that begins wit=
h &#39;0&#39; as free-form, without any additional constraints. This strate=
gy offers several distinct benefits:<br><br>Immediate utilization: This ope=
ns the door for developers to make use of the taproot annex for a variety o=
f applications straight away, thus eliminating the need to wait for the imp=
lementation of TLV or any other structured format.<br><br>Future flexibilit=
y: Assigning &#39;0&#39;-beginning annexes as free-form keeps our options o=
pen for future developments and structure improvements. As we forge ahead i=
n determining the best way to standardize the annex, this strategy ensures =
we do not limit ourselves by setting its structure in stone prematurely.<br=
><br>Chainspace efficiency: Non-structured data may require fewer bytes com=
pared to a probable TLV format, which would necessitate the encoding of len=
gth even when there&#39;s only a single field. <br><br>In conclusion, adopt=
ing this approach will immediately broaden the utilization scope of the tap=
root annex while preserving the possibility of transitioning to a more stru=
ctured format in the future. I believe this is a pragmatic and efficient ro=
ute, one that can yield substantial benefits in both the short and long ter=
m.<br><br>Joost<br><br>[1] <a href=3D"https://github.com/bitcoin/bips/pull/=
1381" target=3D"_blank">https://github.com/bitcoin/bips/pull/1381</a></div>
</blockquote></div></div>

--0000000000001d00c905fd9ab7b1--