Z address length

#1

Is there a reason z-addresses are so long? Does anyone see a way toward customized, short z-addresses, as in user names? For example, instead of “I’ll send you my long z-address and I hope you copy and paste perfectly when you send the ZEC to me” I could say “send it to zs1eric”

1 Like
#2

Unstoppable domains might help you. The .zil domain can serve as a crypto wallet and from what I have heard it can serve as your address for multiple cryptos. I haven’t tried it personally just watched some youtube videos.

It would be better to have it in ZEC natively if possible.

#3

One idea is to use the shielded memo field to set up a “Zcash name registry”. We could send memos to a special registry address and associate names with long z addresses. Then we would just have to get the wallets to check this special address so that the wallet knows what to do if I tell it to send money to “_eric”

Would just need to make the wallet check for duplicate names etc. but it would be pretty straightforward I think.

2 Likes
#4

I like it… this sounds like the address book function in ZecWallet. Afaik, all the address books are siloed, but if there was one master address book to import, or pre-loaded…

1 Like
#5

Yes having one master address book would be amazing. Would have to be first-come first-serve to grab the name you want. Could even have a method is invalidating/transferring ownership of nicknames similar to how people sell regular domain names.

2 Likes
#6

A Sapling z-address contains a 32-byte public key and an 11-byte diversifier, which are concatenated and then encoded using Bech32 to get a 78-character address.

  • The public key is 32 bytes because that is the size of encoded Jubjub group elements, and is necessary to target the 128-bit security level.
  • The diversifier enables diversified addresses. An 11-byte diversifier enables 287 addresses to be generated corresponding to a single spending key, which is a large enough domain to support almost any use case. We picked 11 bytes because that was the largest diversifier space we could have while keeping the Bech32-encoded z-address under 80 characters.

If we had not included diversified addresses in the protocol, the addresses would be around 61 characters long instead of 78. We did include it because for many-to-one use cases (such as large exchanges), diversified addresses provide a huge performance improvement. But even without that feature, the addresses would still be pretty long, much more so than in a petname or registered name system like above (which has its own set of problems).

5 Likes
#7

I was thinking of a system where the z addresses are like ip addresses and the ‘nicknames’ are like domain names, and the dns system is just a z address that everyone has a view key to check? Curious if you have already thought of this and what the problems are?

1 Like
#9

I made an open source CSV file anyone can view, inspect, and import into your ZecWallet address book. Right now, it’s a few charities that accept z2z donations, but could be expanded into a public address book.
https://github.com/ezvaughn/zregistry

1 Like
#10

Added the rest of the charities with public Zcash addresses, even ones with t-addresses. So now you can import into your ZecWallet, the addresses of 30 Zcash-accepting charities.

1 Like