[flagged]
A quick look at zero-knowledge proofs
31–40 of 54 posts
Re: A quick look at zero-knowledge proofs
#32[dead]
Re: A quick look at zero-knowledge proofs
#33[dead]
Re: A quick look at zero-knowledge proofs
#34[dead]
Re: A quick look at zero-knowledge proofs
#35[flagged]
> are you fucking stupid unable to think for yourself??
I was about to write you off as ignorant and unhinged, but then you wrote this, which persuaded me that you were right all along
Re: A quick look at zero-knowledge proofs
#36[flagged]
Re: A quick look at zero-knowledge proofs
#37I don't think ZKPs / programmable cryptography are useless like some of the other commenters. But I do remember being surprised, based on the way that people talk about building on top of it, to learn that the performance is so bad (except on dedicated servers) that it's basically a theoretical technology until that's fixed. Has this changed recently? Not a rhetorical question.
Nowadays you can run arbitrary verified computation at 100-300MHz using so-called zkvm. State of the art are probably risczero and succinct. Practically speaking, write any program you want, compile it to riscv, imagine to run it on a pretty fast microcontroller, and in addition to the result you get a proof of correct execution. I’d say it’s pretty practical, all major unlocks happened like in the past 3-4y and of c…
[dead]
Re: A quick look at zero-knowledge proofs
#38Earlier quoted context omitted.
> this way you can conceal the input while still proving something about it 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?
But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof
Then just ask the third party?
Re: A quick look at zero-knowledge proofs
#39ZKPs verify statements about data, not the authenticity of the data source itself.
Re: A quick look at zero-knowledge proofs
#40Earlier quoted context omitted.
> 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 th…
> this way you can conceal the input while still proving something about it 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?
Consider ZK password proof protocol: at enrollment (password set / change) the server -or a third party it trusts- knows the password and computes a verifier, while at login time the server uses the verifier to validate that the client knows the password but without the client revealing the password to the server. The client could perhaps have found an alternative password that matches the same verifier, but the ZKPP's security characteristics are supposed to make that exceedingly difficult. Meanwhile, the ZKPP is also supposed to make it exceedingly difficult to recover the password from a ZKPP exchange that any eavesdropper could record.
A non-augmented ZKPP protects the password from eavesdroppers, but the server's verifier is a password-equivalent (though it isn't the password, just a one-way function of it).
A ZKPP is the simplest ZKP application, but others work similarly.
In other words: you're missing everything about ZKPs.