Title: ERC__Short_Representation_for_Leading_Zeros_in_Add
Category: ERCs

Author: xinbenlv
Date: 2023-12-20T17:26:49.313Z

Hi, as I presented in previous AllWalletDevs about a proposal to represent leading zeros in address which reduces chance of phishing, I am thinking of starting an ERC.
Motivation

reduce phishing

Specification
The format will be 0{N}xAA..BBBB, where

N is the number of leading zeros in decimal form
AA is the two hex digits of two digits since first non-zero hex digit
BBBB is the last four hex digits

Rationale

We choose 0{N}x format so it can be easily differentiate from 0x
We choose 2 digits before and 4 digits after in the non-zero part, instead of 4,4 for length restriction, but up for discussion
We choose to turn into upper case ditching ERC-55 or ERC-1191 because those case switching no longer serves the purpose of checksum.
We shall anticipate the short-form will need to be compatible with assumptions made in CAIPs

Reference Implementation
// Javascript
function convertHexString(hexString) {
    // Ensure the input is a string
    if (typeof hexString !== 'string') {
        throw new Error('Input must be a string.');
    }

    // Regex to match leading zeros
    const leadingZeros = hexString.match(/^0x0+/);
    if (!leadingZeros) {
        return hexString.toUpperCase(); // Return original in uppercase if no leading zeros
    }

    const zeroCount = leadingZeros[0].length - 2; // Subtract 2 for '0x'
    const remainingString = hexString.slice(zeroCount + 2).toUpperCase(); // +2 for '0x', then convert to uppercase
    const truncated = remainingString.substring(0, 2) + '...' + remainingString.slice(-4);

    return `0{${zeroCount}}x${truncated}`;
}

// Example usage
const result = convertHexString('0x00000000219ab540356cbb839cbe05303d7705fa');
console.log(result); // Outputs: 0{8}x21...05FA

Test




original
short
note




0x00000000219ab540356cbb839cbe05303d7705fa
0{8}x21...05FA
ETH 2.0 deposit


0x000000000022d473030f116ddee9f6b43ac78ba3
0{10}x22...8BA3
Uniswap Permit2


0x0000000000A39bb272e79075ade125fd351887Ac
0{10}xA3...87AC
Blur


0x00000000000000adc04c56bf30ac9d3c0aaf14dc
0{14}xAD...14DC
OpenSea Seaport 1.4



Soliciting Reviewers
We kindly invite the following reviewers for feedback

ERC-55: @vbuterin Vitalik Buterin <vitalik.buterin@ethereum.org>, @alexvandesande , Alex Van de Sande <avsa@ethereum.org>
ERC-1191 authors: Juliano Rizzo (@juli)
CAIPs: @ligi, @bumblefudge
ethers.js @ricmoo
HomeWork / OpenSea: @0age
MetaMask: @frangio

And anyone whose work and interest involves short form address representation.

Author: wjmelements
Date: 2023-12-20T19:40:59.678Z

The 0x prefix signals that the constant literal immediate is hexadecimal. This prefix should not be split up.
The syntax you suggest is similar to the regular expression syntax but it is not a valid regular expression.
For both of these reasons your suggested format is an abomination.
Hiding the middle digits also increases the ease of phishing, though this is your supposed motivation.
I’d be more interested in a solution like Bitcoin’s base58 which would increase the number of bits encoded per character while remaining alphanumeric.

Author: wjmelements
Date: 2023-12-20T21:46:33.735Z

wjmelements:

I’d be more interested in a solution like Bitcoin’s base58 which would increase the number of bits encoded per character while remaining alphanumeric.


Unicode emoji are good candidates for compressed addresses since they are easy to recognize. There are almost 4000 of them so far.

Author: bumblefudge
Date: 2023-12-21T23:51:23.035Z

If you like Base58-style encoding gymnastics, you are gonna LOVE the multibase project over in IPFS land:

github.com/multiformats/multibase








feat: add base256emoji


master ← Jorropo:base256emoji



          opened 03:04AM - 04 Dec 21 UTC




            Jorropo
          



+570
-25






I think this should be merged because :
- It's fun and allows us have an almost… endless of fun in docs and trolling opportunities.
- Most of the NFT community likes useless differentiation features, why not giving what they want ?
- It's a good test for unicode based encodings in current implementations.
- It makes for a great education tool about what the spirit of multiformats is about (I found that some new people over sacralise what a CID is, if we allows dumb stuff like that I think it will be helpfull to explain to people that things are really extensible and you can make whatever you want on top of it).
- It's not taking valuable prefix space (the 🚀 preffix is very unlikely to ever be used by anything else).
- Implementations that doesn't support unicode will just error with codec not found (since the first byte of 🚀 is not valid ascii nor unicode it would be wrong from us to use as a prefix).

### TL;DR:
I think it has a very slight positive impact and no negative impact, let's merge this. :)

Author: bumblefudge
Date: 2023-12-21T23:56:01.149Z

wjmelements:

For both of these reasons your suggested format is an abomination.


I’m not sure I’d go as far as abomination but I agree that this scheme risks being confused for or mistaken for schemes it rhymes with but breaks.  What about something like
0x0*8x21...05FA or 0x8x21...05FA?
Another wierd nit while we’re in pre-draft spitballing phase-- don’t those 00 always come in pairs? Wouldn’t it be 0x4x21... since there are 4 bits of 00 rather than 8 characters of 0?

Author: xinbenlv
Date: 2023-12-22T01:39:29.845Z

bumblefudge:

I’m not sure I’d go as far as abomination but I agree that this scheme risks being confused for or mistaken for schemes it rhymes with but breaks. What about something like
0x0*8x21...05FA or 0x8x21...05FA?


You mean compare to
0{8}x21…05FA, use 0x0*8x21...05FA or 0x8x21...05FA
I think that’s doable!
The pros is that they are less like RegEx. Though the cons is they might look more like a math formular.
I am totally open to all suggestions regarding the best format. Having your opinion helps we gauge possible response from broader user base.



 bumblefudge:

Another wierd nit while we’re in pre-draft spitballing phase-- why don’t those 00 always come in pairs? Wouldn’t it be 0x4x21... since there are 4 bits that are 00 rather than 8 that are 0?


I think it’s possible there are odd number of zeros and it’s easier for general (non-tech) user to understand “this is the first non-zero digit” as opposed on zero always come in pair because its a “byte”

Author: bumblefudge
Date: 2023-12-22T01:40:32.380Z

but the first byte of 000005 isn’t 5 it’s 05-- i take your point, tho, 0x2x05 might be confusing to a normie

Author: xinbenlv
Date: 2023-12-22T01:45:08.405Z

wjmelements:

The 0x prefix signals that the constant literal immediate is hexadecimal. This prefix should not be split up.


Yes. That’s a rationale that deserves consideration. In that case it could be something like
{9}0x1234, but it may confuse user to think 0x1234 is the beginning of full 20bytes wallet address. I am still debating whether it’s better or less ideal.



 wjmelements:

The syntax you suggest is similar to the regular expression syntax but it is not a valid regular expression.


It’s possible for someone like you and I who are developers to be confused it with RegEx.
If our target is end user who are general and non-tech savvy, RegEx is not a widely known thing outside of developers. I won’t worry too much about it being confused with RegEx.



 wjmelements:

Hiding the middle digits also increases the ease of phishing, though this is your supposed motivation.
I’d be more interested in a solution like Bitcoin’s base58 which would increase the number of bits encoded per character while remaining alphanumeric.


That’s possible, except for that it could create a bigger barrier to existing EVM wallet users, it’s too much a change and a much higher learning curve. Also could mistaken user from recognizing them and compare it with the hex string

Author: xinbenlv
Date: 2023-12-28T02:14:09.828Z

I encountered this scam attempt today
image3456×1754 718 KB

Author: wjmelements
Date: 2023-12-28T23:03:20.484Z

Can that wallet’s “Address book” feature help with distinguishing these addresses?

Author: wjmelements
Date: 2024-04-01T00:05:19.218Z

I have created an ERC for this solution.



ERC: Distinguishable Account Addresses EIPs


    Addressing several recurring topics in this forum, this will improve the resiliency of account addresses against spoofing attacks.