Expand number of cryptocurrencies the Manager supports

[brantlymillegan]

No description provided.

[brantlymillegan]

There are a number of top cryptocurrencies we don't support in our Manager that we need to support, such as (in order):

• ADA
• BSV
• XTZ
• XMR
• VET
• NEO
• ERD
• ALGO
• QTUM
• HBAR
• ICX
• ZIL

[makoto]

Just checked cointypes at https://github.com/satoshilabs/slips/blob/master/slip-0044.md

cointypes

ADA = 1815
BSV = 236
XTZ = 1729
XMR = 128
VET = 818
NEO = 888
ERD = 508
ALGO = 283
QTUM = 2301
HBAR (XHB) = 3030
ICX = 74
ZIL = 313
FLOW = 539
NEAR = 397

[makoto]

And some notes on format

• ADA = bech32 is the recommended option
• BSV = can'f find developer doc at https://bitcoinsv.io/
• XTZ = couldn't find at https://tezos.gitlab.io/
• XMR = cound't find at https://www.getmonero.org/resources/developer-guides/wallet-rpc.html
• VET = cound't find at https://doc.vechainworld.io/
• NEO = couldn't find at https://docs.neo.org/
• ERD = bech32?
• ALGO = Ed25519?
• QTUM="legacy", "p2sh-segwit" or "bech32"
• HBAR = ed25519?
• ICX = Couldn't find at https://www.icondev.io/docs
• ZIL = bech32?
• FLOW uses 16 hex with some checksum
• NEAR = string = they have their own name service as part of the protocol

[brantlymillegan]

• NEAR = string = they have their own name service as part of the protocol

Yes, but we should still support it

[brantlymillegan]

Additional ones:

• FIL
• AVA
• FLOW
• ZEC

[brantlymillegan]

I just got off a call with Gemini, and they are interested in various kinds of integration with ENS. One thing they pointed out is that we support in our Manager all the cryptocurrencies they do except for ZEC. To show good will to Gemini, @makoto could you prioritize trying to get ZEC address support in the Manager ASAP?

[makoto]

@brantlymillegan can you check with Gemini if they are okay with just storing transparent address, not shielded address?

There is outstanding PR on ZCASH but @Arachnid commented the need to support shielded address.

ensdomains/address-encoder#10

I spoke to Trust wallet team who already support zcash but they also only support transparent address.

[brantlymillegan]

@brantlymillegan can you check with Gemini if they are okay with just storing transparent address, not shielded address?

There is outstanding PR on ZCASH but @Arachnid commented the need to support shielded address.

ensdomains/address-encoder#10

I spoke to Trust wallet team who already support zcash but they also only support transparent address.

But don't we want to support both transparent and shielded addresses? Is it a lot harder to support both? And if we support transparent addresses right now, can we easily add support for shielded addresses later? @Arachnid in that thread you linked talks about the need for it to be backwards compatible. Was that PR changed to be backwards compatible so that we could add shielded addresses later?

[makoto]

I don't know zcash well but not sure if you want to store shielded address (which suppose to be secret) into a publicly accessible place. I also don't know how hard to implement support for the shielded address tbh.

[makoto]

@Arachnid In terms of supporting transparent address, the PR I showed above is a bit out of date (people did some optimisation refactoring), so I tried to implement myself as follows but the testing isn't passing. Am I wrong to understand that 0xb8 and 0xbd are the version number? What should I put instead if it's wrong?

[brantlymillegan]

@makoto I just talked to @Arachnid . He said it'd be great if we could add support for both at the same time. But if we can't do that and we only add support for transparent addresses, that's fine as long as the encoding makes it clear people can distinguish between them. To determine that we probably just need to talk to a Zcash dev (otherwise it could take us a long time to try to figure out on our own).

[makoto]

@Arachnid could you review ensdomains/address-encoder#45 . Also we should pay bounty to the guy who originally submitted ensdomains/address-encoder#10 as it's mostly his code

[makoto]

@Arachnid this one is also good to go for Tezos ensdomains/address-encoder#46 . In terms of your earlier comment about the pr17, I commented here.

NOTE: I noticed that TrustWallet encode/decode differently so I reported to the team.

[makoto]

@Arachnid can you also either merge or close ensdomains/address-encoder#35 ? This could potentially impact other outstanding PRs

[makoto]

Also added DOT as it was super easy extension to KSM ensdomains/address-encoder#47

[Arachnid]

@makoto Thanks! I left some comments on your PRs.

[brantlymillegan]

@makoto I've set up bounties for a bunch of these for the Apollo Gitcoin hackathon we were invited to, and I'm getting a lot of responses. So please check the outstanding PRs tab before doing the work to add a new cryptocurrency address