Add BIP 349: OP_INTERNALKEY #1534

pull reardencode wants to merge 5 commits into bitcoin:master from reardencode:internalkey changing 2 files +79 −0
  1. reardencode commented at 6:30 pm on January 7, 2024: none
    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.
  2. reardencode force-pushed on Jan 13, 2024
  3. 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.
  4. 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.
  5. reardencode force-pushed on Apr 24, 2024
  6. reardencode force-pushed on Apr 24, 2024
  7. reardencode commented at 9:59 pm on April 24, 2024: none
    Updated to match the BIN.
  8. jonatack added the label Needs number assignment on Apr 24, 2024
  9. jonatack removed the label Needs number assignment on Apr 24, 2024
  10. jonatack added the label New BIP on Apr 24, 2024
  11. jonatack added the label Needs number assignment on Apr 24, 2024
  12. reardencode force-pushed on Apr 25, 2024
  13. reardencode force-pushed on Apr 25, 2024
  14. reardencode force-pushed on Apr 25, 2024
  15. in 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”.

  16. murchandamus commented at 7:16 pm on May 1, 2024: contributor
    Has this proposal been discussed on the mailing list?
  17. murchandamus added the label PR Author action required on May 8, 2024
  18. in 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.
  19. reardencode force-pushed on May 14, 2024
  20. in 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 replaces OP_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 replaces OP_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 replaces OP_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.
  21. 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
  22. 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 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.
  23. 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
  24. murchandamus commented at 7:51 pm on May 22, 2024: contributor
    This 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.
  25. Starco1001 approved
  26. moonsettler commented at 10:05 pm on November 11, 2024: none
    So what exactly needs to be done to get this BIP unstuck?
  27. murchandamus commented at 9:17 pm on November 12, 2024: contributor
    There do seem to be several unaddressed review comments. Happy to review again when the open review comments have been addressed.
  28. murchandamus commented at 5:00 pm on November 14, 2024: contributor
    Let’s call this BIP 349. Could you please rename the file, add the number to the preamble, and update the README table accordingly?
  29. murchandamus removed the label Needs number assignment on Nov 14, 2024
  30. murchandamus renamed this:
    Add bip-internalkey
    Add BIP 349: OP_INTERNALKEY
    on Nov 14, 2024
  31. in 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>
  32. murchandamus commented at 8:42 pm on November 14, 2024: contributor
    CI isn’t passing, I think the problem are two little issues with the Preamble.
  33. Add bip-internalkey 75351f2587
  34. Fixes and clarifications to address PR comments b35383b68f
  35. BIP-349 329b0d3db5
  36. murchandamus force-pushed on Nov 14, 2024
  37. murchandamus removed the label PR Author action required on Nov 14, 2024
  38. BIP349: Fix preamble for CI issues 669d3b3570
  39. BIP349: Set Created header to number assignment 217ae0dfa8
  40. murchandamus force-pushed on Nov 14, 2024
  41. reardencode commented at 9:38 pm on November 14, 2024: none
    Thanks @murchandamus !
  42. murchandamus commented at 9:38 pm on November 14, 2024: contributor

    I 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.


reardencode vostrnad murchandamus halseth ProofOfKeags moonsettler Starco1001

Labels
New BIP

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-11-21 12:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me