Note:

BIP-118 as-is= enables something similar to OP_PUSH_KEY_INTERNAL_TAGGED via the following= script fragment:

witness: <internal pk> <sig>

program: DUP 0x01 CHECKSIG SWAP DUP TOALTSTACK= =C2=A0CHECKSIG FROMALTSTACK

It's unclear how useful this might be, since the signature already co= vers the transaction.

On Wed, Jan 12, 2022 at 4:35 PM J= eremy <jlrubin@mit.edu> wrote:=

Hi Devs,

Two small transaction introspection opcodes that = are worth considering are OP_PUSH_KEY_INTERNAL or OP_PUSH_KEY_EXTERNAL whic= h can return the taproot key for the current input.

While the i= nternal key could be included in the tree already, and this is just a perfo= rmance improvement, the external key creates a hash cycle and is not possib= le to include directly.

=
This came up as a potential nicety whil= e looking at how BIP-118 "puns" a single 0x01 byte as a key argum= ent to refer to the Internal key for compactness. It would be more general = if instead of 0x01, there were an opcode that actually put the Internal key= on the stack.

There is a small incompatibility with BIP-118 wi= th this approach, which is that keys are not tagged for APO-enablement. Thu= s, there should either be a version of this opcode for APO tagged or not, o= r, APO should instead define some CheckSig2 which has APO if tagging is sti= ll desired. (Or we could abandon tagging keys too...)

It might = be worth pursuing simplifying APO to use these OP_PUSH_KEY opcodes because = future plans for more generalized covenant might benefit from being able to= get the current key off the stack. For example, TLUV might be able to be d= ecomposed into simpler (RISC) opcodes for getting the internal key, getting= the current merkel path, and then manipulating it, then tweaking the inter= nal key.

The internal key might be useful for signing in a path= not just for APO, but also because you might want to sign e.g. a transacti= on that is contingent on a HTLC scriptcode being satisfied. Because it is c= heaper to use the 0x01 CHECKSIG than doing a separate key (<pk> CHECK= SIG), it also causes an unintended side effect from APO of incentivizing no= t using a unique key per branch (privacy loss) and incentivizing enabling a= n APO tagged key where one is not required (unless 0x00, as I've noted = elsewhere is added to the 118 spec as a pun for an untagged key).

Pushing the external key's use is less obvious, but with the develop= ment of future opcodes it would be helpful for some recursive covenants.

Both opcodes are very design specific -- there's only one cho= ice of what data they could push.

Of course, we could keep 11= 8 spec'd as is, and add these PUSH_KEYs later if ever desired redundant= ly with the Checksig puns.

Cheers,

Jeremy

--
@JeremyRubin

--0000000000000fd38105d56cd8af--