* [bitcoindev] BIP for OP_INTERNALKEY
@ 2024-04-25 5:22 Brandon Black
2024-04-26 8:09 ` [bitcoindev] " Garlo Nicon
0 siblings, 1 reply; 3+ messages in thread
From: Brandon Black @ 2024-04-25 5:22 UTC (permalink / raw)
To: bitcoindev
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
--
--Brandon
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zinohf1n8-aWN6G9%40console.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: BIP for OP_INTERNALKEY
2024-04-25 5:22 [bitcoindev] BIP for OP_INTERNALKEY Brandon Black
@ 2024-04-26 8:09 ` Garlo Nicon
2024-04-26 16:03 ` Brandon Black
0 siblings, 1 reply; 3+ messages in thread
From: Garlo Nicon @ 2024-04-26 8:09 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 4224 bytes --]
I wonder, what is the reason to pick 0xcb as OP_INTERNALKEY, when we had
pseudo-words OP_PUBKEY (assigned to 0xfe) and OP_PUBKEYHASH (assigned to
0xfd). Of course, those opcodes are invalid in the non-Taproot scripts, but
they were intended to be used in cases like "OP_PUBKEY OP_CHECKSIG", and
"OP_DUP OP_HASH160 OP_PUBKEYHASH OP_EQUALVERIFY OP_CHECKSIG". So, I guess
we could reuse those opcodes, and make it a general rule, that OP_PUBKEY
picks the next key from the stack (which in this specific case will give us
the internal key, but I can imagine leaving some room for extending it in
the future, 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 somewhat like OP_FROMALTSTACK, but working on a separate stack of
public keys instead, where the first key of that stack would be the
internal Taproot key).
czwartek, 25 kwietnia 2024 o 12:41:04 UTC+2 Brandon Black napisał(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
>
> --
> --Brandon
>
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 6033 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Re: BIP for OP_INTERNALKEY
2024-04-26 8:09 ` [bitcoindev] " Garlo Nicon
@ 2024-04-26 16:03 ` Brandon Black
0 siblings, 0 replies; 3+ messages in thread
From: Brandon Black @ 2024-04-26 16:03 UTC (permalink / raw)
To: Garlo Nicon; +Cc: Bitcoin Development Mailing List
Hi Garlo, thanks for your thoughts!
On 2024-04-26 (Fri) at 01:09:24 -0700, Garlo Nicon wrote:
> I wonder, what is the reason to pick 0xcb as OP_INTERNALKEY,
The choice of 0xcb was fairly arbitrary. An early draft had used another
OP_SUCCESS but we moved to 0xcb to avoid conflict with BIP345.
> when we had pseudo-words OP_PUBKEY (assigned to 0xfe) and
> OP_PUBKEYHASH (assigned to 0xfd).
Given that OP_PUBKEY was never an actual opcode, reusing that
pseudo-word for this purpose seems more confusing than beneficial.
> So, I guess we could reuse those opcodes, and make it a general rule,
> that OP_PUBKEY picks the next key from the stack (which in this
> specific case will give us the internal key, but I can imagine leaving
> some room for extending it in the future, 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 somewhat like
> OP_FROMALTSTACK, but working on a separate stack of public keys
> instead, where the first key of that stack would be the internal
> Taproot key).
In terms of creating a stack of pubkeys which can be accessed
sequentially in script, the only two keys I can see that being used for
are the taproot internal key and the taproot external key. Any other
keys will already explicitly appear in the script being validated. An
alternative design could be OP_TAPKEY which can be called up to two
times in script, first pushing the internal key and then pushing the
external key. My inclination here is that if a case can be made for
accessing both of these keys, 2 separate opcodes that repeatedly push
the same key is more ergonomic for script developers than 1 opcode that
pushes internal, then external, (then fails?). I'd even opt for
OP_TAPKEYS that pushes both keys and the script can then DROP or NIP
away the one they don't need over a stack of keys.
Best,
--Brandon
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZivQPc0DRY3_rNj0%40console.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-26 16:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-25 5:22 [bitcoindev] BIP for OP_INTERNALKEY Brandon Black
2024-04-26 8:09 ` [bitcoindev] " Garlo Nicon
2024-04-26 16:03 ` Brandon Black
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox