Quote from: Mike Hearn on January 29, 2014, 11:59:33 AM

Quote from: d'aniel on January 29, 2014, 06:39:26 AM

Though don't governments generally have access to lots of foreign passport scans from border crossings, airport, etc.?

That's true, they do. It's like a bigger variant of the hotel attack. So maybe the "reveal country and play geopolitics" wouldn't work well.

I thought of a couple of countermeasures but they decrease convenience a lot. One would be to find a way to do the time-spacing trick, perhaps by committing to a hash of some (derived?) data in the block chain, and then incorporating that and a block hash from N days later into the proof. However in the absence of AA it doesn't work, and most passports don't do AA, so that seems like a dead end.

The second is to have some random/semi/low trusted third party do a match between face and passport photo data (it can be extracted independently from the rest), in such a way that it's clear the owner of the passport is consenting to creating the fresh identity. That way attacks based on just grabbing someones data wouldn't work. Because matching two photos together perhaps with a MySpace style "salute" (write a code on a piece of paper and hold it up to the camera), is very easy, it could be a Mechanical Turk style microwork scheme. There's no need for the face-matching-person to know anything about who they are seeing. Accuracy could be measured and enforced by having other low-trusted third parties do random audits.

But that's very complicated and would take a lot of effort to set up. If Tor strongly suspected it was really being infiltrated by a lot of intelligence agency controlled nodes, it might become worth it. But otherwise I doubt it's worth it.

Note that ZKPOPs have use cases outside "how do we beat the government at sybil attacks". For instance, one reason porn sites hestitate to use Bitcoin is that they use credit cards as a form of age verification. Anonymous age verification, anti-spam systems, helping manage identities in end-to-end encrypted email ... there's lots of places where selectively revealed yet hard-to-forge identities would be useful.

Time spacing could be achieved at the node-node handover of a block.

N1 isn't known to N2.

N1 --> N2: Here's a block. It has timestamp t0.
N2 waits a random amount of time <1sec.
N1 <-- N2: Ok, now solve this small puzzle and send me a new timestamp.
N1 --> N2: Here's the solution and timestamp t0+N2_delay+x.

Now, t0+N2_delay+x must be greater than t0 - so the person in control of the node isn't just winding their clock backwards and forwards between problems. The latencies for the connection should also be the same in both directions, to within a narrow margin. Comparing the timestamps tells you how long that node should take to solve a particular puzzle, which can then be used as a reference when asking the same puzzle later. This tells you the physical make-up of the machine hasn't been swapped out and another one is just spoofing the ID.

This map of latencies and 'puzzle-solving-times' acts like a map/proof for other nodes in the network when they now want to talk to N1.

Again, I'm sure there are parts I'm missing, but this would be internal to the protocol itself and not require external tokens, and be fairly easy to bootstrap outwards from a single trusted server.