| BIN-2024-0003 | OP_INTERNALKEY |
|---|---|
| Revision | 001 (2024-01-27) |
| Author | Brandon Black <[email protected]> |
| Layer | Consensus (soft fork) |
| Status | Draft |
| License | BSD-3-CLAUSE |
| Discussion | https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/9 |
| Aliases | BIPs PR#1534 |
This BIP describes a new tapscript opcode (OP_INTERNALKEY) which
pushes the taproot internal key to the stack.
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.
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.
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.
A reference implementation is provided here:
https://github.com/brandonblack/bitcoin/commit/985e8c788d5e0f91802200044d31f9b86500255c
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.
TBD
Jeremy Rubin described most of the ideas for OP_INTERNALKEY to me.
This document is licensed under the 3-clause BSD license.