Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is great. It really pissed me off when David Chaum locked all the cool uses of ZKPs behind a patent wall. The DigiCash folks were peak dot com greed types, their business model was "We're going to get big chunk of change out of every transaction ever so we should be valued at 1% of the worlds GDP!" And the world responded with "Yeah, no."

I really like Andy Birrells "micro-cents" which exploited the fact you could not easily reverse an MD5 hash so you one could cheaply do high confidence low value transactions at speed. Another idea that never got anywhere sadly.

ZKP ID cards and ZKP currency are both interesting things from the 90's I'd love to see in real life. Imagine I could pay you phone to phone with no network level of capability using a currency that couldn't be double spent. That was the promise of digicash. The government hated it :-). It was just like cash currency in that serial numbers could let you track the bank it left, and the bank it came back in to, but you couldn't track anywhere it had been between those two points.

Fun times. I'll have to see if some of my ZKP ideas can be built on top of this tech now.



> This is great.

Do you still feel that way knowing that it introduces a hard requirement for all users to have their private data managed by one of Apple, Google, or Microsoft[1]? I want to be excited about this, and about Passkeys, but the people working in this space keep fumbling this ball :(

[1] "Using the MDOC requires a signature from a hardware security key in the phone" https://news.ycombinator.com/item?id=44458417


You can have a password manage your passkey private data. Several now have passkey support, including some that work on Linux such as 1Password and Bitwarden letting you use passkeys even if your household is completely Apple-free, Microsoft-free, and Google-free.


https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

> To be very honest here, you risk having KeePassXC blocked by relying parties

Even if the bigtechs don't "officially" make the passkey standards require bigtech involvement, it seems very likely to me that conservative businesses like banks will only accept bigtech implementations. And then you're sunk.

Similarly, look at how OpenID turned into "Sign in with AppleGooFaceSoft".

This ZKP+hardware secure element stuff seems even worse, because how are you going to make it work on old hardware, or with free software, or with open devices?


> Even if the bigtechs don't "officially" make the passkey standards require bigtech involvement, it seems very likely to me that conservative businesses like banks will only accept bigtech implementations.

Indeed. It's not a theoretical concern, either. The spec authors themselves actually maintain a "naughty client list": https://passkeys.dev/docs/reference/known-issues/

> This ZKP+hardware secure element stuff seems even worse, because how are you going to make it work on old hardware, or with free software, or with open devices?

I don't love it, but I actually do see an argument that this kind of proof-of-property stuff really does belong in a secure area, backed by approved software. It is making government-backed, legal claims about a person or entity. Unlike with Passkeys, it's not really "your" data, rather it's a way for the government to provide legally-backed information to someone, without the government actually having to be in the loop. I'd probably argue the solution to the big-tech dependency here is the government should be required to provide its own, verifiable solution (such as a physical ID card with open software) for users who do not want to trust big-tech.

Where the ZKP spec authors goofed was in not considering the wallet provider to be a party in the transaction. That third party may have interests that are not aligned with the user's.



Nice. I wish you success in this.


Appreciate it


Offline transfers don’t work without risk of double spending. The transactions eventually have to be finalized with a mint. The most one could hope for in the DigiCash model is the detection of a double spend once the cheated parties go back online[1].

If only the recipient doesn’t have access, a certain amount of trust can be delegated to the strength of the proof presented in the spend. In an ecash model, the proof would be in the form of a signature made by the mint (assuming the recipient was able to get the public keys the mint was using).

Active research is being done on the ecash model with the resurgence of the concept in the Cashu and Fedimint projects. Cashu takes the online sender, offline receiver approach[2].

[1] https://chaum.com/wp-content/uploads/2021/12/Untraceable_Ele...

^See paragraph in the introduction ending with:

“But if Alice reuses a coin, the bank can trace it to her account and can prove that she has used it twice.”

[2] https://x.com/CashuBTC/status/1901240537866273252




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: