- The speaker is discussing the problem of phishing and how it relates to shortened addresses.
- They propose a way to show the length of zeros in an address to make phishing more difficult.
- They ask for suggestions on what to call these addresses and how to better represent them.
- The issue of shortening addresses in general is also discussed, with the need for users to have a way to check the full address.
- The speaker suggests that a standard way to represent the zeros would be a partial solution to the problem.
- The importance of verifying addresses and the responsibility of wallets in displaying them is emphasized.

- The speaker discusses the issue of displaying accurate information on wallet models when interacting with different apps.
- They suggest a joint effort between apps and wallets to maintain their own registries of legitimate projects.
- The speaker acknowledges the difficulty in finding a solution and suggests displaying the full address or a name provided by the wallet instead of shortened addresses.
- They mention the trade-off between displaying the full text and whether users will actually read it.
- The conversation includes suggestions for compressing redundant parts of addresses and the need for empirical testing to determine the safest method of shortening addresses.
- The speaker emphasizes the importance of users comparing the entirety of the address and acknowledges the risk involved in shortening addresses.
- They express the need for more suggestions on how to better display shortened addresses.
- The speaker suggests creating a Discord channel for wallet developers to discuss these issues.

So everyone, thanks for the opportunity for this all wallet dev.

I want to come back to a topic that I presented this meeting last time.

So basically the concept is that we realized that the threat of phishing is a problem And we have seen industry using, let's say, ETH 2.0 deposit contract has 8 zeros.

So traditionally, wallet will show the address of open C as this.

And if it's shortened, it will look like this.

And it doesn't help much with only 4 zeros showing up and an at last 1, because anyone who want to fish can still create this.

And so it would be ideal if we can come up with some way to show the length of zeros and then the 4 starting, 4 ending, it will make the phishing this much harder.

And so I'm gonna, so that's why I'm wanna bring it to today's meeting for a way to propose 1 way to show the wallets in a shorthand way when there are multiple leading zeros.

I don't have a good name for small address or rare address, but basically you get the point.

So suggestion would be greatly appreciated of what, how do we call these kind of address and how do we better show the address.

I'm just proposing this as a way to get inspiration.

So you're suggesting putting a 13 in curly braces before the X?

I don't have a good idea about how it could be best present, represent, but I think it would be good if we can account, let the short form account for the fact that it has a lot of zeros.

I'm asking the participants what, is it a good way or if there is other ways to represent it?

But at first I think, is it a good idea to represent these many zeros where the fact that there are a lot of zeros.

And that's the first question I want to ask the audience, the participants.

So what I would say on that is that you need to have a useful reference for how many zeros it should have displayed elsewhere.

Because otherwise, a user is still going to click through because they're not cognizant of how many leading zeros there should be.

Yeah, it's the that's why I think a standard will be helpful because if everyone is just deciding to use the same way to represent it when users see references from other side let's say they see it on their wallet and then they go to ether scan.

If they both shows to be represented in the same way that user can, can better compare.

But if user aren't seeing it out elsewhere, if only 1 wallet is implementing this short form or any extra short form, then user wouldn't even be able to know.

I think this is, you know, kind of a general problem because just shortening addresses at all has this issue, right?

If you cut out the middle part of the address and only display the first 4 and the last 4, or something along those lines, you still need a way to check the whole address, you know what I mean?

So like, I don't know if we want something specifically for zeros, or if we want something that works for just shortening addresses generally.

So, yes, you need other ways for users to check the full length.

And then ultimately, I think the domain names is a good way.

But in this particular case, solving 1 problem at a time, I think if we can come up with a standard way to represent at least the zeros, which is the practice that the industry is picking up, then we solve the problem with partial solution better than it is right now and at least help some of those legitimate projects.

So let's say, even if you only display 4 characters, like 2 before and 2 after, if you have 13 zeros, you have to mine 13 plus 7 to make it look like the same.

I mean, I don't really have any particular input.

Jeff has to rejoin because he didn't have microphone permission.

This is the first, it's the first 1 that I'm joining.

I'm Pivo from a protocol that's called MinFinance.

We do DCA stuff, just cool stuff around GoLibP.

So I wanted to chime a little bit in about this.

So talking about showing addresses to users is when we talk about the UX here, I think it goes a little bit beyond just showing a button to show numbers.

The most common user is not going to be able to recognize anywhere, right?

So what I think we as a community, as a dev community should aim for is to try to start hiding addresses as much as we can without being without letting the users not verify them, right?

So in this example, the Uniswap Permit2 contract, I wouldn't like to show the user 0x000 stuff.

I would just say, hey, you're interacting with the new subprime to contract.

If you want to click on it, I can show you the full address for that.

So you can verify that it's actually the contract you want to interrupt.

But I think we should start trying aiming to not actually short any addresses, because that's just the same problem that we have right now where you see an address and you don't know what it's linked to, but maybe letting the user go.

Yeah, yeah, I think we are in very much agreement with that.

The problem is that there will be Fisher who comes out and says, hey, we are Permit2.

And so can you use us and approve with us to interact with Uniswap and then take your money?

And we're trying to solve a problem in a lower level when a Fisher comes up and says, Hey, we are Uniswap permit 2.

And then actually we have a address that looks very similar to Uniswap.

That's the problem we're trying to solve today.

So I think this this problem specifically is where do we tackle it?

So who should be tackling the issue of how we show how we display addresses?

Should we leave that responsibility to the wallets?

There are the end users, a final approach into either configuring a transaction, signing a transaction, signing a message, etc., etc., etc.

Or should we leave it up to each specific application to handle?

I think it should go into the wallet space, right?

So each wallet should try to keep up to date as much as they can, because it's really hard to, to at least the most known protocols on what their contracts are.

So we can, so for example, if MetaMask, I'm in charge with the Uniswap Permit2 contract, I would love for MetaMask to tell me, hey, you're interacting with the Uniswap Permit2 contract.

And if I go into a patient site and they say, hey, you're about to interact with Uniswap Permit2, and I click to sign a transaction or whatever, and my Metamask model pops up.

In my Metamask model, it shouldn't say Unix app permit to anywhere else, right?

So that's kind of the point I'm trying to aim for.

I don't think I have the right solution for this.

I don't know if there's a silver bullet to handle this.

I think it should be more of a joint effort between both.

Apps should be able to keep their own registry.

Wallets are identifying to a specific domain, for example, Fermi2, and also wallets should try to maintain that record too.

It's hard, I know, I don't see how we could improve this.

I agree with you that it would be good for the wallet to also support that.

And then I think that's a separate solutions that we can also consider.

And there's nothing preventing us from solving the both.

And then it take time for the mass adoptions of all those wallets to also have their own list of legitimate projects that they think.

Yeah, so, and then we still, as a decentralized and permissionless space, we still want user to be verified at the end of the day, right?

We're not like Twitter, and who says, Hey, if we Twitter consider this is illegitimate, we will take you down and a user of should not be interacting with it.

So at the end of day, it's up to the user what they want to interact with and they need to have a way to vary things.

Yeah, so I think I love to hear wallet builders, what your thoughts about having a way to show the address so users can easily compare the contract or the wallet they're interacting with with the 1 that they intend to.

I mean, maybe the recommendation should be that you don't display shortened addresses.

So either you display a name that the wallet provides, or you provide the full address and you just never show shortened addresses.

It's just that if I swap 1 address from here, user is still very likely to mistaken them.

So if it's a very long address and then I swap, I managed to make it very similar to yours.

And the longer the address are, the longer it is going to be.

Easier to confuse user, just like how you never.

So back in the day, people will display summarize of the term of use of a website for users to understand them before they click yes.

And then I think the current general approach is that they will show the full thing and so user will never look into them.

So there is a trade-off we made when we show the full text versus and whether user will look at them.

Not to pass any value on, you know, if we should implement it or not, but maybe just a general comment about the idea.

There's a lot of zeros in like vanity type wallets, but there are other values that are repeated.

So like multiple ones, multiple of a letter, something like that.

So the approach that you took right now is 0, 13, and then the part of the address that comes after it.

It might be beneficial to keep the 0x and then just compress the parts that come after that and are redundant.

So something like Maybe something like this, right?

Yeah, and this way it could work on anything.

Yeah, I still think it's ill-advised to give the shortened address, but it would be better to do it this way than maybe another.

It's generally people don't shorten them at all.

It's that they will highlight, for example, a lot of what address will highlight the part for user to at least check.

So they say if you don't have time to check every single character and make sure you're not reading the shifted, the shifted characters, at least check these 8, the top 4 and top last 4.

And I agree if user can do it every time, that's great.

And so I'm all for showing the full address.

It's just that we also find that users don't look at them at all.

I mean, I feel like this should be something we can do empirically, make a little web page that compares different ways of shortening addresses and find out which ones people are the best at telling the difference between.

Because I don't think we can just guess at what the safest method is going to be.

Because like shortening it at all is going to be a problem.

Like, shorting an address is always going to be a risk.

No matter how we short it, how we want, what do we want to include or not, it's always going to be a risk because you're not looking at the full address.

And even if you're looking at the full address, it's very easy to not see like a little difference between number, letter, and uppercase, lowercase, just because I get confused, for example, between the eye and the eye, sorry, English is not my native, so a little trouble pronouncing the vocals.

There's the way to show them is not perfect right now.

We can ask for more suggestion on how the better to show the short form, but in general, we will advise user that it's better that they compare the entire entirety.

So this is just here to put before all the wallet developers because I don't know any other better venue to talk about this.

Would you like a Discord channel for this maybe?

I find it much easier to get feedback asynchronously from this group.

Yeah, that'd be great inside of wallet, Ethereum wallet, right?

I'm wondering, it's a warrant a separate place, very legitimate.

I think that's everything we had scheduled.

Again, a little notice that 6963 has gone to final.

So if you're a wallet implementer, take a look at it.

It lets you have multiple wallets on the same page.

And with that, I guess that's the end of this meeting.


Speaker 0: Sounds good. So everyone, thanks for the opportunity for this all wallet dev. I want to come back to a topic that I presented this meeting last time. Can I share?

Speaker 1: Go for it. So, Go for it.

Speaker 0: So basically the concept is that we realized that the threat of phishing is a problem And we have seen industry using, let's say, ETH 2.0 deposit contract has 8 zeros. Uniswap has 10 zeros. Increasingly, OpenSea have 13 zeros. So traditionally, wallet will show the address of open C as this. And if it's shortened, it will look like this.

And it doesn't help much with only 4 zeros showing up and an at last 1, because anyone who want to fish can still create this. And so it would be ideal if we can come up with some way to show the length of zeros and then the 4 starting, 4 ending, it will make the phishing this much harder. And so I'm gonna, so that's why I'm wanna bring it to today's meeting for a way to propose 1 way to show the wallets in a shorthand way when there are multiple leading zeros. I don't have a good name for small address or rare address, but basically you get the point. So suggestion would be greatly appreciated of what, how do we call these kind of address and how do we better show the address.

I'm just proposing this as a way to get inspiration.

Speaker 2: So you're suggesting putting a 13 in curly braces before the X?

Speaker 0: I don't have a good idea about how it could be best present, represent, but I think it would be good if we can account, let the short form account for the fact that it has a lot of zeros. So maybe this is not the best way. I'm asking the participants what, is it a good way or if there is other ways to represent it? But at first I think, is it a good idea to represent these many zeros where the fact that there are a lot of zeros. And that's the first question I want to ask the audience, the participants.

Speaker 3: So what I would say on that is that you need to have a useful reference for how many zeros it should have displayed elsewhere. Because otherwise, a user is still going to click through because they're not cognizant of how many leading zeros there should be.

Speaker 0: Yes, that's true. Yeah, it's the that's why I think a standard will be helpful because if everyone is just deciding to use the same way to represent it when users see references from other side let's say they see it on their wallet and then they go to ether scan. If they both shows to be represented in the same way that user can, can better compare. But if user aren't seeing it out elsewhere, if only 1 wallet is implementing this short form or any extra short form, then user wouldn't even be able to know.

Speaker 2: I think this is, you know, kind of a general problem because just shortening addresses at all has this issue, right? If you cut out the middle part of the address and only display the first 4 and the last 4, or something along those lines, you still need a way to check the whole address, you know what I mean? So like, I don't know if we want something specifically for zeros, or if we want something that works for just shortening addresses generally.

Speaker 0: So, yes, you need other ways for users to check the full length. And then ultimately, I think the domain names is a good way. But in this particular case, solving 1 problem at a time, I think if we can come up with a standard way to represent at least the zeros, which is the practice that the industry is picking up, then we solve the problem with partial solution better than it is right now and at least help some of those legitimate projects. So let's say, even if you only display 4 characters, like 2 before and 2 after, if you have 13 zeros, you have to mine 13 plus 7 to make it look like the same. And that's very, very hard.

That's like 16 to the 17 large number.

Speaker 2: Yeah, that's true. I mean, I don't really have any particular input. I just think it needs to be considered. That's all.

Speaker 0: Yeah.

Speaker 1: Hey guys. Sorry, can you hear me? Jeff has to rejoin because he didn't have microphone permission.

Speaker 2: Yeah, we can hear you. I'm glad

Speaker 0: to have you back.

Speaker 1: Perfect, perfect. Hi, just a bit of introductions. This is the first, it's the first 1 that I'm joining. I'm Pivo from a protocol that's called MinFinance. We do DCA stuff, just cool stuff around GoLibP.

So I wanted to chime a little bit in about this. So talking about showing addresses to users is when we talk about the UX here, I think it goes a little bit beyond just showing a button to show numbers. The most common user is not going to be able to recognize anywhere, right? So what I think we as a community, as a dev community should aim for is to try to start hiding addresses as much as we can without being without letting the users not verify them, right? So in this example, the Uniswap Permit2 contract, I wouldn't like to show the user 0x000 stuff.

I would just say, hey, you're interacting with the new subprime to contract. If you want to click on it, I can show you the full address for that. So you can verify that it's actually the contract you want to interrupt. But I think we should start trying aiming to not actually short any addresses, because that's just the same problem that we have right now where you see an address and you don't know what it's linked to, but maybe letting the user go. Yeah, sorry.

Speaker 0: Yeah, yeah, I think we are in very much agreement with that. The problem is that there will be Fisher who comes out and says, hey, we are Permit2. And so can you use us and approve with us to interact with Uniswap and then take your money? And we're trying to solve a problem in a lower level when a Fisher comes up and says, Hey, we are Uniswap permit 2. And then actually we have a address that looks very similar to Uniswap.

And that's the problem. That's the problem we're trying to solve today.

Speaker 1: Yeah. Yeah. A hundred percent. III agree with you on this. So I think this this problem specifically is where do we tackle it?

Right. So who should be tackling the issue of how we show how we display addresses? Should we leave that responsibility to the wallets? There are the end users, a final approach into either configuring a transaction, signing a transaction, signing a message, etc., etc., etc. Or should we leave it up to each specific application to handle?

I think it should go into the wallet space, right? So each wallet should try to keep up to date as much as they can, because it's really hard to, to at least the most known protocols on what their contracts are. So we can, so for example, if MetaMask, I'm in charge with the Uniswap Permit2 contract, I would love for MetaMask to tell me, hey, you're interacting with the Uniswap Permit2 contract. And if I go into a patient site and they say, hey, you're about to interact with Uniswap Permit2, and I click to sign a transaction or whatever, and my Metamask model pops up. In my Metamask model, it shouldn't say Unix app permit to anywhere else, right?

So that's kind of the point I'm trying to aim for. I don't think I have the right solution for this. I don't know if there's a silver bullet to handle this. Like, where should it go? I think it should be more of a joint effort between both.

Apps should be able to keep their own registry. Wallets are identifying to a specific domain, for example, Fermi2, and also wallets should try to maintain that record too. It's hard, I know, I don't see how we could improve this.

Speaker 0: I agree with you that it would be good for the wallet to also support that. And then I think that's a separate solutions that we can also consider. And there's nothing preventing us from solving the both. And then it take time for the mass adoptions of all those wallets to also have their own list of legitimate projects that they think. Yeah, so, and then we still, as a decentralized and permissionless space, we still want user to be verified at the end of the day, right?

We're not like Twitter, and who says, Hey, if we Twitter consider this is illegitimate, we will take you down and a user of should not be interacting with it. This is permissionless. So at the end of day, it's up to the user what they want to interact with and they need to have a way to vary things. Yeah, so I think I love to hear wallet builders, what your thoughts about having a way to show the address so users can easily compare the contract or the wallet they're interacting with with the 1 that they intend to.

Speaker 2: I mean, maybe the recommendation should be that you don't display shortened addresses. So either you display a name that the wallet provides, or you provide the full address and you just never show shortened addresses.

Speaker 0: Effectively, that's a way to do it. It's just that if I swap 1 address from here, user is still very likely to mistaken them. So if it's a very long address and then I swap, I managed to make it very similar to yours. User can get confused. And the longer the address are, the longer it is going to be.

Easier to confuse user, just like how you never. So back in the day, people will display summarize of the term of use of a website for users to understand them before they click yes. And then I think the current general approach is that they will show the full thing and so user will never look into them. So there is a trade-off we made when we show the full text versus and whether user will look at them.

Speaker 4: Not to pass any value on, you know, if we should implement it or not, but maybe just a general comment about the idea. There's a lot of zeros in like vanity type wallets, but there are other values that are repeated. So like multiple ones, multiple of a letter, something like that. So the approach that you took right now is 0, 13, and then the part of the address that comes after it. It might be beneficial to keep the 0x and then just compress the parts that come after that and are redundant.

Speaker 0: Oh, that's a very helpful suggestion. So something like Maybe something like this, right?

Speaker 4: Yeah, and this way it could work on anything.

Speaker 0: Different address.

Speaker 4: Yeah, I still think it's ill-advised to give the shortened address, but it would be better to do it this way than maybe another.

Speaker 0: Yeah. It's generally people don't shorten them at all. It's that they will highlight, for example, a lot of what address will highlight the part for user to at least check. So they say if you don't have time to check every single character and make sure you're not reading the shifted, the shifted characters, at least check these 8, the top 4 and top last 4. And I agree if user can do it every time, that's great.

And so I'm all for showing the full address. It's just that we also find that users don't look at them at all.

Speaker 2: I mean, I feel like this should be something we can do empirically, make a little web page that compares different ways of shortening addresses and find out which ones people are the best at telling the difference between. Because I don't think we can just guess at what the safest method is going to be. Because like shortening it at all is going to be a problem.

Speaker 0: So. Right, right. Yeah. And also, sorry, I cut you off. Go ahead.

Speaker 1: No, I just said that I agree with that. Like, shorting an address is always going to be a risk. No matter how we short it, how we want, what do we want to include or not, it's always going to be a risk because you're not looking at the full address. And even if you're looking at the full address, it's very easy to not see like a little difference between number, letter, and uppercase, lowercase, just because I get confused, for example, between the eye and the eye, sorry, English is not my native, so a little trouble pronouncing the vocals. But yeah.

Yeah, I just thought.

Speaker 0: Yeah. Yeah, I agree. There's the way to show them is not perfect right now. And also, we can have more. We can ask for more suggestion on how the better to show the short form, but in general, we will advise user that it's better that they compare the entire entirety.

Yeah. So this is just here to put before all the wallet developers because I don't know any other better venue to talk about this. Thanks for hearing me.

Speaker 2: Would you like a Discord channel for this maybe? I find it much easier to get feedback asynchronously from this group.

Speaker 0: Yeah, that'd be great inside of wallet, Ethereum wallet, right?

Speaker 1: Yep.

Speaker 0: I'm wondering, it's a warrant a separate place, very legitimate.

Speaker 1: Cool.

Speaker 2: Cool. I think that's everything we had scheduled. Again, a little notice that 6963 has gone to final. So if you're a wallet implementer, take a look at it. It lets you have multiple wallets on the same page.

And with that, I guess that's the end of this meeting. Thanks, everyone.

See all Ethereum Cat Herders transcripts on Youtube

All Wallet Devs#17