@ulerdogan I just recalled that a broader precompile effort was put forth in 2019 with EIP-1829. It might be useful to understand from @Recmo what happened there and if revival of a more generic precompile would still be useful.
My sense is that 1829 has now been fully supplanted by one-off EIPs for specific curves and as such moving forward with a secp256r1 makes sense, but it might be worth reviewing.
Hey, thanks for reviving the idea!
I followed the EIP-1829 discussions and some other contents. Then, I found EIP-1962 which is a continuation of EIP-1829 by Alex. It seems that the problems in the implementation later revealed EIP-2537 which was planned to be included in Cancun upgrade, now postponed.
Apparently, generalized curve implementations failed and were replaced by specific ones with EIP-2537 ([notes] by @timbeiko (https://twitter.com/TimBeiko/status/1235931932644564995?s=20) from an ACD call).
I would love to hear the ideas of those who have worked on precompiled contract implementations for curves about the previous experiences and this proposal! @Recmo @shamatar @ralexstokes @kelly
I support this EIP. Just image how many new users will be attracted to Ethereum without the trouble to backup their mnemonics or private key on a piece of paper…
I do feel, that specific support for the secp256r1 curve is needed. There are a lot of requests for a gas-efficient way to verify passkey-signed data on-chain. And this proposal will make it possible.
I agree with your opinion that secp256r1 can be enough. however Ed25519 seems to still have many benefits, especially less computation.
And, it also seems that there was already an EIP about Ed25519, could we leverage that proposal?
As per Vitalik’s post quite some time ago, I don’t recommend using the secp256r1 curves.
" The obvious question is this: where did the seed come from? Why was the seed not chosen to be some more innocent-looking number, like 15? In light of recent revelations regarding the US National Security Agency subverting cryptographic standards, an obvious concern is that the seed was somehow deliberately chosen in order to make the curve weak in some way that only the NSA knows. Thankfully, the wiggle room is not unlimited. Because of the properties of hash functions, the NSA could not have found one “weak” curve and then gone backward to determine the seed; rather, the only avenue of attack is to try different seeds until one turns out to generate a curve that is weak. If the NSA knows of an elliptic curve vulnerability that affects only one specific curve, the pseudorandom parameter generation process would prevent them from standardizing it. However, if they knew of a weakness in one in every billion curves, then the process offers no protection; for all we know, c49d360886e704936a6678e1139d26b7819f7e90 could have been the billionth seed that the National Institute for Standards in Technology tried."
@longfin @Toshi I don’t think there are many that would dispute that secp256r1 is a non-ideal curve, however, the claims of a backdoor have been made for well over a decade without any substantive evidence of the existence of one. This is significantly different than the discussion for a SHA1 precompile which was demonstrably malleable at the time of proposal.
Proposing other curves arbitrarily ignores the key arguments in favor of this EIP which is that billions of devices have hardware accelerated support and isolated secure storage for secp256r1. Ed25519 would be great, but low cost secure element chips don’t support it (nor do they support secp256k1).
If this proposal sought to shift EOA creation to secp256r1 I would understand the concerns here, however, just adding it as a precompile doesn’t seem to me to warrant the ire that it’s currently receiving.
First of all, I don’t believe the rumors of a backdoor on secp256r1 seriously too. 
Aside from unconfirmed concerns about backdoors, the difference between secp256r1 and Ed25519 seems to be whether we will use relatively the modern curve or the little bit old curve that supports many devices, and coverage seems to make sense at this moment. 
Thanks for your comments @longfin @Toshi, and thanks for your explanation -I completely agree with you- @ccamrobertson.
I think that even if ed25519 presents an efficient usage, I can’t find enough motivation to bring this curve into the EVM, but the secp256r1 curve has many cases that can directly improve the UX in Ethereum as it’s one of the most widely supported elliptic curves in the internet/mobile ecosystem.
Also, my comments about the rumours: I agree with the idea that choosing the k1 curve as the main security mechanism of Bitcoin and Ethereum, but bringing the r1 curve as an additional verification mechanism in the app level, does not contradict this selection.
Additionally, pointing out an upper discussion:
i’m starting to see account-abstraction projects implement “riced-out” versions of secp256r1 signature verification to support passkey authenticators who dont support Koblitz, to save on gas. How the heck can I, a mere mortal, review, understand, and audit these implementations:
trampoline/contracts/EllipticCurve.sol at webauthn · eth-infinitism/trampoline · GitHub
aa-passkeys-wallet/src/Secp256r1.sol at main · itsobvioustech/aa-passkeys-wallet · GitHub
More importantly, if we want to onboard the next ${num} users onto the EVM, there are about 4billion devices that support webauthn: navigator.credentials.create() to securely create, store, and sign a PublicKeyCredential without installing anything
however, none of the devices I tested: (e.g., ~samsung phones, ~pixel phones, various iphones, m1 macbook, dell laptop (windows / linux / macOS)) support the Koblitz curve (secp256k1), they can only do secp256r1 (P-256, COSE Curve: 1, Alg: -7)
can we please get a precompile (or native support) for secp256r1 ? cc @vbuterin
Fantastic point. The harm from everyone rolling their own secp256r1 could be massive. If an AA scheme catches on leveraging a broken implementation you will see real loss vs. hypothetical loss from the NSA.
@mac Ledger security team will present this paper on the 17th at ethcc “WebAuthn Optimization: optimizing ECC sec256r1” this extend the resources in the repo previously shared above.
Regarding the debate on the security of p256 I recommend this article
This old Serenity EIP-101 discussing is relevant too:
OP produced an example implementation for OP hackathon project: Opclave | ETHGlobal
https://github.com/itublockchain/opclave-scaling2023/tree/main/precompiles
Claiming this will help users manage their private keys better by entrenching them in a proprietary SoC solution (Apple Secure Enclave) is ridiculous. We trust in math, not Chinese supply chain vendors. Claiming that “backdooring” is not viable misses the point: we are not claiming that all chips are backdoored, only that certain chips be intercepted en route to end user by TAG/TAU and flashed with backdoor. It is hard to verify hardware, its easier to verify software.
Here is an approach that uses existing authentication schemes to provide user key management, check their github for examples. https://mfkdf.com/
Precompiles should be ossified, they were always a “temporary” solution, that was 8 years ago.
Strongly in support of this - secp256r1 is by far the most widely used curve, and enabling it to be efficiently verified in the EVM will enable countless integrations with existing infrastructure that are currently impractical.
Those suggesting alternate curves or raising issues with the derivation of the secp256r1 parameters are missing the point; the idea here is not to pick the ideal curve, it’s to add functionality that permits integrating with external and legacy applications efficiently.
I would suggest that an ‘ecrecover’ type implementation is more versatile, though; it’s easy to convert ecrecover into a signature verification operation, but impossible to do the inverse.
In strong support of this proposal.
Generally speaking, hard reproducible evidence has to exist for the claims of NSA influencing NIST to weaken the secp256r1.
Otherwise it’s unproductive for the conversation.
Alexander has been constantly requesting and implementing support for secp256k1 for the bitcoin community in Apple’s Swift crypto library for the past 4 years: New API Proposal: Add SECG curves, especially `secp256k1` · Issue #8 · apple/swift-crypto · GitHub
It’s evident from the conversation that they consider secp256k1 to be limited to cryptocurrency and not for “wide usecases” and have been delaying and denying support.
Considering this proposal, the wallet UX for regular Mobile users using Android/iOS/Android-derivate OSes can drastically improve.
This also includes keychain devices which already support the curve or hardware devices which can be built using secure element (SE) that support secp256r1.
So it isn’t just Mobile Devices, but beyond that, large no. of IoT devices can come integrated with SE and utilise this precompile to unlock new/existing use-cases.
I see no reason to support secp256r1 instead of x25519 / ed25519. r1 is US gov standard. The world is bigger than US.
25519:
That’s a false dichotomy; this proposal doesn’t argue anywhere that secp256r1 support should supercede 25519 support. I suspect most people here would also support a 25519 precompile.
I personally think secp256r1 has a lot of usage, having a precompile will be beneficial. And I also agree with the counter argument that there is cost to implement and adopt such precompile.
It seems a pattern that whenever a precompile is proposed, there will be a lot of debate about whether there is likely to be a lot of usage. The chicken-and-egg nature is that without deploying the precompile, we can’t calculate the adoption, and without the adoption, it’s hard to argue for making it a precompile.
Good news, we are propose to have a “progressive path towards precompiles”, where author proposes a precompile, but instead of requiring it to be deployed as precompile first, they deploy a precompile candidate which is a traditional smart contract (with higher gas cost per operation, though), and see if there is usage. Once the usage is validated, the data can be used to (1) justify the need for such precompile, and (2) serve as call pattern to help client implementor tune performance
In terms of usecase and “will it get used”, this EIP is essentially for onboarding the next millions of users. There’s no way to onboard normies at the moment as you need to use MetaMask or another wallet to use DeFi, NFTs etc. With this EIP we can convert web2 users in scale.
Would like to express support for this EIP. Echo the opinion that this should not be a debate on the security of the curve. Providing a precompile for the curve enables integration with mass distributed hardware where users are already trusting the curve. We should provide an option for those users to extend that trust to smart contracts which elect to use this curve for validation.
To me it feels pretty straight forward. The most widely adopted curve should have a precompile. Its not forcing anyone to use it but provides critical functionality for those who want it.