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
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 720E5C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Oct 2022 06:12:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 4CA5A82690
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Oct 2022 06:12:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4CA5A82690
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=C95cLRh+
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 zbIkxGdmZvz5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Oct 2022 06:11:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 16C3781489
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
[IPv6:2607:f8b0:4864:20::d34])
by smtp1.osuosl.org (Postfix) with ESMTPS id 16C3781489
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Oct 2022 06:11:58 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id p186so7735412iof.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Oct 2022 23:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=RsaSfflBhpmSicJHjuqzB3rh5pGmzY/Kvo9QIs+fIoY=;
b=C95cLRh+rY6Wuz3yMXA26wnofRoDvxFBqbHIV4HrFC7xXDH9YPXCUKrQgMsShegM+g
FKY00+vIfhsAjMv20Gc83Par+lwYB4S/1rEBR64EdCWrS7lA+P9BJNt6QOa3uLcCZBBW
FQ9CYiW/MqJeJffhJI1Oi8Kmg8c5oDGEb5MS2FtAIQWZLhRO66SaEQJwo9F+BBgqlxpW
vbLfPKau12QeSv613h+1/YCfdLJvaz1KCGRIDftv9lYPaPhHfeJfaOsJ+lUj6gHrnggM
U1DW3gPmivY1Qbt1wGppow7iuVYikJdlxtBN+UcTtW2DuIThBafNnD62WKIiv1mmacUx
rNKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=RsaSfflBhpmSicJHjuqzB3rh5pGmzY/Kvo9QIs+fIoY=;
b=vi3zY80Yz0tliEDIGRASy85ZZp9m//+fM3V7XgKiaGm1H6xDuPs/P7VkNxxeLydAAa
M9h/oyonHRUkw4DjB4FJEwwKSrMtSS4S5suS+EB8o8Elio9vQQkwkeRhg56zprHPIr6N
XzjWOI0zQ7wI1FcpXZC+JgaLwl9xIjdToAVRozY/Wet3auFkekEE4WYN9xzG4SC1+6Cs
LGzxusd+uUq79KdeTYYAdaFH2JL42h1hox/whm4BbgDCUTUtbn9f8+IQ82CGlQoUJo4C
vTXE129P1OnHO5Szq7PXbyLgDiKkJL54pQ7xdudbSuttAvuD6P2+Zx5Frk/BZVQUJMky
Vtjg==
X-Gm-Message-State: ACrzQf0ke2KELjkFVgxQA8uOEEyCCvJOeF2zJvCK9hB6QggkV2bYK51s
d4dg2cIjSUxy+tFpnvgis1vkAdGiBW/fZBKf0Yx6R1H1bkLZjw==
X-Google-Smtp-Source: AMsMyM7a9ym52lckWvlaiVaBqsmDLk4ov8BYftMRxdrpo0osFf38sav1QoQInyeA738QXCV4I/9AjKxKZLRg53LtRIY=
X-Received: by 2002:a5e:d506:0:b0:6a4:b8b3:a6f0 with SMTP id
e6-20020a5ed506000000b006a4b8b3a6f0mr7799483iom.138.1665382317936; Sun, 09
Oct 2022 23:11:57 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 10 Oct 2022 02:11:47 -0400
Message-ID: <CALZpt+G2FRzhyZ4AtpJtvL0d1aASHc9ic_0jWTdyX154Y7svgw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000079d4cc05eaa80966"
X-Mailman-Approved-At: Mon, 10 Oct 2022 11:03:36 +0000
Subject: [bitcoin-dev] What has the Taproot Annex ever done for us ?
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: Mon, 10 Oct 2022 06:12:00 -0000
--00000000000079d4cc05eaa80966
Content-Type: text/plain; charset="UTF-8"
Hi,
Recent advances in the development of Eltoo Lightning channels have
envisioned the usage of the Taproot annex as a transaction endpoint where
to store specific protocol payload. [0] Further, during the past years,
some use-cases such as SIGHASH_GROUP/SIGHASH_BUNDLE have been proposed that
would require an extension of transaction fields. [1]. While there is
already the nSequence field serving as an endpoint for enforcement of new
consensus
semantics, the 32 bits of space doesn't allow multiple semantics to be
enforced on a transaction in a composable way. [2]
The Taproot softfork paved the way by introducing the annex, a tagged
element part of any SegWit v1 spends: "a reserved space for future
extensions".
This proposal introduces a Type-Length-Value format for the annex field,
motivated by its backward-compatibility and parsing straightforwardness.
There are a WIP implementation and a BIP available:
https://github.com/bitcoin-inquisition/bitcoin/pull/9
https://github.com/bitcoin/bips/pull/1381
For now, the proposal is minimal, seeking feedback in the TLV format is an
interesting direction. More advanced design questions are also open, like
what policy/consensus rules should be envisioned to prevent DoS of any kind
and how to make the annex field accessible to Script programmers (e.g
PUSH_ANNEX_RECORD).
Few use-cases could be served by the annex.
Per-input lock-time: as of today absolute timelocks are enforced at the
transaction level preventing aggregation of timelocked inputs by a
non-coordinating set of signers.
Commitment to historical block hash: signing the block hash could prevent a
transaction to be replayed or fee snipped in case of persistent forks.
Group of inputs/outputs: a group of input-outputs could be bundled and
signed together to enable non-interactive fee-bumping batching of off-chain
protocols.
Vectors of scriptPubkeys/amounts: within an off-chain protocol, a set of
signers can commit a priori to individual withdrawal ability, of which the
aggregation is enforced by the Script interpreter. [3]
The described use-cases are more whiteboard ideas than anything. It would
be interesting to dig in the archives of the ML and other Bitcoin research
venues, if there are forgotten requests of transaction fields extensions.
From my perspective, I would say there are years of R&D work, before the
annex can be considered ready for activation.
Detailing the annex format now could harmonize its usage by application
only leveraging policy-only enforcement of the field, without having
ulterior consensus validation nullifying or interfering with the use.
Cheers,
Antoine
[0]
https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[2] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
--00000000000079d4cc05eaa80966
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Recent advances in the development of Eltoo Lig=
htning channels have envisioned the usage of the Taproot annex as a transac=
tion endpoint where to store specific protocol payload. [0] Further, during=
the past years, some use-cases such as SIGHASH_GROUP/SIGHASH_BUNDLE have b=
een proposed that would require an extension of transaction fields. [1]. Wh=
ile there is already the nSequence field serving as an endpoint for enforce=
ment of new consensus<br>semantics, the 32 bits of space doesn't allow =
multiple semantics to be enforced on a transaction in a composable way. [2]=
<br><br>The Taproot softfork paved the way by introducing the annex, a tagg=
ed element part of any SegWit v1 spends: "a reserved space for future =
extensions".<br><br>This proposal introduces a Type-Length-Value forma=
t for the annex field, motivated by its backward-compatibility and parsing =
straightforwardness.<br><br>There are a WIP implementation and a BIP availa=
ble:<br><a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/9">h=
ttps://github.com/bitcoin-inquisition/bitcoin/pull/9</a><br><a href=3D"http=
s://github.com/bitcoin/bips/pull/1381">https://github.com/bitcoin/bips/pull=
/1381</a><br><br>For now, the proposal is minimal, seeking feedback in the =
TLV format is an interesting direction. More advanced design questions are =
also open, like what policy/consensus rules should be envisioned to prevent=
DoS of any kind and how to make the annex field accessible to Script progr=
ammers (e.g PUSH_ANNEX_RECORD).<br><br>Few use-cases could be served by the=
annex.<br><br>Per-input lock-time: as of today absolute timelocks are enfo=
rced at the transaction level preventing aggregation of timelocked inputs b=
y a non-coordinating set of signers.<br><br>Commitment to historical block =
hash: signing the block hash could prevent a transaction to be replayed or =
fee snipped in case of persistent forks.<br><br>Group of inputs/outputs: a =
group of input-outputs could be bundled and signed together to enable non-i=
nteractive fee-bumping batching of off-chain protocols.<br><br>Vectors of s=
criptPubkeys/amounts: within an off-chain protocol, a set of signers can co=
mmit a priori to individual withdrawal ability, of which the aggregation is=
enforced by the Script interpreter. [3]<br><br>The described use-cases are=
more whiteboard ideas than anything. It would be interesting to dig in the=
archives of the ML and other Bitcoin research venues, if there are forgott=
en requests of transaction fields extensions. From my perspective, I would =
say there are years of R&D work, before the annex can be considered rea=
dy for activation.<br><br>Detailing the annex format now could harmonize it=
s usage by application only leveraging policy-only enforcement of the field=
, without having ulterior consensus validation nullifying or interfering wi=
th the use.<br><br>Cheers,<br>Antoine<br><br>[0] <a href=3D"https://github.=
com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md">https://git=
hub.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md</a><br>[=
1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-=
July/019243.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
021-July/019243.html</a><br>[2] <a href=3D"https://github.com/bitcoin/bips/=
blob/master/bip-0068.mediawiki">https://github.com/bitcoin/bips/blob/master=
/bip-0068.mediawiki</a><br>[3] <a href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2022-February/019926.html">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-February/019926.html</a><br></div>
--00000000000079d4cc05eaa80966--
|