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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
|
Delivery-date: Fri, 26 Apr 2024 02:46:07 -0700
Received: from mail-yw1-f191.google.com ([209.85.128.191])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCY3VBMZVAMRBVXPVWYQMGQEZKV4PEI@googlegroups.com>)
id 1s0I9e-0005Ce-Hk
for bitcoindev@gnusha.org; Fri, 26 Apr 2024 02:46:07 -0700
Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-61aecbcb990sf33669967b3.1
for <bitcoindev@gnusha.org>; Fri, 26 Apr 2024 02:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1714124760; x=1714729560; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=2Yb7jFw+TmRh47Zr/Zhv5Zmy26Huwi4uhUh1R7Zn/9g=;
b=gGgTUErmjHaR4igyw+Q1i+KujnhubO/bYFQ7QwyuBjIHvS7/Ds4qARpaYPjO/nnrKN
xkEcJ+E6l8Tv7djDbUEbUq3G5ek2H/RXjpzPTq+hgUEpZPWK3L7eJq7cNEdWbbcbU3Il
hJKz4+9vqSFBOvJ6AgSLRT0DbbJvDo/w36lmSMG4i79s4hffSGaJxl3V6hgGtCgthDeu
J4B5rgqHguLgLwcVAYkEXlw9cPpnYRqmI684lncDoGp/H4/iwrnwOP5jva2TvUlEZLlR
8BmItqHT9XSUpYAiT28riAm0vW/zPS8WGGqaIsrYJ2X1UmY8KXsJ+rDChITDQDc9ms5m
GOZA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1714124760; x=1714729560; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=2Yb7jFw+TmRh47Zr/Zhv5Zmy26Huwi4uhUh1R7Zn/9g=;
b=Et9LTCw2I2v30hAO9wOM2ROZ5ySoGwJVF5IP4NOxXDvahXuZTWxJZ7fbdm9QfV0gmc
Xc7H6RnU3g/wVM60yMaGSj3G536mr1BYWbWol2u+RNztTcHH2wYCgCfnZa/jbHHlM8Yo
78AGRflrRGXq6JW99Tqh7AZdlMCVZ4oj3EB/N5Nq+y8HVG/F9pq41uDdBDEBbCd4xBuq
S13AyDXwrINSjdBSu0x1svY3ALjKNWUujKDR9ZNqh3YKwqvMLxw693jkmpB1O+yz9e2M
RMOC+kd36dDS3f+YuXIuU7sB4293gH/oitdUhwCIQQltiq1ms9IyO5b7zYf72O9jpKz5
6lNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1714124760; x=1714729560;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=2Yb7jFw+TmRh47Zr/Zhv5Zmy26Huwi4uhUh1R7Zn/9g=;
b=rDCXbXu913W0GzlUuSuGqInBeQ1AMxMklcmG+80GRUywcoWi6fljlt72vf26yzWq1i
mgAdN4v4oYcwzuKSivU/WnEXY6Seh9TYErgy2n7UDXJ9JMlH4q3+z4ff5N+4btDZgiL9
2rvT6HpeT3VC+TUZVM0aebNtrsPDivLp8Gp4TM3uiy+832sKOFbxMK02CVXHyocTITMT
qdqm5eArnlE82H5tUPw9I8fgGCPk9PCtaTxvM3kwRTxzoalBN/+2kebum8bm7WG/TXh4
+ky16cgIl86w9lUaEf0iRsYAKvaY4pZD5K0ccWdLymVSIV9ap6wglPF7gN+nONxWLQaH
E9ng==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUJ69ZxA6QDprK0MGKTXBMhhJFxdNfkPI4mVT0J65vpowBmdYvSUwfI6GeXCDE+4IEKWHk6I7tXuxKLM8RsyWSlJgj0AsY=
X-Gm-Message-State: AOJu0YyyYsWSXm/v68B6E42XyFyv/Y2xHsa9CjNxXl4bmhpSim98yeN1
JKw7OThiC2NPNUYv3vHvvLoVJ/TnmSDCCiKJeyrvXzH4FV8TPv8n
X-Google-Smtp-Source: AGHT+IHKDRpR8O6Y2R6OrIG1l74QCsOUd8t86Qn8C9zzV4EJ2mA8Rb37qhg8SqVqBzXl6gv/FW6G4A==
X-Received: by 2002:a25:8703:0:b0:de5:5037:8861 with SMTP id a3-20020a258703000000b00de550378861mr2154926ybl.48.1714124759942;
Fri, 26 Apr 2024 02:45:59 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:2748:0:b0:de5:49a0:e397 with SMTP id 3f1490d57ef6-de5861ea01dls355380276.2.-pod-prod-07-us;
Fri, 26 Apr 2024 02:45:58 -0700 (PDT)
X-Received: by 2002:a0d:dd0d:0:b0:61b:737:1a86 with SMTP id g13-20020a0ddd0d000000b0061b07371a86mr472964ywe.10.1714124758365;
Fri, 26 Apr 2024 02:45:58 -0700 (PDT)
Received: by 2002:a05:690c:9:b0:61a:e84a:c592 with SMTP id 00721157ae682-61ba917c6bbms7b3;
Fri, 26 Apr 2024 01:09:25 -0700 (PDT)
X-Received: by 2002:a05:6902:20ca:b0:de4:6624:b763 with SMTP id dj10-20020a05690220ca00b00de46624b763mr695633ybb.0.1714118964532;
Fri, 26 Apr 2024 01:09:24 -0700 (PDT)
Date: Fri, 26 Apr 2024 01:09:24 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f95ca346-fc95-4cc7-9ded-1393e8dc827en@googlegroups.com>
In-Reply-To: <Zinohf1n8-aWN6G9@console>
References: <Zinohf1n8-aWN6G9@console>
Subject: [bitcoindev] Re: BIP for OP_INTERNALKEY
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_444_1130141159.1714118964184"
X-Original-Sender: garlonicon@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_444_1130141159.1714118964184
Content-Type: multipart/alternative;
boundary="----=_Part_445_1334399062.1714118964184"
------=_Part_445_1334399062.1714118964184
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I wonder, what is the reason to pick 0xcb as OP_INTERNALKEY, when we had=20
pseudo-words OP_PUBKEY (assigned to 0xfe) and OP_PUBKEYHASH (assigned to=20
0xfd). Of course, those opcodes are invalid in the non-Taproot scripts, but=
=20
they were intended to be used in cases like "OP_PUBKEY OP_CHECKSIG", and=20
"OP_DUP OP_HASH160 OP_PUBKEYHASH OP_EQUALVERIFY OP_CHECKSIG". So, I guess=
=20
we could reuse those opcodes, and make it a general rule, that OP_PUBKEY=20
picks the next key from the stack (which in this specific case will give us=
=20
the internal key, but I can imagine leaving some room for extending it in=
=20
the future, with scripts like "OP_PUBKEY OP_CHECKSIGVERIFY OP_PUBKEY=20
OP_CHECKSIG", where each of those OP_PUBKEYs will give us a different key,=
=20
and act somewhat like OP_FROMALTSTACK, but working on a separate stack of=
=20
public keys instead, where the first key of that stack would be the=20
internal Taproot key).
czwartek, 25 kwietnia 2024 o 12:41:04 UTC+2 Brandon Black napisa=C5=82(a):
> Hello list,
>
> I'm currently failing to find the original reference discussion for
> adding OP_INTERNALKEY to tapscript. I believe it was in the context of
> the SIGHASH_ANYPREVOUT proposal which opted instead to access the
> internalkey as a special key with value `0x01`. Regardless, here[0] is a
> BIP for adding OP_INTERNALKEY to tapscript to allow access to the
> taproot internal key. As noted below, this helps certain classes of
> script come closer to matching segwitv0 in byte efficiency, which can be
> particularly useful for protocols such as Lightning where the same
> signers may need to sign a script path in some cases, and a key path in
> others.
>
> ------------
> ## Abstract
>
> This BIP describes a new tapscript opcode (`OP_INTERNALKEY`) which
> pushes the taproot internal key to the stack.
>
> ## Specification
>
> When verifying taproot script spends having leaf version `0xc0` (as
> defined in [BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb).
> `OP_INTERNALKEY` pushes the taproot internal key, as defined in [BIP
> 341], to the stack.
>
> ## Motivation
>
> ### Key spend with additional conditions
>
> When building taproot outputs, especially those secured by an aggregate
> key representing more than one signer, the parties may wish to
> collaborate on signing with the taproot internal key, but only with
> additional script restrictions. In this case, `OP_INTERNALKEY` saves 8
> vBytes.
>
> ### Mitigated control block overhead for scripts using hash locks
>
> In cases where script path spending is not desired, the internal key may
> be set to a NUMS point whose bytes would otherwise be required in a
> tapscript. This could be used with any hash locked transaction, for
> example, to save 8 vBytes.
>
> Note: The internal key must be the X coordinate of a point on the
> SECP256K1 curve, so any such hash must be checked and modified until it
> is such an X coordinate. This will typically take approximately 2
> attempts.
>
> ## Reference Implementation
>
> A reference implementation is provided here:
>
> https://github.com/bitcoin/bitcoin/pull/29269
>
> ## Backward Compatibility
>
> By constraining the behavior of an OP_SUCCESS opcode, deployment of the
> BIP can be done in a backwards compatible, soft-fork manner. If anyone
> were to rely on the OP_SUCCESS behavior of `OP_SUCCESS203`,
> `OP_INTERNALKEY` would invalidate their spend.
>
> ## Deployment
>
> TBD
>
> ## Copyright
>
> This document is licensed under the 3-clause BSD license.
>
> [BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
>
> [BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
>
> ------------
>
> [0]: https://github.com/bitcoin/bips/pull/1534
>
> --=20
> --Brandon
>
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/f95ca346-fc95-4cc7-9ded-1393e8dc827en%40googlegroups.com.
------=_Part_445_1334399062.1714118964184
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I wonder, what is the reason to pick 0xcb as OP_INTERNALKEY, when we had ps=
eudo-words OP_PUBKEY (assigned to 0xfe) and OP_PUBKEYHASH (assigned to 0xfd=
). Of course, those opcodes are invalid in the non-Taproot scripts, but the=
y were intended to be used in cases like "OP_PUBKEY OP_CHECKSIG", and "OP_D=
UP OP_HASH160 OP_PUBKEYHASH OP_EQUALVERIFY OP_CHECKSIG". So, I guess we cou=
ld reuse those opcodes, and make it a general rule, that OP_PUBKEY picks th=
e next key from the stack (which in this specific case will give us the int=
ernal key, but I can imagine leaving some room for extending it in the futu=
re, with scripts like "OP_PUBKEY OP_CHECKSIGVERIFY OP_PUBKEY OP_CHECKSIG", =
where each of those OP_PUBKEYs will give us a different key, and act somewh=
at like OP_FROMALTSTACK, but working on a separate stack of public keys ins=
tead, where the first key of that stack would be the internal Taproot key).=
<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att=
r">czwartek, 25 kwietnia 2024 o=C2=A012:41:04 UTC+2 Brandon Black napisa=C5=
=82(a):<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello=
list,
<br>
<br>I'm currently failing to find the original reference discussion for
<br>adding OP_INTERNALKEY to tapscript. I believe it was in the context of
<br>the SIGHASH_ANYPREVOUT proposal which opted instead to access the
<br>internalkey as a special key with value `0x01`. Regardless, here[0] is =
a
<br>BIP for adding OP_INTERNALKEY to tapscript to allow access to the
<br>taproot internal key. As noted below, this helps certain classes of
<br>script come closer to matching segwitv0 in byte efficiency, which can b=
e
<br>particularly useful for protocols such as Lightning where the same
<br>signers may need to sign a script path in some cases, and a key path in
<br>others.
<br>
<br>------------
<br>## Abstract
<br>
<br>This BIP describes a new tapscript opcode (`OP_INTERNALKEY`) which
<br>pushes the taproot internal key to the stack.
<br>
<br>## Specification
<br>
<br>When verifying taproot script spends having leaf version `0xc0` (as
<br>defined in [BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb)=
.
<br>`OP_INTERNALKEY` pushes the taproot internal key, as defined in [BIP
<br>341], to the stack.
<br>
<br>## Motivation
<br>
<br>### Key spend with additional conditions
<br>
<br>When building taproot outputs, especially those secured by an aggregate
<br>key representing more than one signer, the parties may wish to
<br>collaborate on signing with the taproot internal key, but only with
<br>additional script restrictions. In this case, `OP_INTERNALKEY` saves 8
<br>vBytes.
<br>
<br>### Mitigated control block overhead for scripts using hash locks
<br>
<br>In cases where script path spending is not desired, the internal key ma=
y
<br>be set to a NUMS point whose bytes would otherwise be required in a
<br>tapscript. This could be used with any hash locked transaction, for
<br>example, to save 8 vBytes.
<br>
<br>Note: The internal key must be the X coordinate of a point on the
<br>SECP256K1 curve, so any such hash must be checked and modified until it
<br>is such an X coordinate. This will typically take approximately 2
<br>attempts.
<br>
<br>## Reference Implementation
<br>
<br>A reference implementation is provided here:
<br>
<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/29269" target=3D"_bl=
ank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dpl&q=3Dhttps://github.com/bitcoin/bitcoin/pull/29269&source=3Dgm=
ail&ust=3D1714205107710000&usg=3DAOvVaw0EIGv1oOopk7PqwR-n62pQ">http=
s://github.com/bitcoin/bitcoin/pull/29269</a>
<br>
<br>## Backward Compatibility
<br>
<br>By constraining the behavior of an OP_SUCCESS opcode, deployment of the
<br>BIP can be done in a backwards compatible, soft-fork manner. If anyone
<br>were to rely on the OP_SUCCESS behavior of `OP_SUCCESS203`,
<br>`OP_INTERNALKEY` would invalidate their spend.
<br>
<br>## Deployment
<br>
<br>TBD
<br>
<br>## Copyright
<br>
<br>This document is licensed under the 3-clause BSD license.
<br>
<br>[BIP 341]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0=
341.mediawiki" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Dpl&q=3Dhttps://github.com/bitcoin/bips/b=
lob/master/bip-0341.mediawiki&source=3Dgmail&ust=3D1714205107710000=
&usg=3DAOvVaw3HHO8SoKw1IuSF4f25Z1-E">https://github.com/bitcoin/bips/bl=
ob/master/bip-0341.mediawiki</a>
<br>
<br>[BIP 342]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0=
342.mediawiki" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Dpl&q=3Dhttps://github.com/bitcoin/bips/b=
lob/master/bip-0342.mediawiki&source=3Dgmail&ust=3D1714205107710000=
&usg=3DAOvVaw3i9eBTO1dR8MYSKHpiNoz9">https://github.com/bitcoin/bips/bl=
ob/master/bip-0342.mediawiki</a>
<br>
<br>------------
<br>
<br>[0]: <a href=3D"https://github.com/bitcoin/bips/pull/1534" target=3D"_b=
lank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?h=
l=3Dpl&q=3Dhttps://github.com/bitcoin/bips/pull/1534&source=3Dgmail=
&ust=3D1714205107710000&usg=3DAOvVaw2Rj7ViXqyggaPQKX5WXIUY">https:/=
/github.com/bitcoin/bips/pull/1534</a>
<br>
<br>--=20
<br>--Brandon
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/f95ca346-fc95-4cc7-9ded-1393e8dc827en%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/f95ca346-fc95-4cc7-9ded-1393e8dc827en%40googlegroups.com</a>.=
<br />
------=_Part_445_1334399062.1714118964184--
------=_Part_444_1130141159.1714118964184--
|
