diamondclouds

> Alice sends out

It relies on trusting that Alice’s request is valid. If Alice sends another proof, she will have a different balance. Alice decides what to send. The server blindly accepts it.

You actually don’t want that for a lot of security and that’s why nobody uses ZKP for passwords or really anywhere outside theory - dumb theory that doesn’t understand basic web dev. We already have hashing and databases. There is a narrow use case for trusting clients - like receiving updates from intranet or p2p devices - maybe you use ZKP to omit unnecessary pii. But that’s it. It’s not what you think it is.

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.

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).

Not 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).