Author: Jeremy 2022-01-13 00:35:19
Published on: 2022-01-13T00:35:19+00:00
The author proposes the consideration of two small transaction introspection opcodes, OP_PUSH_KEY_INTERNAL or OP_PUSH_KEY_EXTERNAL, which could return the taproot key for the current input. While the internal key could be included in the tree already, and this is just a performance improvement, the external key creates a hash cycle and is not possible to include directly. The proposal was made to create a more general approach where instead of using a single 0x01 byte as a key argument to refer to the Internal key for compactness, an opcode would actually put the Internal key on the stack. There is a small incompatibility with BIP-118 with this approach, which is that keys are not tagged for APO-enablement. Thus, there should either be a version of this opcode for APO tagged or not, or APO should instead define some CheckSig2 which has APO if tagging is still desired. 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. The internal key might be useful for signing in a path not just for APO, but also because you might want to sign a transaction that is contingent on a HTLC scriptcode being satisfied. Pushing the external key's use is less obvious, but with the development of future opcodes it would be helpful for some recursive covenants. Both opcodes are very design specific -- there's only one choice of what data they could push.
Updated on: 2023-05-22T16:33:06.371038+00:00