Adding technical cab minutes for SIP-033

considerations/minutes/technical-cab/2025-10-06-sip-033.md

@@ -0,0 +1,133 @@
+# Technical CAB Minutes
+
+## Meeting Information
+
+**Location:** Discord (async)
+
+**Recorded:** No
+
+**Date:**
+
+- Oct 6th, 2025
+
+**Time:** n/a
+
+**Attendees:**
+
+- Aaron Blankstein
+- Brice Dobry
+- j2p2
+- Friedger
+- Jesse Wiley
+- Vlad
+- Radu
+- Setzeus
+
+**Topic(s):**
+
+- [Clarity 4: high-demand new builtins](https://github.com/stacksgov/sips/pull/218)
+
+**Materials**:
+
+- [Clarity 4: high-demand new builtins](https://github.com/stacksgov/sips/pull/218)
+- https://forum.stacks.org/t/clarity-4-proposal-new-builtins-for-vital-ecosystem-projects/18266
+
+## 2025-10-06 Meeting Notes
+
+The Technical CAB discussed SIP-023 and the supporting materials, and concluded that this hard fork is necessary to support the ecosystem.
+
+### Edit 2025-10-13
+There was a change to the proposed functions in the SIP after the CAB vote.
+
+Noted in the chat that this seems more like an implementation detail, with the option to call for a new vote if other CAB members felt one was warranted.
+
+Sip author shared the full diff, which modified two (2) secp256r1 functions after discovering changes were required during implementation (diff shared below).
+
+
+tl;dr is that no re-vote is required, as no members called for one with the understanding that the changes were required, only affected 2 proposed functions (for secp256r1) and were  only discovered during implementation work.
+
+
+From SIP author after the CAB vote:
+```
+I just noticed another small change I'll need to make. it seems that the secp256r1 signatures do not include a recovery byte, so I need to adjust the type sizes to remove that extra byte. Does that sound right?
+```
+
+
+```
+I'm going to not just be removing that byte, but removing the -recover? function since it doesn't make sense any more. Here's the patch:
+```
+```diff
+--- a/sips/sip-clarity4/sip-clarity4.md
++++ b/sips/sip-033/sip-clarity4.md
+@@ -72,9 +72,8 @@ write secure and composable smart contracts. Specifically, it proposes:
+    keyword will allow developers to easily access the timestamp of the block
+    currently being processed, enabling time-based logic and features in their
+    smart contracts. This is especially important for DeFi applications.
+-5. **New secp256r1 signature primitives: `secp256r1-recover?` and
+-   `secp256r1-verify`.** These functions provide on-chain support for the
+-   secp256r1 curve, enabling public-key recovery from signatures and signature
++5. **New secp256r1 signature primitive: `secp256r1-verify`.** This function
++   provides on-chain support for the secp256r1 curve, enabling signature
+    verification for applications that use secp256r1-based keys (WebAuthn for
+    example).
+
+@@ -457,29 +456,12 @@ that context will result in a runtime error.
+
+ ## Secp256r1 Functions
+
+-Clarity 4 introduces functions for working with the secp256r1 elliptic curve,
+-which is widely used for cryptographic operations. These functions are:
+-
+-- `secp256r1-recover?`
+-
+-  - **Input**: `(buff 32), (buff 65)`
+-  - **Output**: `(response (buff 33) uint)`
+-  - **Signature**: `(secp256r1-recover? message-hash signature)`
+-  - **Description**: The `secp256r1-recover?` function recovers the public key
+-    used to sign the message whose SHA-256 hash is `message-hash` using the
+-    provided `signature`. If the signature does not match the message hash, it
+-    returns `(err u1)`. If the signature is invalid or malformed, it returns
+-    `(err u2)`. The signature is expected to be 65 bytes (64 bytes of compact
+-    signature data plus a recovery id in the final byte).
+-  - **Example**:
+-    \`\`\`clarity
+-    (secp256r1-recover? 0x033510403a646d23ee4f005061c2ca6af5da7c32c83758e8e9b6ac4cc1c2153c
+-      0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b7200) ;; Returns (ok 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296)
+-    \`\`\`
++Clarity 4 introduces a new function to verify signatures for the secp256r1
++elliptic curve, which is widely used for cryptographic operations.
+
+ - `secp256r1-verify`
+
+-  - **Input**: `(buff 32), (buff 64) | (buff 65), (buff 33)`
++  - **Input**: `(buff 32), (buff 64), (buff 33)`
+   - **Output**: `bool`
+   - **Signature**: `(secp256r1-verify message-hash signature public-key)`
+   - **Description**: The `secp256r1-verify` function verifies that the provided
+@@ -491,9 +473,9 @@ which is widely used for cryptographic operations. These functions are:
+   - **Example**:
+     \`\`\`clarity
+     (secp256r1-verify 0x033510403a646d23ee4f005061c2ca6af5da7c32c83758e8e9b6ac4cc1c2153c
+-      0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b7200 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns true
++      0x9608dc164b76d2e19365ffa67b48981e441d323c3109718aee245d6ac8ccd21ddadadb94303c922c0d79d131ea59a0b6ba83e1157695db01189bb4b7e9f14b72 0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns true
+     (secp256r1-verify 0x0000000000000000000000000000000000000000000000000000000000000000
+-      0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
++      0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+       0x037a6b62e3c8b14f1b5933f5d5ab0509a8e7d95a111b8d3b264d95bfa753b00296) ;; Returns false
+     \`\`\`
+```
+## Vote Outcome(s)
+
+| Name             | Vote    |
+| ---------------- | ------- |
+| Aaron Blankstein | abstain |
+| j2p2             | yes     |
+| Friedger         | yes     |
+| Jesse Wiley      | yes     |
+| Vlad             | yes     |
+| Radu             | yes     |
+| Setzeus          | yes     |
+
+_Note_ Brice Dobry is the author of SIP-033, as such no vote was tallied for him.
+
+The Technical CAB approves SIP-033 with 6 yes votes, where 1 members abstained and 1 vote was discarded due to authorship.