Related #4927: Add ss58 address format network identifier prefix for DataHighway parachain

[ltfschoen]

UPDATE: 26 May 2020 Changed to request ss58 prefixes of 49, which has not already been reserved

• What does it do?

  • We would like to claim these ss58 prefixes:
    • 49: DataHighway Mainnet
  • We will be using Substrate's ss58 prefix of 42 for DataHighway Testnet
  • DataHighway will be a parachain supported by the Polkadot network. The chain's repo requires an ss58 address format network identifier prefix, see associated issue.

• What important points reviewers should know?

  • If this PR is approved, the "External Address Format (SS58)" section of the Substrate wiki should be updated to reflect the changes in this PR (i.e. add the DataHighway's ss58 address format network identifier prefix)

• My notes:

  • If this PR is approved, I will need to update
    • Polkadot.js util-crypto's ss58: https://github.com/polkadot-js/common/blob/master/packages/util-crypto/src/address/ss58.ts
    • Polkadot.js's app-config sections: https://github.com/polkadot-js/apps/blob/master/packages/apps-config/README.md

[jacogr]

Thanks for the heads up, but don't manage specific user-chains myself, it is up to the chain devs. f they want support, see https://github.com/polkadot-js/apps/tree/master/packages/apps-config

ss58 is actually never an issue since it comes from on-chain via the spec properties, like decimals and token.

[gavofyork]

The "Reserved" of Reserved46 pertains to the fact that Parity is reserving it for future use. You might want to try claiming one of the indices which are not reserved.

[ltfschoen]

Thanks for the feedback, I've pushed a commit to request indice 49, which has not been reserved

[bkchr]

Thanks for the feedback, I've pushed a commit to request indice 49, which has not been reserved

Please take a closer look:

substrate/primitives/core/src/crypto.rs

Line 479 in a4ba9be

// Note: 48 and above are reserved.

[ltfschoen]

substrate/primitives/core/src/crypto.rs

@bkchr I've had a closer look.

We asked for indice 49 since it didn't appear to be reserved based on the following initial observations:

1. There isn't a Reserved49 already in that file
   2 I've checked that there aren't any PRs already asking for 49
   3 It's not one of the reserved indices (i.e. 1, 3, 43, 46, 47, which have the word 'reserved' in their number and name)
2. I've checked that I've used a unique identifier, number, name, and description.
3. I've avoided choosing 48 since this comment // Note: 48 and above are reserved. says that 48 is a reserved indice, but I'm not sure why there isn't a line Reserved48 => (48, "reserved48", "Reserved for future use (48).")
4. It doesn't mention anywhere that we can't try to claim one of the indices that are greater that 48
5. The comment // Note: 48 and above are reserved. mentions that 48 is reserved, even though there isn't a line Reserved48 => (48, "reserved48", "Reserved for future use (48)."), so I've assumed that since it says ... and above are reserved that all other indices that are less than the number 48 are reserved, even if they too aren't shown as being reserved (i.e. there isn't a
   Reserved13 => (13, "reserved13", "Reserved for future use (13).") but I assume it's reserved as it satisfies the comment), so even though these indices don't appear to have been taken (i.e. 4, 13 to 15, 17, 19 to 31, 33 to 35, 37 to 41, 45, and 48), I've assumed that they are reserved and haven't chosen any of them.
6. I've reviewed other PRs that have requested an available indice successfully (i.e. https://github.com/paritytech/substrate/pull/5155/files, https://github.com/paritytech/substrate/pull/5061/files, and https://github.com/paritytech/substrate/pull/5506/files), and I've noticed that whilst they chose an indice that was less that or equal to 48 and didn't choose to replace one of the visibly reserved indices (i.e. Reserved47), I don't know if they claimed indices that they already knew were reserved for them, and which were one of the reserved indices mentioned in the comment // Note: 48 and above are reserved..
7. Note that I've observed that the following "Account Indices" documentation is still in progress https://substrate.dev/docs/en/next/development/deployment/account-prefix

However, now that I've looked into it further, I found that in the Polkadot Wiki here https://wiki.polkadot.network/docs/en/learn-accounts#for-the-curious-how-prefixes-work, it provides a link to https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58), which lists the following, and clearly shows that 49 is already used for (49) Edwards Ed25519 key:

00000000b..=00101111b (0..47 inclusive): Account/address identifiers on networks:
00000000b (0) Polkadot Live (SS58 checksum preimage)
00000001b (1) Polkadot Live (reserved for secondary use)
00000010b (2) Polkadot Canary (SS58 checksum preimage)
00000011b (3) Polkadot Canary (reserved for secondary use)
00000111b (7) Edgeware/Berlin (SS58 checksum preimage)
00010000b (16) Kulupu (SS58 checksum preimage)
00010001b (17) Kulupu (Reserved)
00010100b (20) Dothereum (SS58 checksum preimage)
00101010b (42) Generic Substrate wildcard (SS58 checksum preimage)
00101011b (43) Generic Substrate wildcard (reserved for secondary use)
00101111b (46) Reserved for future address format extensions.
00101111b (47) Reserved for future address format extensions.
00110000b..=00110111b (48..55 inclusive): Bare public keys of primary cryptography
00110000b (48) Schnorr/Ristretto 25519 ("S/R 25519") key
00110001b (49) Edwards Ed25519 key
00110010b (50) ECDSA SECP256k1 key
00111000b..=00111111b (56..63 inclusive): Bare public keys of secondary cryptography (additional byte expected).
01000000b..=01111111b (64-127 inclusive) Reserved for future address format extensions.
10000000b..=11111111b (128-255 inclusive) Secondary address types (additional byte expected).

So it says (0..47 inclusive): Account/address identifiers on networks, which indicates that I can actually only choose an indice between 0 and 47, but when I combine those that are mentioned as being available in the crypto.rs file, and those that are mentioned as being available at that wiki link, only the following are still available: 4, 15, 17, 20 to 31, 33 to 35, 37 to 41, 45.

Question 1: Are indices from 64 to 127 (inclusive) (i.e. Reserved for future address format extensions), and 128 to 255 (inclusive) (i.e. Secondary address types (additional byte expected)) also available to be claimed?

Question 2: So based on all the above, should I modify the code of my PR to be the following instead in order for it to be approved, where <INDICE> may only be chosen from the following: 4, 15, 17, 20 to 31, 33 to 35, 37 to 41, 45?

	DataHighwayAccount =>
		(<INDICE>, "datahighway", "DataHighway mainnet, standard account (*25519).")

Question 3: What are indices 51 to 55 to be used for?

Question 4: Would it be beneficial to add the other indices that mentioned in https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58) as already being reserved into the crypto.rs file? It may make it easier if the list of available indices are all in the same place
i.e. I think there's an opportunity to add something like the following to the crypto.rs

        // (0..47 inclusive): Account/address identifiers on networks
        ...
	Reserved17 =>
		(47, "reserved47", "Reserved for Kulupu (47).")
        ...
	Reserved20 =>
		(20, "reserved20", "Reserved for Dothereum (20).")
        ...
        // (48..55 inclusive): Bare public keys of primary cryptography
	Reserved48 =>
		(48, "reserved48", "Reserved for Schnorr/Ristretto 25519 (S/R 25519) key (48).")
        ...
	Reserved49 =>
		(49, "reserved49", "Reserved for Edwards Ed25519 key (49).")
        ...
	Reserved50 =>
		(50, "reserved50", "Reserved for ECDSA SECP256k1 key (50).")
        ...
        // (51..55 inclusive): ???
        ...
        // (56..63 inclusive): Bare public keys of secondary cryptography (additional byte expected).
        // (64-127 inclusive) Reserved for future address format extensions.
        // (128-255 inclusive) Secondary address types (additional byte expected).

[jacogr]

It is clear without having explicit entries for each of the reserved fields. Note: 48 and above are reserved. Unpacking -

• 48 is unavailable (it appears in the comment explicitly)
• 48 + n is unavailable (it appears in the comment as "and above")

TL;DR Pick any unassigned number < 48 and push the change.

[ltfschoen]

Cheers, sorry I misinterpreted and above to be referring to the lines of code above the comment, rather than indices above 48 😊

[kianenigma]

TL;DR Pick any unassigned number < 48 and push the change.

updates @ltfschoen ?