Add BIP 349: OP_INTERNALKEY #1534
pull reardencode wants to merge 5 commits into bitcoin:master from reardencode:internalkey changing 2 files +79 −0-
reardencode commented at 6:30 pm on January 7, 2024: contributorOP_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.
-
reardencode force-pushed on Jan 13, 2024
-
in bip-internalkey.mediawiki:31 in a24aca432c outdated
26+ 27+===Key spend with additional conditions=== 28+ 29+When building taproot outputs, especially those secured by an aggregate key 30+representing more than 1 signer; the parties may wish to collaborate on signing 31+with the taproot internal key, but only with additional script restrictions. In
vostrnad commented at 1:51 am on January 17, 2024: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?
reardencode commented at 10:06 pm on January 19, 2024:The most obvious case would be lightning symmetry where the parties want to pre-sign with CTV+CSFS to create a rebindable update transaction.in bip-internalkey.mediawiki:39 in a24aca432c outdated
34+===Mitigated control block overhead for scripts using hash locks=== 35+ 36+In cases where script path spending is not desired, the internal key may be set 37+to a NUMS point whose bytes would otherwise be required in a tapscript. This 38+could be used with any hash locked transaction, for example, to save 32 witness 39+bytes.
vostrnad commented at 7:35 pm on January 19, 2024:The internal key needs to correspond to a point on the secp256k1 curve, so how can this be used with “any hash locked transaction”?
reardencode commented at 10:05 pm on January 19, 2024:Yeah, I need to tighten up this language. In a typical case it will take about 2 tries to find a hash that is on the curve. For hash locks, a next preimage can be derived if the first does not hash to an X on the curve; for CTV locks, the template transaction can be modified in some slight protocol-compatible way to get a hash that is also an X on the curve.reardencode force-pushed on Apr 24, 2024reardencode force-pushed on Apr 24, 2024reardencode commented at 9:59 pm on April 24, 2024: contributorUpdated to match the BIN.jonatack added the label Needs number assignment on Apr 24, 2024jonatack removed the label Needs number assignment on Apr 24, 2024jonatack added the label New BIP on Apr 24, 2024jonatack added the label Needs number assignment on Apr 24, 2024reardencode force-pushed on Apr 25, 2024reardencode force-pushed on Apr 25, 2024reardencode force-pushed on Apr 25, 2024in bip-internalkey.md:9 in efd4bd9ebd outdated
0@@ -0,0 +1,68 @@ 1+| BIP-XXXX | `OP_INTERNALKEY` 2+| :--------- | :--------------- 3+| Layer | Consensus (soft fork) 4+| Author | Brandon Black `<freedom@reardencode.com>`, Jeremy Rubin `<j@rubin.io>` 5+| Discussion | https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/9 6+| Status | Draft 7+| Type | Standards Track 8+| Created | 2023-12-22 9+| License | BSD-3-Clause
murchandamus commented at 7:12 pm on May 1, 2024:Please use the preamble format specified in BIP2.
Instead of “BIP-XXXX” there should be a “BIP” header. The “Title” header is missing, the “Comments-URI” header is missing, and “Discussion” should be “Post-History”.
murchandamus commented at 7:16 pm on May 1, 2024: contributorHas this proposal been discussed on the mailing list?murchandamus added the label PR Author action required on May 8, 2024in bip-internalkey.md:24 in efd4bd9ebd outdated
17+ 18+When verifying taproot script spends having leaf version `0xc0` (as defined in 19+[BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb). `OP_INTERNALKEY` 20+pushes the taproot internal key, as defined in [BIP 341], to the stack. 21+ 22+## Motivation
halseth commented at 8:27 am on May 13, 2024:Additional useful feature: ability to inspect the tweak to a key (in combination with some OP_TWEAKVERIFY).
reardencode commented at 9:46 pm on May 14, 2024:That would require additional introspection beyond just INTERNALKEY too, wouldn’t it?
halseth commented at 6:49 am on May 15, 2024:Yes, something like TWEAKADD or TWEAKVERIFY.reardencode force-pushed on May 14, 2024in bip-internalkey.md:22 in e7dfa7eaef outdated
17+ 18+## Specification 19+ 20+When verifying taproot script spends having leaf version `0xc0` (as defined in 21+[BIP 342]), `OP_INTERNALKEY` replaces `OP_SUCCESS203` (0xcb). `OP_INTERNALKEY` 22+pushes the taproot internal key, as defined in [BIP 341], to the stack.
ProofOfKeags commented at 7:14 pm on May 22, 2024: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.
murchandamus commented at 7:42 pm on May 22, 2024: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.
moonsettler commented at 10:13 pm on November 12, 2024:“the taproot internal key denoted as P in [BIP 341]”?
murchandamus commented at 4:25 pm on November 14, 2024:My point is that the “taproot internal key” refers to an abstract object in BIP 341 that is denoted as p:
“q is referred to as taproot output key and p as taproot internal key.”
and it wouldn’t hurt to simply describe what you are referring to, instead of sending people to parse another BIP to get clued in.
How about:
“pushes the 32-byte x-only representation P of the taproot internal key p, as defined in [BIP 341], to the stack.”
moonsettler commented at 4:41 pm on November 14, 2024:How about?
When verifying taproot script path spends having leaf version
0xc0
(as defined in [BIP 342]),OP_INTERNALKEY
replacesOP_SUCCESS203
(0xcb).OP_INTERNALKEY
pushes the 32-byte x-only representation (referred to as P) of the taproot internal key (referred to as p), as defined in [BIP 341], to the stack.
vostrnad commented at 4:48 pm on November 14, 2024:Note that BIP341 already defines the taproot internal key p (note the lowercase) as a 32-byte array (as opposed to, say, a point on the secp256k1 curve), so it’s not necessary to reinterpret it in any way before pushing it to the stack.
murchandamus commented at 4:56 pm on November 14, 2024:If others feel that this passage is sufficiently clear, I don’t feel strongly about it.
moonsettler commented at 4:59 pm on November 14, 2024:So then:
When verifying taproot script path spends having leaf version
0xc0
(as defined in [BIP 342]),OP_INTERNALKEY
replacesOP_SUCCESS203
(0xcb).OP_INTERNALKEY
pushes the 32-byte taproot internal key (referred to as p), as defined in [BIP 341], to the stack.?
vostrnad commented at 5:34 pm on November 14, 2024:Yes, we can add the “32-byte” qualifier for additional clarity. I would use slightly different phrasing, but that’s just a suggestion:
When verifying taproot script path spends having leaf version
0xc0
(as defined in [BIP 342]),OP_INTERNALKEY
replacesOP_SUCCESS203
(0xcb
).OP_INTERNALKEY
pushes the 32-byte taproot internal key p, as defined in [BIP 341], to the stack.
moonsettler commented at 5:48 pm on November 14, 2024:I find it weird that both taproot internal key and p are in italic and together like that. No hard preference just feels off somehow!
vostrnad commented at 5:54 pm on November 14, 2024:I understand that, but it’s not unprecedented, for example in BIP341 you’ll find “annex a”. Also notice that they’re in separate italic blocks, even though you can’t tell from the rendered version.in bip-internalkey.md:20 in e7dfa7eaef outdated
15+This BIP describes a new tapscript opcode (`OP_INTERNALKEY`) which 16+pushes the taproot internal key to the stack. 17+ 18+## Specification 19+ 20+When verifying taproot script spends having leaf version `0xc0` (as defined in
murchandamus commented at 7:16 pm on May 22, 2024:0When verifying taproot script path spends having leaf version `0xc0` (as defined in
in bip-internalkey.md:31 in e7dfa7eaef outdated
26+### Key spend with additional conditions 27+ 28+When building taproot outputs, especially those secured by an aggregate key 29+representing more than one signer, the parties may wish to collaborate on 30+signing with the taproot internal key, but only with additional script 31+restrictions. In this case, `OP_INTERNALKEY` saves 8 vBytes.
murchandamus commented at 7:20 pm on May 22, 2024:Perhaps you could elaborate howOP_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 withOP_INTERNALKEY
you only need only that one byte instead. But if I had to think about that, maybe others would also appreciate an explanation.in bip-internalkey.md:35 in e7dfa7eaef outdated
30+signing with the taproot internal key, but only with additional script 31+restrictions. In this case, `OP_INTERNALKEY` saves 8 vBytes. 32+ 33+### Mitigated control block overhead for scripts using hash locks 34+ 35+In cases where script path spending is not desired, the internal key may be set
murchandamus commented at 7:22 pm on May 22, 2024:Did you mean:
0In cases where key path spending is not desired, the internal key may be set
murchandamus commented at 7:51 pm on May 22, 2024: contributorThis seems close to ready for a merge, although I am wondering whether it has gotten enough review from the community. I noticed that both this PR and the mailing list thread were not that active.Starco1001 approvedmoonsettler commented at 10:05 pm on November 11, 2024: contributorSo what exactly needs to be done to get this BIP unstuck?murchandamus commented at 9:17 pm on November 12, 2024: contributorThere do seem to be several unaddressed review comments. Happy to review again when the open review comments have been addressed.murchandamus commented at 5:00 pm on November 14, 2024: contributorLet’s call this BIP 349. Could you please rename the file, add the number to the preamble, and update the README table accordingly?murchandamus removed the label Needs number assignment on Nov 14, 2024murchandamus renamed this:
Add bip-internalkey
Add BIP 349: OP_INTERNALKEY
on Nov 14, 2024in bip-0349.md:11 in 4a8049fd7b outdated
6+Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0349 7+Status: Draft 8+Type: Standards Track 9+Created: 2023-12-22 10+License: BSD-3-Clause 11+```
murchandamus commented at 8:41 pm on November 14, 2024:I think these changes should make the CI pass:
- use
<pre>
and</pre>
instead of ``` - put each author on a separate line
I also suggest updating the date in the Created header to the day that the proposal was assigned a number as that’s the meaning of the field according to BIP 2.
0<pre> 1 BIP: 349 2 Layer: Consensus (soft fork) 3 Title: OP_INTERNALKEY 4 Author: Brandon Black <freedom@reardencode.com> 5 Jeremy Rubin <j@rubin.io> 6 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0349 7 Status: Draft 8 Type: Standards Track 9 Created: 2024-11-14 10 License: BSD-3-Clause 11</pre>
murchandamus commented at 8:42 pm on November 14, 2024: contributorCI isn’t passing, I think the problem are two little issues with the Preamble.Add bip-internalkey 75351f2587Fixes and clarifications to address PR comments b35383b68fBIP-349 329b0d3db5murchandamus force-pushed on Nov 14, 2024murchandamus removed the label PR Author action required on Nov 14, 2024BIP349: Fix preamble for CI issues 669d3b3570BIP349: Set Created header to number assignment 217ae0dfa8murchandamus force-pushed on Nov 14, 2024reardencode commented at 9:38 pm on November 14, 2024: contributorThanks @murchandamus !murchandamus commented at 9:38 pm on November 14, 2024: contributorI updated the Preamble formatting:
- Move authors to separate lines
- Use
<pre>
formatting - Correct the background color in README table
- Updated the “Created” header to use the date of the number assignment as prescribed by BIP 2.
This should now be good to go unless you wanted to make more changes before it is merged.
murchandamus merged this on Nov 25, 2024murchandamus closed this on Nov 25, 2024
allysa08 approved
github-metadata-mirror
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-26 18:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me