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
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.
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?
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.
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â
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.
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.
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
