A quick look at zero-knowledge proofs
bernsteinbear.com
A quick look at zero-knowledge proofs
1–10 of 54 posts
Re: A quick look at zero-knowledge proofs
#2Amazing article. Will save to explain ZKP to others.
One tiny correction
random.randrange(100) gives 300 possible commitments(3 colors for hundred nonces) After seeing a couple of revealed edges, the verifier can figure out the palette and brute-force all 300 combinations, effectively opening every commitment.
It can be mitigated if we use 128 bits of randomness, e.g. secrets.token_bytes(16).
Also I would use sha256 instead of hash. Python hash is not considered secure as it does not have proper collision resistance.
Re: A quick look at zero-knowledge proofs
#3[flagged]
Re: A quick look at zero-knowledge proofs
#4[flagged]
A great way to announce that you don't understand ZKP
Re: A quick look at zero-knowledge proofs
#5[flagged]
A great way to announce that you don't understand ZKP
Explain why you need ZKP for their flagship problem - the “prove you’re 21” thing.
Or choose any case you like.
Explain why I can’t do it without this hilariously elementary philosophy detached from real world dev.
No cheating! I get access to the same resources. Explain why I need ZKP.
Re: A quick look at zero-knowledge proofs
#6Earlier quoted context omitted.
A great way to announce that you don't understand ZKP
Explain why you need ZKP for their flagship problem - the “prove you’re 21” thing. Or choose any case you like. Explain why I can’t do it without this hilariously elementary philosophy detached from real world dev. No cheating! I get access to the same resources. Explain why I need ZKP.
I actually don't think ZKPs solve the age verification problem (for a variety of reasons that won't fit here), but they solve plenty of more interesting problems. Private transactions in Zcash, for example.
Re: A quick look at zero-knowledge proofs
#7Not one mention that ZKP depends on servers trusting clients.
The single reason ZKP is not viable for most security is that it relies on you trusting the client to send you true information about data.
With conventional security the user sends their inputs and the server validates it.
Something I notice that is almost never mentioned when people bring up ZKP - it is pretty much only for peer-to-peer when there is no authoritative server. Or when that server trusts the “nodes” (clients).
Re: A quick look at zero-knowledge proofs
#8[flagged]
It has a use case in peer-to-peer or anywhere that you want the server to trust the connections.
Sometimes you want clients to be authoritative (although rare).
Re: A quick look at zero-knowledge proofs
#9Earlier quoted context omitted.
A great way to announce that you don't understand ZKP
Explain why you need ZKP for their flagship problem - the “prove you’re 21” thing. Or choose any case you like. Explain why I can’t do it without this hilariously elementary philosophy detached from real world dev. No cheating! I get access to the same resources. Explain why I need ZKP.
I think the fine article says it best when it says
> After doing a bit of research, we decided that the most common real world use cases of zero-knowledge proofs (age verification, crypto, etc) aren’t particularly interesting to us. We enjoyed the graphs and theory of computation and networked computing though. We hope you had fun playing around with interactive proofs too.
The inclusion of this statement makes your comments look rather bizarre and strangely combative by comparison. Maybe we can just enjoy a bit of math together?
Re: A quick look at zero-knowledge proofs
#10Earlier quoted context omitted.
Explain why you need ZKP for their flagship problem - the “prove you’re 21” thing. Or choose any case you like. Explain why I can’t do it without this hilariously elementary philosophy detached from real world dev. No cheating! I get access to the same resources. Explain why I need ZKP.
I actually don't think ZKPs solve the age verification problem (for a variety of reasons that won't fit here), but they solve plenty of more interesting problems. Private transactions in Zcash, for example.
Only because zcash trusts the sending node - whoever is hosting that ledger.
If they had no clue who it was, like the typical http web, they could not allow a sender to be a prover, since they would not be able to verify their balance. At some point a balance inquiry would have to reveal who they are. It only works if you trust the banker.
Or by being a middleman. You send [payment service] the money and they send it to the recipient, hiding your info.