> relies on you trusting the client to send you true information about data
this is false. the client is constrained to send you true information or else the verifiers will know to reject it.ZKP's are not magic, you need a cryptographic operation on which to operate the ZKP. this way you can conceal the input while still proving something about it. this works because the ZKP follows the trace of execution through the cryptographic primitive which proves it was executed properly and then the output was validated by some public measure.
conversely, if ZKP's ever get fast enough to be useful for this you can prove a public input (ex. source code) was compiled properly into a public output (ex. binary). for obvious reasons doing this only makes sense when it's efficient otherwise you can just execute it yourself.
This doesn’t mean the input is “true” though. I can send some zkp that says I’m at least 18 or that I have at least $1M in my bank account, but it doesn’t mean that I actually am or do. Or am I missing something?
Yeah ok bud. You wouldn’t last a week.
something is fishy in this comment section.
> why would you need the proof
Precisely why ZKP is crypto tweaker nonsense - you don’t. You don’t have to mathematically prove anything. If the user provides their birthdate guess what I already know if they are over 21. Better if I validate on my end. If it relies on a super secret algorithm that can’t be cracked client side then I have a bridge to sell you.
You don’t trust the client. Unless you do. Then in that case by all means reinvent every protocol