HIP-? on Identity Theft

I recently got asked the following:

Illicit identities: How do we handle people paying someone who isn’t in the registry yet for the right to take a photo/video of them? This seems hard to prevent, and could mean that the cost of owning an entry in the registry is <$10.

It’s a tricky attack, and although maybe this is not happening today… it will certainly happen in the future as we gain mass adoption.

Since the video itself is a form of affidavit, I though that maybe a statement where you claim: “I certify im the owner of this wallet and no one else controls it” could work, but maybe it’s a bit naive. We could say tho that:

  1. it increases the length of the speech sample we get, which is useful for sybil detection via voice biometric

  2. it might increase the cost of the attack, because it might be more expensive to convince someone to lie on camera than it is to just get them to say some random thing. people might be worried they could get in trouble, etc. it’s probably not a huge effect, but security is an economic game and we might as well take wins where we can :slight_smile:

(credit to @RoboTeddy for thinking about this)


This will be an issue, I call it human-in-the-middle, and it was the only plausible attack vector I could think of. This form of attack could be used to exploit vulnerable populations. For example go to a poor area, offer $1 for anyone to hold a sign and record a video. When they have no idea what the video is - or what they are doing. This potential vulnerability effectively sets the price of one year of UBI at the cost to get someone to verify.

My discussions about this topic have lead me to believe it will be a problem, and that it will be hard to solve without adding complexity. The UX is already burdensome, I am reluctant to add more steps.

A few ideas to handling this (these are just for academic discussion, not well baked and I don’t like adding complexity):

  1. Change the statement to something that acknowledges they will be collecting benefits. For example “… I understand that the owner of the address I am holding will be receiving my benefits, including universal basic income, and voting rights”.
    • Remember we will have dependents (children / elderly / non-tech family), so certifying you are the owner of the address might not work - because you might not be.
  2. Empower challengers with tools. Let them detect potential human-in-the-middle networks and give them a method to challenge. Something like a “consent” request. The challenger puts up the deposit, but UBI is locked. To win the challenge the profile has to take a picture with a sign that shows some unique value (like the transaction hash of the challenge). If they do it they get the deposit from the challenger. If they don’t the challenger gets their UBI. The idea here is smart people can detect human-in-the-middle networks using blockchain / internet forensics, find a way to reward it (and punish the attackers).
  3. Adjust the registration process to force a longer relationship with the human being taken advantage of. Something like:
    • Submission is the same as now, photo, video, and name.
    • After vouching and funding BEFORE moving to “pending registration” (when the challenge period starts) have a one day waiting period.
    • At the end of the one day waiting period you add a photo of yourself to the evidence holding a sign with a hash that the smart contract specifies (based on most recent block or similar).
    • Then the normal challenge period starts, but that third photo would be part of the evidence.

Personally I am a fan of tweaking the registration phrase. I think this would be enough to discourage. Today the registration phrase is very abstract - out of context it doesn’t have meaning.


si pones un reconocimiento de datos biométricos de voz al inicio de sesión de PoH + video ,
como hace KLARWAY;no sería necesaria la prueba de que esta con vida cada 6 meses o 12 .
KLARWAY solo usa datos biométricos faciales
lo usan muchas universidades para que no sea plagiado los exámenes
si usan video + vos sería muy difícil de plagiar

if you put a voice biometric recognition to PoH + video login,
as * KLARWAY * does; the test of humanity would not be necessary.

  • KLARWAY * only uses facial biometric data
    It is used by many universities so that the exams are not plagiarized
    if they use video + you would be very difficult to plagiarize
1 Like

Thanks for starting this thread, Santi!

It’s a tricky attack, and although maybe this is not happening today… it will certainly happen in the future as we gain mass adoption.

This will be an issue, I call it human-in-the-middle, and it was the only plausible attack vector I could think of.

Agreed! It’s the attack I’m most concerned about, by a very large margin.

Possible ways to increase cost of the attack

(summarizing the thread so far and adding some more possibliities):

Increase the coordination/trust required between a puppeteer and their human puppet:

  • Require an additional check after 3 days
  • Require an additional check some random amount of time later, with a limited time to respond (thanks to @clesaege for this idea) — even harder to coordinate against this

Increase the benefits of proof of humanity so that people want to claim it for themselves

  • There may always be a large pool of people who aren’t educated about PoH
    • Though people can prove their understanding during registration on video
  • This incentive might be cancelled out: the greater the benefit, the greater the reward to puppeteers for each human puppet they slip in, and the greater amount they can afford to pay those puppets.

Shrink the pool of willing human puppets

  • Exclude people who learn about the benefits and want them for themselves
    • We could ensure this education by having it be part of what they say on video, if we can ascertain they understand the language they’re speaking
    • However, the larger the benefits of registering, the more revenue the puppeteer earns per bribe, and the larger the bribe they can afford to pay…
  • Exclude people who are unwilling to lie on camera (registration could involve an oath on this topic)

Let community challenge/investigate suspected bribery cases (this is brilliant, @justin!)

  • Offer people being bribed a safe way out
    • We could have videochat sessions where a commnity notary can visually verify that there is no one looking over the human’s shoulder, can ask them to change location (e.g. walk outside)
    • Community notary can ask if anyone offered them money to record a video
    • If notary learns of bribe, they could have a way to invalidate the registered identity without the puppeteer becoming aware (similar to coercion-resistant votes using MACI in Blockchain voting is overrated among uninformed people but underrated among informed people)
    • However, we’d need some way to establish a secure communication line with the human puppet, which I don’t immediately see a way to do: the puppeteer can submit their own contact information and mitm video communications.

Verification scores

  • Perhaps when you initially register with PoH, you’re verified with a medium verification score
  • Then can increase score by taking on additional challenges that would be hard to coordinate with the puppeteer, getting vouches from trusted parts of the graph, etc.
  • Sidenote: hmm — I wonder if rather than requiring renewal every 6 months (not great UX), we could just have a score that decays with the time since last verification. If you wait a year to reverify, your verification score might be quite low — after some years, perhaps your score would be negligible.
    • Projects relying on PoH could have a minimum score requirement and/or could weight by verification score

Next steps

  • Anyone have have more thoughts on how to make this attack more expensive?
    • Even ideas that seem infeasible or have terrible UX it could be good for spurring conversation.
  • How can we get more people thinking about this problem?

To be honest, I really don’t think this attack is a dangerous as it initially seems (deep fakes seen like a much more problematic attack vector).

The best mitigation to this type of attack is a recovery mechanism, whereby the rightful owner of an account can reclaim it with relative ease, coupled with explicit user education on the value of the account.

I quite like the above suggestions of including statement that clearly states the value of the account as part of each human’s registration video. Perhaps something to the effect of “whoever controls this account will receive x UBI per month, currently worth $y USD per month”. Assuming applicants comprehend the words they are saying, this should give them pause to consider the value of what they are giving up and ultimately push the price higher.

Luckily, a recovery mechanism already exists. Any account can be challenged. @Justin suggested to empower challengers with tools to detect people buying accounts. I think this probably boiled down to two things.

  1. Educating users that they can do this, since they will be one of few parties that have certain knowledge of the fraud. Perhaps this can also be part of the statement. Something like “I understand that fraudulent accounts can be challenged and removed by anyone”.
  2. Ensuring users have access to enough capital to put down the bond to create a removal request and a new registration request. It seems like there could bea market-based solution for this; short-term loans to cover the challenge/submission deposit.
1 Like

El idioma que se use es importante . Para uno de sus puntos . Que entienda lo que dice es Básico y esencial

Well in current rules you need to own the address “the full Ethereum address of the

Yeah I expect that to be used as evidence, we could even have a list of challenges that applicants would need to comply with.

Note that submissions are valid 1 year, it will probably be extended through governance but it was initially set conservatively in case some attacks were to succeed in the early days.

The problem is that it would prevent the use of second layer anonymity solutions.


In what way would it prevent the second layer anonymity solution?

1 Like

Second layer anonymity solutions are not compatible with “cancelling” a submission at a time other than its expiration time. This is because the public profile and the private profiles would not be linked so we couldn’t cancel the private profile and the new profile could then make a new private profile sybil attacking the private identity system.

Note that to solve the issue we could allow someone to reclaim a profile but only if he hasn’t made a private profile or at the profile expiration date.

creo que si no es muy entrometido con el tema del anonimato .estaría bien asociar un numero de telefono . y una vez al mes/semana , enviar una frase o un número y que la persona lo responda usando telegram o signal con simple video o solo voz , eso aumentaría mucho la seguridad del PoH y complica mucho al estafador .ya que tendríamos un parámetro más para poder cotejar cuanto tiempo tarda en contestar por ejemplo .
I think if you are not very nosy about anonymity, it would be nice to associate a phone number. and once a month / week, send a phrase or a number and have the person respond using telegram or signal with simple video or only voice, that would greatly increase the security of the PoH and greatly complicate the scammer, since we should have one more parameter to be able to check how long it takes to answer for example.

hhmmm, this seems like a solvable problem with ZKPs though, no?
It would probably require a coordinator, but I think that’s fine.
I would look something like this.

  1. user creates public profile connected to their ETH address
  2. user creates signing key and registers it with their ETH address
  3. Using that signing key, the user can call an on-chain function to send an encrypted message to the coordinator to (i) update their signing key (ii) set an address as their private address (iii) change their private address.

Any time a private profile is used on-chain, it should provide a proof (supplied by the coordinator) that it is both the current private address of a human on the list and that none of the human’s previous private addresses are currently being used in this context.

If a profile is cancelled, then the coordinator should no longer be able to generate a valid proof.

Some further thoughts on this topic: Proof of Humanity: the cost of attack - HackMD

Particularly of interest may be the “Incent the puppet to defect on their puppeteer” section.


I don’t know how to make this kind of ZK proof but some people may. But here we would have the limitation that you only prove being registered at time T (so would need recurrent proofs) while with the other solutions you could prove to be registered for a whole period of time.

I guess this suggestion is too radical to implement but I want to get out there anyway:

Part 1:

Implement/change the profile picture upload to a facial recognition submission as they use in those 60 sec KYC.

Part 2:

Instead of streaming the UBI directly to the user’s wallets. The users have to claim it.

When claiming it you would have to do the facial recognition again which tries to match the original profile picture submission.

If the facial recognition fails it could (optionally) be escalated to the court who can decide whether or not to make the payout.


Throwing out crazy ideas is how real innovation happens! Thanks :pray:

Really creative idea about requiring some validation to claim dripped UBI. Not sure it would work, but is an angle I hand’t thought of.


Yesterday in Tweet a guy, who I think belongs to the community, posted this:


I was thinking about this last night while trying to sleep. There is a need for a middle layer between storage and consumers. For example: process the stored data before providing it to the consumer instead of just giving them access to the actual ipfs path

implement it from this point it would be easier to articulate what 0xf366447b5839932828aa50bdc0d0cc296a6ec6c1_Ethereum mentions or something similar to what I posted above

ayer en Tweet un chico, que creo que pertenece a la comunidad, publicó esto:
Estaba pensando en esto anoche mientras intentaba dormir. Existe la necesidad de una capa intermedia entre el almacenamiento y los consumidores. Por ejemplo: procese los datos almacenados antes de proporcionárselos al consumidor en lugar de simplemente darles acceso a la ruta ipfs real

implementarlo desde este punto sería más fácil articular lo que 0xf366447b5839932828aa50bdc0d0cc296a6ec6c1_Ethereum menciona o algo similar a lo que e publicado anteriormente

1 Like

Took this from a conversation in the tg channel:

Looks like someone’s been paying random people on one street for profile videos

(thinking about a concrete case can be helpful for this discussion)



(Inspiration from the evidence on this submission: Proof of Humanity, a sybil-proof list of humans. and “Primary Document > Challenge Types > Deceased”.

Add another challenge type, e.g., “Suspicious”.

Where the challenger is willing to risk his/her ETH to get a verification on the person attachment to the ETH address.

Add this to the challenge types:

Suspicious : It is expected that the submitter is not the owner of the ETH address.

The challenged submitter can provide a video of him/herself reading a recent block hash. Submitters not able to give recent proof are to be considered the wrongful owner of the ETH address.


OK so this might not work, but let me try. How about when a suspected puppeteer is identified, they can be challenged. The challenge then triggers an immediate need for the puppeteer to make another deposit for each puppet which they can lose if the challenge is won? Again it would be important to differentiate between puppeteers and those who could be appointed ‘PoH ambassadors’ which I think is a great idea.

[Edit: the puppeteer would be identified by their wallet?]