Increase AVAX support and add AVAXC

[0xcharchar]

Issue number

Missing X- and P- identity stripping as highlighted in #294

Description

Two changes are included:

• increase compatibility with AVAX X & P chains by stripping any address that has the X- or P- identifier prepended
• add support for AVAXC, which is the Avalanche C-Chain, including C- identifier stripping

Reference to the specification

• Avalanche documentation - What is an address?
• SLIP-0044 data table

Reference to the test address.

Both addresses were pulled from transactions on the Avalanche blockchain explorer: https://explorer.avax.network/

List of features added/changed

• changed AVAX to support address format with and without ID prepended, previously did not support the ID
• added AVAXC support, which is uses the EVM format and could have an ID prepended

How much has the filesize increased?

Before: 410838
After: 411043
Difference: 205 bytes

How Has This Been Tested?

Added to the existing unit test vectors for AVAX and new vectors for AVAXC

Checklist:

• My code follows the code style of this project.
• My code implements all the required features.
• I have specified correct coinTypes specified at Slip 44
• I have provided the reference link to the specification I implemented.
• I have provided enough explanation about how I provided the test address

[0xcharchar]

Tried to keep the changes very tight in each commit, if the team wants any of them cut out let me know

[makoto]

Thank you for your contribution. Any reason why package-lock.json is updated without any change on package.json?

[0xcharchar]

Thank you for your contribution. Any reason why package-lock.json is updated without any change on package.json?

Packages automatically updated when I did the package install. Happy to revert that commit.

[makoto]

Packages automatically updated when I did the package install. Happy to revert that commit.

yes, that would be great

[0xcharchar]

So, I've reverted the package updates and was getting an error in the Travis tests. Tried merging in master with no success. Eventually I cloned the branch that #341 was based on and ran the tests locally with the same error result we are seeing here in Travis.

My local result:

  ● MRX

    TypeError: Cannot read property 'decoder' of undefined

      1259 |
      1260 |     for (var example of vector.passingVectors) {
    > 1261 |       const decoded = format.decoder(example.text);
           |                              ^
      1262 |       expect(decoded).toBeInstanceOf(Buffer);
      1263 |       expect(decoded.toString('hex')).toBe(example.hex);
      1264 |       const reencoded = format.encoder(decoded);

      at Object.<anonymous> (src/__tests__/index.test.ts:1261:30)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 136 passed, 137 total
Snapshots:   0 total
Time:        9.258 s
Ran all test suites.
npm ERR! Test failed.  See above for more details.
➜  seqsee-address-encoder (master)✭ nvm current
v10.24.1
➜  seqsee-address-encoder (master)✭ git remote --v
origin  https://github.com/SeqSEE/address-encoder.git (fetch)
origin  https://github.com/SeqSEE/address-encoder.git (push)

And the direct link to Travis result for this PR

It looks like the Travis tests may not have been run for #341?

@SeqSEE @makoto How would you like to proceed on getting this sorted out?

[makoto]

Can you verify only X and P prefixes are allowed?

[0xcharchar]

Based on the documentation (https://support.avax.network/en/articles/4596397-what-is-an-address), X or P are allowed and are technically separate chains using the same addressing format (besides the prefix).

There seems to be a new feature, the chainId can be used instead of an alias:

Same address, using the chainID instead of the chain alias:
11111111111111111111111111111111LpoYY-avax1kj06lhgx84h39snsljcey3tpc046ze68mek3g5

Is this something you would like to see supported too?

[makoto]

Well spotted about chainId. Is it something we can verify the format or it can be anything?

[makoto]

Can you verify only C-prefix is allowed?
Also, please use ChainID for EVM compatible chains instead of SLIP44 cointype? Please see https://docs.ens.domains/ens-improvement-proposals/ensip-11-evmchain-address-resolution for more detail. You should be able to make use of convertEVMChainIdToCoinType(chainId) which I explained at https://medium.com/the-ethereum-name-service/improved-ens-support-for-evm-compatible-chains-19fc86e9722b (but probably have to strip C- off/back in when storing)

[makoto]

I didn't notice that MXR PR didn't run CI test. I will revert at #343

[makoto]

My comment is a bit scattered so here is the summary

• For AVAX, your current base implementation is good. Please add a check to only accept P- and X-. Let's not handle chainId for now as we don't know what format exists.
• For AVAXC, please EVM chainID, not SLIP44 cointype as mentioned in the comment. This allows to have all EVM coins in the same ID range.

Please let me know if you have any questions.

[makoto]

I split this PR into the following two PRs
#359
#358