I built an algorithm to make password as privatekey, and it works well on EVM.
Many new crypto users abandoned at wroten down the privatekey, I hope this password algorithmcan bring them back (without privatekey). It’s decentralized, base on ZK-SNARK and smart contract, it can be also used as multi-sign with privatekey, to be double security for protecting assets.
That is super interesting. I will take a deep look.
The EIP looks good as a draft. And thank you for this creative idea!
[Peer Review] The only technical concern I have is that in 2008-2009 the Bitcoin’s hashrate globally is 10MHash/s, today it’s 400EHash/s which is 4e13 times more. If the hash rate of Poseidon increases as fast in that rate, it will be cracked in 100seconds in 15th year. 116586246y = 3.6766638539e+15sec
Thank you, thanks for the notice, we are following, if any better way, we will update
Do you have a working implementation somewhere?
I’m having trouble understanding the motivation for this.
It seems to me that I could have password-based accounts in Ethereum (w/ or w/o EIP-4337) by just deriving my SK from a password (using whatever memory-hard hash function I prefer).
I guess I cannot “rotate” my password, but I could implement this via the EIP-4337 standard using a digital signature from my old password-derived SK on a new PK.
Why bring complicated ZKPs into this when simple digital signatures with password-derived SKs seem to work just fine?
Using certificate + password => private key, it needs to store certificate. Losing certificate is a big secure problem.
Another way is using public private key + path => new private key, like BIP-32, incording to the BIP, it donsen’t support password, but you can still encode password to path, maybe it can work, I’m not sure, I guess it may need a long time(a few minutes, ZKP is seconds) to generate the new private key, if you have tried, share your idea, I‘ll glad to know.
I am not able to parse your reply, sorry.
What “certificate” are you referring to?
Not sure I get your point about BIP-32 either. Your approach is not BIP-32 compatible, AFAICT. Neither is the approach I’m proposing above (i.e., derive an SK in whatever secure manner you want from a password).