We're in a very small window in the battle against climate change where people are even allowed to spend money on space programs.
In a few decades at our current rate we're going to see so many natural disasters and mass migrations that the general populace will be far more concerned about food and water for the populace than wasting it on extravagances like space, and then we may end up all dying on this rock.
Once we're able to successfully mine minerals from space and have some hope for colonizing other planets the game changes, because people could see it as a lifeline rather than a waste.
A more complex way they are currently used is for proving arbitrary computation.
One of the most obvious flaws of blockchains is that every node needs to re-run every transaction to know that the block is valid, leading to the same computation being run thousands of times.
Instead of having to do this there are new Layer2 chains like Polygon zkEVM or zkSync that post a compressed blob of transaction data and a ZK proof that all transactions in that data are valid according to the rules of the EVM. This makes the chain 1000x more efficient as the computation only needs to be run once and verified 999 times.
The proving is still slow and expensive which is why this isn't fully rolled out, but it's getting faster very quickly with both software improvements and custom ASICs for proving.
Yea you can prove you're some set of users without revealing which one.
This is useful in the case of whistle blowing you can prove you do work at a company, or say a US Senator can show the government is up to no good and prove they are a senator without revealing who they are.
ZK STARKS can be done without a trusted setup, they are slightly different from ZK SNARKS.
I believe it's possible to do a trusted setup with many hundreds or thousands of anonymous people too, someone would need to get every single contribution to recreate the trusted setup.
ZKPs have only become cheap and easy enough to do in the last few years, so of course Goldman Sachs doesn't use them yet. They'll be using them in a decade, for now look at startups. https://github.com/zk-passport/openpassport is one that is working today, worldcoin ID verification is another.
The ID would need to have some government digital signature for the ZK circuit to work. The proof would be "this digital ID that has this valid government signature shows XYZ".
The verifier would need the government public key and then can see "This ID that has been signed by the governments private key shows XYZ"
And the next question is: why bother? We have well-established protocols for the ID card: a police scanner creates a nonce and sends it to the card, the card signs it with its private key, and provides a certificate signed by the government.
The police scanner then verifies the signature and checks that the certificate is correctly signed by the government's public key.
Yea the chip gives the information written on the device. It doesn't answer arbitrary questions about the data.
The whole point of ZK proofs is the zero knowledge part. If you don't care about the person being able to see the information of course there's no need for them.
First you described exactly the concept of password hashing, now you're describing something else entirely:
> It doesn't answer arbitrary questions about the data.
Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality.
When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password.
Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages.
Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".
I didn't mention hashes anywhere in this thread, you were the one claiming you can prove someone's age just based on a hash of it (and still haven't shown how other than breaking the hash with a rainbow table).
I posted this earlier (and it's in the article...) but will reiterate again: ZK proofs are used when the prover (server) and verifier (client) don't trust each other and don't want to give each other data on each other. If you trust the server you can just give it a copy of your passport, if the server trusts the client they can just show a checkbox asking if they're old enough.
The hash check is binary, you can only check if a password is correct or not. The ZK proof can prove anything, like that the password has enough special symbols and numbers that it's secure.
There's no way to check that someone's age is old enough with just a hash unless you break the hash.
The most common but painful way to write ZK circuits is with Circom. Better more modern ways are with Noir or using SP1 which can prove arbitrary rust code.
Apparently not, isn't it designed specifically such that it's scoped to a particular "proof"?
You guys always say "without it linking you to your identity" as if identity is built into JavaScript or something. How does using a password hash inherently leak my PII? What problem does ZKP solve?
Using conventional development you can also do the trivial stuff you mentioned like running password through regexp.
What do you mean scoped to a particular proof? There are different proof types like there are different hashing algorithms, they can all prove any data just like sha256 and md5 can hash any data.
How do you verify the password meets certain requirements sever side without getting that user data? Client side input can't always be trusted as anyone can modify that regex check.
With something like TLS notary you can prove anything signed by a https certificate, so you can prove there are enough funds in your bank to get a mortgage without revealing how much money you have.
In response to your comment The ZK proof can prove anything, like that the password has enough special symbols and numbers - you definitely do not need "ZKPs" to do this trivial task.
and
> There's no way to check that someone's age is old enough with just a hash
Yeah you can, you log them in then link them to that userData with an identifier - typically an email address or unique user ID. You can easily write the login API to know nothing but hashes, or you can write it to respond with - to use your example that user's age - if the password is correct (without ever actually knowing the password).
Re: Passport verification
Anybody can verify any document with enough identifying information about the document and a registry to match it up to. You don't need a private/public key library wrapped around any functions to accomplish that, but the government probably requires the photo for a reason. Maybe you can verify the document, but a lot of services are going to require photo identification regardless of what your library can do without a photo. Again trying to find what problem this solves. Would have been way cooler if you said it verified faces with passport photos - that's the hardest part.
> Yeah you can, you log them in then link them to that userData with an identifier - typically an email address or unique user ID. You can easily write the login API to know nothing but hashes, or you can write it to respond with - to use your example that user's age - if the password is correct (without ever actually knowing the password).
This doesn't make sense, how do you verify someones age without getting their birthday? Hashes are binary yes/no checks, not range checks.
> Anybody can verify any document with enough identifying information about the document and a registry to match it up to.
So your alternate solution is that every government in the world runs an API you can check a passport against? Instead of them just providing a known public key they signed the passport with? Sounds way over complicated compared to a ZK proof.
> Re: Validating passwords
> You haven't provided an alternative way though?
Check if it has numbers: \d
Check if it has symbols: \W
Check if it's 6-64 chars long: {6,64}
> This doesn't make sense
Promise you it's how it works.
> Hashes are binary yes/no checks
Nope, just means encrypted text.
> every government in the world runs an API
Hilarious you think a decentralized approach where every participant has a copy of an append-only ledger is simpler than a central server with SQL database. The argument for decentralization was never that it was simpler - it's of course way simpler in many ways to have a single source of truth. If you mean using that passport library on a regular server, then you also have to run an API or nobody can use it.
- Do you not understand that client side checks are insecure?
- As you're still not getting it, how about this: This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2`
- Nothing I've mentioned needs an append only log, where are you even getting that from? A ZK proof is created from only the data stored on the passport chip.
Everybody understands that - the underlying point is there's no need for "ZKP" to validate or hash anything.
And for the sake of this kindergarten discussion the hash is computed client-side - that's the whole point, so the server doesn't know your password. The hash is checked on the server side.
Your ZKP has no use case - most of you guys aren't web developers (that much is obvious) and don't realize these problems and solutions are trivial.
It depends on what you want to do, if it's user login over HTTPS you can pass a plaintext password to the server and hash/compare on the server only. It would still be secure because the plaintext is never saved in a db (only the hash is), and was TLS encrypted in transport.
-----
> This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2`
You hash the point of access like a password or key, not the data itself. When the access is granted, you return the data. sha256 is never meant to be decrypted. It would be like this:
If your requirement is to actually to decrypt the sha256 you misunderstand the purpose of one-way encryption. That said - if you really wanted such a system, for such a finite list of dates (365 x 21 = 7665) you can easily maintain an array of the valid 7,665 sha256's on any given day. If it doesn't match a sha256 on file, that birthdate is not a person over 21.
Lol, well yea if you throw away the zero knowledge part or trust the client to tell the truth of course you don't need zero knowledge proofs. Its not zero knowledge though (you just gave the server the info) and/or isn't proving anything.
This is the situation zero knowledge proofs are used in:
- The client doesn't trust the server and doesn't want to give it any info (that's the zero knowledge part)
- The server doesn't trust the client (that's the proof part)
If you break them of course the problem is much easier to solve.
If the client trusts the server they can give it a scan of their passport.
If the server trusts the client to run that code then you don't need a proof, you may as well just have a popup that says "are you over 21?"
A rainbow table is just breaking the hash and then you may as well not have it, in the real world the client would add a salt so this isn't possible.
>It depends on what you want to do, if it's user login over HTTPS you can pass a plaintext password to the server and hash/compare on the server only. It would still be secure because the plaintext is never saved in a db (only the hash is), and was TLS encrypted in transport.
:) if I get a penny every time someone logs sensitive information in plain text to some log file without realizing they did.
If I had a penny for every straw man argument. Who said anything about writing
plaintext passwords to files - you just made that up?
Also you might not understand web dev 101. Every website including this one that uses HTTPS sends encrypted data, the password you enter in a text input is in plaintext. For the backend - as I said above, the server hashes it and saves the hash, never the plaintext password.
That's how it works - nobody said anything about "log files".
50% of Australia lives in Brisbane, Melbourne and Sydney. Having a nuclear power plant for each would make sense. Melbourne would make the most sense first as it gets a lot less sun than the others.
I went through the same thing last few years. Ended up joining a venture capital firm as a technical researcher and love it.
I focus on crypto most of the time, and sometimes robotics, AI or developer tooling. I mostly talk to startups about their tech and do due diligence to make sure they know what they're doing.
I read a lot of whitepapers and go to technical discussions at conferences to know where the industry is going to see where we should be investing.
In a few decades at our current rate we're going to see so many natural disasters and mass migrations that the general populace will be far more concerned about food and water for the populace than wasting it on extravagances like space, and then we may end up all dying on this rock.
Once we're able to successfully mine minerals from space and have some hope for colonizing other planets the game changes, because people could see it as a lifeline rather than a waste.