Delivery-date: Fri, 26 Apr 2024 02:46:07 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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&#39;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&amp;q=3Dhttps://github.com/bitcoin/bitcoin/pull/29269&amp;source=3Dgm=
ail&amp;ust=3D1714205107710000&amp;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&amp;q=3Dhttps://github.com/bitcoin/bips/b=
lob/master/bip-0341.mediawiki&amp;source=3Dgmail&amp;ust=3D1714205107710000=
&amp;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&amp;q=3Dhttps://github.com/bitcoin/bips/b=
lob/master/bip-0342.mediawiki&amp;source=3Dgmail&amp;ust=3D1714205107710000=
&amp;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&amp;q=3Dhttps://github.com/bitcoin/bips/pull/1534&amp;source=3Dgmail=
&amp;ust=3D1714205107710000&amp;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&quot; 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--