Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Secp256k1 keys #3345

Merged
merged 6 commits into from
Feb 20, 2025
Merged

Add Secp256k1 keys #3345

merged 6 commits into from
Feb 20, 2025

Conversation

deuszx
Copy link
Contributor

@deuszx deuszx commented Feb 15, 2025

Motivation

We want to support secp256k1 signatures - meaning we need public/pivate keys for them.

Proposal

Adds Secp256k1SecretKey and Secp256k1PublicKey structs. Creates a static SECP256K1 context for reuse, instead of initializing new context for every operation. Note that the same effect could be used by using global-context feature of the secp256k1 crate but that is mutually exclusive with other features (like alloc) that we might want to use in the future.

Test Plan

N/A

Release Plan

@deuszx deuszx mentioned this pull request Feb 15, 2025
Base automatically changed from refactor-mv-keypair to secp256k1-signatures February 17, 2025 13:39
Base automatically changed from secp256k1-signatures to main February 17, 2025 14:34
@deuszx deuszx marked this pull request as ready for review February 18, 2025 11:12
@deuszx deuszx requested review from afck and bart-linera February 18, 2025 11:13
@deuszx deuszx changed the base branch from main to refactor-separate-authority-account-keys February 18, 2025 19:48

impl fmt::Debug for Secp256k1PublicKey {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "{}", hex::encode(&self.0.serialize()[0..9]))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would self.0.fmt(f) look like? I'd expect that to also just be the key in hexadecimal?

Base automatically changed from refactor-separate-authority-account-keys to main February 19, 2025 14:27
@deuszx deuszx force-pushed the secp256k1-keys branch 3 times, most recently from f8ad395 to 60e38eb Compare February 19, 2025 16:08
@deuszx deuszx force-pushed the secp256k1-keys branch 2 times, most recently from 49ab7e9 to 5314f7c Compare February 19, 2025 18:48
@deuszx deuszx changed the base branch from main to refactor-use-pk-instead-of-owner February 19, 2025 18:48
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch 3 times, most recently from 07d9ca9 to 3c76e1e Compare February 20, 2025 00:21
@deuszx deuszx force-pushed the refactor-use-pk-instead-of-owner branch from 3c76e1e to 9293417 Compare February 20, 2025 00:34
@deuszx deuszx force-pushed the secp256k1-keys branch 2 times, most recently from 6a12891 to d37befd Compare February 20, 2025 09:52
Base automatically changed from refactor-use-pk-instead-of-owner to main February 20, 2025 12:48
@deuszx deuszx merged commit e4d3b92 into main Feb 20, 2025
21 checks passed
@deuszx deuszx deleted the secp256k1-keys branch February 20, 2025 13:24
@ma2bd ma2bd mentioned this pull request Feb 23, 2025
ma2bd added a commit that referenced this pull request Feb 23, 2025
## Motivation

Fix install after #3345.

## Proposal

Apple clang doesn't compile for Wasm. After #3345, clang is needed.
However, LLVM v19 is an issue (to be discussed separately).

## Test Plan

run `brew install llvm@18` locally and it solved the issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants