Introduce distinct address encoding prefixes.

[nathan-at-least]

Let's tweak the encodings of z-addresses, and all of the transparent address types to have distinct prefixes from each other and from Bitcoin. For example, let's have z-addresses always begin with "z" or "Z" and have the transparent addresses always begin with "T" or "t".

• Unresolved issue: there are many transparent (Bitcoin) address types with associated prefixes, so how can we add a T prefix to all of them?
• Bonus issue: consider other cryptocurrencies and ensure Zcash address encodings are visually distinct.

[bitcartel]

For transparent addresses, change the pubkey address version from 0 to 65 on this line of code:

zcash/src/chainparams.cpp

Line 102 in 592b2f0

base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,0);

[daira]

Was this fixed by #1026?

[bitcartel]

Doesn't look like it.

Btw, what about the prefix for transparent addresses on testnet? At the moment they are the same as upstream, so they start with 'm' or 'n'.

[daira]

We need to decide on this ASAP in order for it to be included in beta 2.

[jackgavigan]

Idea: Make the prefix two digits (e.g. z0) so that we can have a different prefix (e.g. z1) in future. NRR (No response required).

[nathan-at-least]

Let's do a 1-engineer-day timebox to experiment with this scheme: all bitcoin addresses are prefixed with an additional 'T' in their encoding. This is in addition to their bitcoin-classification prefixes (eg: 1- for pubkey hash, 3- for script hash, etc...

We believe codifying that change is somewhat simple, except it will break many test vectors. If we can fix all of those test vectors in 1 day, then there's still an impact for all third-party tool development.

[str4d]

We are now considering #812 (comment) for z-addrs, and potentially a similar setup for t-addrs (so e.g. T11- for pubkey hash, T13- for script hash, etc...)

The difference to #812 (comment) is that transparent addresses would have 3 prefix bytes instead of 2. Both of these would require about the same amount of work to implement.

[daira]

I don't think that 3 prefix characters are necessary. What's wrong with just having T as the prefix for transparent addresses, as the current (2016.0-beta-1.6) spec says? Either way we need to make this decision now, preferably today, and stick to it.

[daira]

@nathan-at-least wrote on Slack:

@daira: I delegate to you. My main goal is Z or z prefix for all mainnet z-addrs, and T or t address for all [mainnet] t-addrs, and no ambiguity between mainnet and testnet addrs. If those prefixes also applied to testnet, or if there are subsequent characters such as for versioning, that's fine with me.

-oh, and I wanted to retain all of Bitcoin's encoded distinctions.

I'm a bit worried about how much havoc this might cause throughout zcashd itself as well as the larger ecosystem…

[daira]

@luke-jr helpfully clarified a point I was confused about: the mapping between prefix and leading characters depends on the length. (All of our address formats are fixed-length, so that doesn't present a problem.)

[daira]

The current lead characters are:

• zc for mainnet z-addresses
• SK for mainnet spending keys

and:

• tn for testnet z-addresses
• TK for testnet spending keys
• transparent addresses and keys as Bitcoin

If we are changing "transparent" to "revealed", then I'll prefix those addresses with "r":

• r1 for mainnet P2PKH
• r3 for mainnet P2SH
• rm for testnet P2PKH
• r2 for testnet P2SH

(This does not conflict with any of the altcoin prefixes listed here.)

[daira]

The current lead characters are now:

• zc for mainnet z-addresses
• SK for mainnet spending keys
• t1 for mainnet P2PKH addresses
• t3 for mainnet P2SH addresses

and:

• zt for testnet z-addresses
• ST for testnet spending keys
• tm for testnet P2PKH addresses
• t2 for testnet P2SH addresses
• transparent keys as Bitcoin