[Phase 2] HIP 27: Allow 1 character mistakes in displayed address (Updated)

HIP: 27
title: Allow 1-character mistakes in displayed addresses
author: @Mizu @juanu
status: Phase 2
created: 2021-11-19

Republish Motivation:

Even though the previous version of this HIP did not make it past Phase-2 (HIP-27), it is visible that it wasn’t given enough exposure, given the amount of votes and the number of participants. Since there was a discussion already for it on Phase-1, it is assumed that it can go to Phase-2 again, but we will give more exposure for enough people to vote on it.
The issue trying to be solved is one that has happened more than once and has impacted on the confidence of the Proof of Humanity project, when humans were challenged because of a Honest Mistake.
As stated by Vitalik Buterin when speaking about this on the Proof of Humanity telegram group, the penalty for a honest mistake is to harsh. This proposal helps building a safety net for those honest mistakes.
Since this a Human DAO, we should allow honest Human mistakes.
One such recent case is of the following user, who made the mistake of adding an extra character. After seeing the problem, he tried to appeal to the case assuming single characters because of a human error. He tried to appeal (paying more fee), but his case is likely to be lost on the Kleros court, losing him all the money he puty on registration and appeals.
SEE latest case: Kleros Case #979

Simple Summary

This proposal would modify the registry policy to allow for limited mistakes or omissions in the address displayed in a profile’s video.


Many profiles get challenged due to mistakes affecting a single character in the address displayed by the submitter in their video. This proposal would make it so a single such mistake would no longer be grounds for rejection. This would not reduce the security of the profile or the PoH registry in any practical terms as will be demonstrated below.

Submitters will often write down their address by hand instead of printing it or displaying it on another screen. This might be because they don’t have a printer or another device with a screen they can easily display it on, or simply because they find writing the address by hand to be more convenient at that time.

As one might expect, it is often the case that submitters make mistakes when copying their address. Sometimes, these are significant errors such as the omission of a large part of the address, in which case it might be possible for an attacker to generate matching addresses, but often the error will affect only one character. We may distinguish 4 types of errors:

- omitted character: a character is omitted from the address (e.g. “abcd” → “abd”)
- mistaken character: a different character has been written in place of the one expected in that position (e.g. “abcd” → “ab9d”)
- swapped adjacent characters: two characters adjacent to each other have been swapped (e.g. “abcd” → “acbd”)
- additional character: an additional character has been inserted anywhere in the address (e.g. “abcd” → “abc0d”)

This proposal would allow at most one of the above three errors in a displayed address. The effects on the security of an address (i.e. on the ability of an attacker to find a private key generating an address which would match the displayed address) would be the following:

- omitted character: 9.32 bits: lg(40*16): 40 positions to insert the missing character which has 16 possible values
- mistaken character: 9.23 bits: lg(40*15): 40 characters with 15 possible invalid values each
- swapped adjacent characters: 5.29 bits: lg(39): 39 possible swaps of adjacent characters, although note that this can be slightly lower still since not all swaps have an effect (e.g. in “abbd”, swapping the two "b"s has no effect)
- additional character: 5.36 bits: lg(41): 41 choices for which character to delete

Note that if a character is missing (case 1.) the three other cases are no longer allowed, and conversely, if the displayed address has all 40 characters (case 2. and 3.), the first and fourth cases are no longer allowed, and if there is an extra character, then only case 4. may be considered. As a result the maximum security loss is max(lg(N_1), lg(N_2 + N_3), lg(N_4)) = max(9.32, 9.32, 5.36) = 9.32 bits, reducing the total security of an address from 160 to 150.68 bits. Given the low stakes involved in being able to create a fake profile with an existing PoH registration video and the fact that no one is likely to be able to crack 150 bits of an Ethereum key for the foreseeable future, this should be an acceptable security compromise.

At this point, it is worth noting that there is one disadvantage to this proposal: It will no longer be possible to find a person’s profile from the video alone without trying all possible allowed errors, which is to say 639 trials in the worst case. This is easily remedied with a simple software loop, but something to keep in mind.


The following text will be appended at the end of the first bullet point of subsection 4. of the “List of current required/optional elements and submission rules”:

A single one of the following errors occurring once will be tolerated in the displayed address:
- omitted character: a character is omitted from the address (e.g. “abcd” → “abd”)
- mistaken character: a different character has been written in place of the one expected in that position (e.g. “abcd” → “ab9d”)
- swapped adjacent characters: two characters adjacent to each other have been swapped (e.g. “abcd” → “acbd”, but not “adcb”)
- additional character: an additional character has been inserted anywhere in the address (e.g. “abcd” → “abc0d”)

As stated on the effects on security, 1 character does not add a great impact on security, but it does greatly impact on UX and humans registering making honest mistakes.
It could be argued that in a future time, we could be allowing more characters mistakes, which would lead to a slippery slope. The key point is to maintain security and adding more characters would have a greater impact on security. 1 character mistakes can be considered as a good balance between honest mistakes while maintaining security.



Please, approve this. Humans make errors, which makes us human after all. Minor typos should be acceptable.


Excelent! Thanks to @mizu as well for the writing of the first version of this.

1 Like

Right now it looks like it will pass, but i find myself uneasy when the polling is close as it indicates to me that perhaps something still hasn’t been considered in the discussions that is being voiced in the vote.

For those voting no change, especially those with extra votes delegated to them, I’d be really interested to hear your opinions so we can work to address them.

1 Like

Could you clarify this a little bit?

Sure. There is 40% of the vote saying they don’t want this, which is fine and they absolutely have the right to do so, but i’d like to know why they don’t want it, in case we have completely missed something.

Do 40% of the voters have concerns which have been voiced but are unsatisfied/unconvinced with the responses which were given (so we need to improve communication of the issues and remedies).
Or are there other problems that haven’t been raised in the discussion that are causing people to vote against it, and are these important/critical ideas that we need to hear, or smaller issues that can be negotiated.

Are the oppositions from people who are actively challenging profiles and it wont be worth it for them if we remove this source of income? or is it app developers concerned with integrating with the registry? Did they just misunderstand the proposal? or do they have another proposal they are working on which they think is a better solution?

What seems like a positive and harmless change to many of us clearly has opponents, so how do we satisfy the concerns of the 74/196 (as of writing) people who aren’t happy with it, what is their role and how will they be impacted, and how can this be addressed in Phase 3