password-protected mint (uses msg.sender and recent blockhash as public inputs and password as private input to a zk proof that’s verified onchain)

prev: /nook, protocol @ opensea, co-author seaport & stuff.
professional @slokh and @0xalexander fanboy

how do you invalidate proofs vs signatures? 🤔 for signatures, we invalidate the signed "digest" hash to avoid re-using malleable signatures

i'm pretty sure STARKs are malleable as well (idk about SNARKs - anyone know?) - so maybe hash the public inputs and invalidate that
but what if multiple proofs have the same inputs - could also use validity key as part of calculating the "digest", my understanding is that it's kind of a unique "circuit/program id" 

what are people doing now?

it'd be dumb, but whoever creates the mint

just thought it was amusing that for all the galaxy brain zk stuff out there, i only just now realized you could use simple passwords on blockchain securely with zk proofs lol

because password won’t be private anymore

ZK also makes sense when there is offchain input you want to verify without revealing, no?

just a silly idea 🤠

Why not sign messages with msg.sender in them

Much more efficient and maintainable

ZK only makes sense when there is a computation with dynamic on-chain input you want to verify

interesting approach. using zk proofs for password-protected mints adds a layer of privacy and security. onchain verification is a smart move to maintain trust. curious to see how this impacts user experience. always a balance between security and simplicity.