Delivery-date: Fri, 26 Apr 2024 09:25:33 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 206.125.169.165 as permitted sender) client-ip=206.125.169.165;
Date: Fri, 26 Apr 2024 09:03:09 -0700
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
Message-ID: <ZivQPc0DRY3_rNj0@console>
References: <Zinohf1n8-aWN6G9@console>
 <f95ca346-fc95-4cc7-9ded-1393e8dc827en@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <f95ca346-fc95-4cc7-9ded-1393e8dc827en@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@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.