From: Brandon Black <freedom@reardencode•com>
To: Garlo Nicon <garlonicon@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: BIP for OP_INTERNALKEY
Date: Fri, 26 Apr 2024 09:03:09 -0700 [thread overview]
Message-ID: <ZivQPc0DRY3_rNj0@console> (raw)
In-Reply-To: <f95ca346-fc95-4cc7-9ded-1393e8dc827en@googlegroups.com>
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.
prev parent reply other threads:[~2024-04-26 16:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 5:22 [bitcoindev] " Brandon Black
2024-04-26 8:09 ` [bitcoindev] " Garlo Nicon
2024-04-26 16:03 ` Brandon Black [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZivQPc0DRY3_rNj0@console \
--to=freedom@reardencode$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=garlonicon@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox