Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce distinct address encoding prefixes. #812

Closed
nathan-at-least opened this issue Mar 29, 2016 · 12 comments
Closed

Introduce distinct address encoding prefixes. #812

nathan-at-least opened this issue Mar 29, 2016 · 12 comments
Assignees
Labels
A-documentation Area: Documentation A-rpc-interface Area: RPC interface M-has-pr To-be-removed (GitHub has linked:pr filter) protocol spec usability

Comments

@nathan-at-least
Copy link
Contributor

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.
@nathan-at-least nathan-at-least added A-documentation Area: Documentation usability A-rpc-interface Area: RPC interface labels Mar 29, 2016
@nathan-at-least nathan-at-least added this to the Payment API Code Freeze milestone Mar 29, 2016
@bitcartel
Copy link
Contributor

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

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

@daira
Copy link
Contributor

daira commented Jun 22, 2016

Was this fixed by #1026?

@daira daira modified the milestones: Protocol 2016.1 Implementation, Payment API Implementation & Code Freeze Jun 22, 2016
@bitcartel
Copy link
Contributor

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
Copy link
Contributor

daira commented Sep 19, 2016

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

@jackgavigan
Copy link
Contributor

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
Copy link
Contributor Author

nathan-at-least commented Sep 19, 2016

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
Copy link
Contributor

str4d commented Sep 27, 2016

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
Copy link
Contributor

daira commented Sep 28, 2016

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
Copy link
Contributor

daira commented Oct 3, 2016

@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
Copy link
Contributor

daira commented Oct 3, 2016

@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
Copy link
Contributor

daira commented Oct 3, 2016

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 added a commit to zcash/zips that referenced this issue Oct 3, 2016
daira added a commit to daira/zcash that referenced this issue Oct 3, 2016
str4d pushed a commit that referenced this issue Oct 4, 2016
str4d pushed a commit that referenced this issue Oct 4, 2016
@str4d str4d added the M-has-pr To-be-removed (GitHub has linked:pr filter) label Oct 4, 2016
daira added a commit to zcash/zips that referenced this issue Oct 4, 2016
@daira
Copy link
Contributor

daira commented Oct 4, 2016

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

zkbot pushed a commit that referenced this issue Oct 4, 2016
str4d added a commit to str4d/zcash that referenced this issue Oct 21, 2020
c6b6b8f1b Merge zcash#830: Rip out non-endomorphism code + dependencies
c582abade Consistency improvements to the comments
63c6b7161 Reorder comments/function around scalar_split_lambda
2edc514c9 WNAF of lambda_split output has max size 129
4232e5b7d Rip out non-endomorphism code
ebad8414b Check correctness of lambda split without -DVERIFY
fe7fc1fda Make lambda constant accessible
9d2f2b44d Add tests to exercise lambda split near bounds
9aca2f7f0 Add secp256k1_split_lambda_verify
acab934d2 Detailed comments for secp256k1_scalar_split_lambda
76ed922a5 Increase precision of g1 and g2
6173839c9 Switch to our own memcmp function
63150ab4d Merge zcash#827: Rename testrand functions to have test in name
c5257aed0 Merge zcash#821: travis: Explicitly set --with-valgrind
bb1f54280 Merge zcash#818: Add static assertion that uint32_t is unsigned int or wider
a45c1fa63 Rename testrand functions to have test in name
5006895bd Merge zcash#808: Exhaustive test improvements + exhaustive schnorrsig tests
4eecb4d6e travis: VALGRIND->RUN_VALGRIND to avoid confusion with WITH_VALGRIND
66a765c77 travis: Explicitly set --with-valgrind
d7838ba6a Merge zcash#813: Enable configuring Valgrind support
7ceb0b761 Merge zcash#819: Enable -Wundef warning
8b7dcdd95 Add exhaustive test for extrakeys and schnorrsig
08d7d8929 Make pubkey parsing test whether points are in the correct subgroup
87af00b51 Abstract out challenge computation in schnorrsig
63e1b2aa7 Disable output buffering in tests_exhaustive.c
39f67dd07 Support splitting exhaustive tests across cores
e99b26fcd Give exhaustive_tests count and seed cmdline inputs
49e6630bc refactor: move RNG seeding to testrand
b110c106f Change exhaustive test groups so they have a point with X=1
cec7b18a3 Select exhaustive lambda in function of order
78f6cdfaa Make the curve B constant a secp256k1_fe
d7f39ae4b Delete gej_is_valid_var: unused outside tests
8bcd78cd7 Make secp256k1_scalar_b32 detect overflow in scalar_low
c498366e5 Move exhaustive tests for recovery to module
be3179154 Make group order purely compile-time in exhaustive tests
e73ff3092 Enable -Wundef warning
c0041b5cf Add static assertion that uint32_t is unsigned int or wider
4ad408faf Merge zcash#782: Check if variable=yes instead of if var is set in travis.sh
412bf874d configure: Allow specifying --with[out]-valgrind explicitly
34debf7a6 Modify .travis.yml to explictly pass no in env vars instead of setting to nothing
a0e99fc12 Merge zcash#814: tests: Initialize random group elements fully
5738e8622 tests: Initialize random group elements fully
c9939ba55 Merge zcash#812: travis: run bench_schnorrsig
a51f2af62 travis: run bench_schnorrsig
ef37761fe Change travis.sh to check if variables are equal to yes instead of not-empty. Before this, setting `VALGRIND=wat` was considered as true, and to make it evaluate as false you had to unset the variable `VALGRIND=` but not it checks if `VALGRIND=yes` and if it's not `yes` then it's evaluated to false

git-subtree-dir: src/secp256k1
git-subtree-split: c6b6b8f1bb044d7d1aa065ebb674adde98a36a8e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documentation Area: Documentation A-rpc-interface Area: RPC interface M-has-pr To-be-removed (GitHub has linked:pr filter) protocol spec usability
Projects
None yet
Development

No branches or pull requests

6 participants