Add bip-internalkey #1534
Add bip-internalkey #1534
Conversation
reardencode
force-pushed
the
internalkey
branch
from
4d448cc
to
a24aca4
Compare
bip-internalkey.mediawiki
Outdated
|
|
||
| When building taproot outputs, especially those secured by an aggregate key | ||
| representing more than 1 signer; the parties may wish to collaborate on signing | ||
| with the taproot internal key, but only with additional script restrictions. In |
There was a problem hiding this comment.
Can you give an example where using the key path with an aggregate key and having every participant enforce the additional restrictions themselves (i.e. only signing if they're met) wouldn't suffice?
There was a problem hiding this comment.
The most obvious case would be lightning symmetry where the parties want to pre-sign with CTV+CSFS to create a rebindable update transaction.
reardencode
force-pushed
the
internalkey
branch
2 times, most recently
from
c9842c4
to
729276c
Compare
|
Updated to match the BIN. |
jonatack
added
Needs number assignment
New BIP
and removed
Needs number assignment
labels
reardencode
force-pushed
the
internalkey
branch
3 times, most recently
from
978f4cd
to
efd4bd9
Compare
murchandamus
added
the
PR Author action required
| [BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb). `OP_INTERNALKEY` | ||
| pushes the taproot internal key, as defined in [BIP 341], to the stack. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Additional useful feature: ability to inspect the tweak to a key (in combination with some OP_TWEAKVERIFY).
There was a problem hiding this comment.
That would require additional introspection beyond just INTERNALKEY too, wouldn't it?
There was a problem hiding this comment.
Yes, something like TWEAKADD or TWEAKVERIFY.
|
|
||
| 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. |
There was a problem hiding this comment.
nit: might be nice to mark "taproot internal key" as a formal term, either by italicizing, backticks or the like. I find that marking terms that invoke a suite of definitions and properties is really helpful. We do it a lot in the BOLTs and I'd recommend doing it in the BIPs as much as we can.
|
|
||
| ## Specification | ||
|
|
||
| When verifying taproot script spends having leaf version `0xc0` (as defined in |
There was a problem hiding this comment.
| When verifying taproot script spends having leaf version `0xc0` (as defined in | |
| When verifying taproot script path spends having leaf version `0xc0` (as defined in |
| 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. |
There was a problem hiding this comment.
Perhaps you could elaborate how OP_INTERNALKEY would save 8 vB, for example in a footnote. (I assume it’s an x-only key of 32 bytes, and otherwise you’d need a PUSH and the 32 bytes, but with OP_INTERNALKEY you only need only that one byte instead. But if I had to think about that, maybe others would also appreciate an explanation.
|
|
||
| ### Mitigated control block overhead for scripts using hash locks | ||
|
|
||
| In cases where script path spending is not desired, the internal key may be set |
There was a problem hiding this comment.
Did you mean:
| In cases where script path spending is not desired, the internal key may be set | |
| In cases where key path spending is not desired, the internal key may be set |
|
|
||
| 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. |
There was a problem hiding this comment.
It seems to me that this should be perhaps a bit more specific what exactly is being pushed to the stack. I assume this is referring to
Let p = c[1:33] and let P = lift_x(int(p)) where lift_x and [:] are defined as in BIP340. Fail if this point is not on the curve. […] q is referred to as taproot output key and p as taproot internal key.
but it would not hurt to clarify.
OP_INTERNALKEY is a new BIP342 tapscript only opcode (upgraded using OP_SUCCESS semantics) that takes bytes 1-32 (0-index, inclusive) from the BIP341 taproot control block and places them on the stack. This BIP describes that behavior.