I have a couple of comments on the EIP, would you rather a PR against the draft or a write-up here?
This end up very similar to what I proposed, so if my opinion has any value it’s positive
A PR is always welcome!
Submitted the PR.
One big issue that’s worth considering is if you want to overload the
setAddr()) methods, given that Vyper doesn’t support function overloading.
Is it impossible to call an overloaded method in Vyper?
Any suggestions for alternate names to avoid using overloading?
Apparently. I suppose low-level calls with function signatures could be used, although it isn’t very friendly.
Not really. The obvious names are
address but the former is already used and the latter most likely a reserved word everywhere.
We could provide two ABIs - legacy and the new one - and Vyper users can choose one or the other. This only helps with calling a resolver, though, not with writing one.
Hi. I insist on using the same interface as we did in RNS for compatibility reasons. Wallets can easily integrate with both services if we keep using same interfaces.
We’ve already had agreement from a dozen or so wallets to implement this, so I’m afraid it’s too late for us to change it now.
The fact that RNS stores the text representation is also an issue; it wastes gas, and makes supporting both addr and the new standard difficult for a resolver implementation.
FYI multicoin support has been added to
How should wallets act in the following case:
- selected chain is a Ethereum compatible chain (ETC, Aquachain, …) that has their own slip44 number
- the user registers a ENS address
should the wallet register with the slip44 number or as a normal Ethereum address?
The first is more correct - but I think can have some legacy problems.
I would suggest all Ethereum compatible chains should be registered as 60 - but I am not 100% sure yet. How do other wallets here handle this case?
I’d be wary of doing this. It’s entirely possible that a user has different addresses for different chains, even if they are nominally compatible. As such I would treat (for example) an Ethereum address different to an Ethereum Classic address as far as setting and getting multicoin addresses.
There is, though, nothing to stop the UI from being friendlier in this type of situation. Continuing with the Ethereum/Ethereum Classic example, if a user wanted their Ethereum Classic address the wallet could look it up and, if nothing is present, look up the Ethereum address. It could then present the Ethereum address with some sort of warning (“use this address for all Ethereum-compatible chains?”) and act accordingly.
Update on multi-coin support:
We have encountered one encoding-related issue that I’d appreciate community feedback on. The EIP expects that addresses are stored in decoded (binary) form; for the most part this is straightforward. However, with the advent of native SegWit addresses on Bitcoin, there are now two different text encodings for Bitcoin addresses, without a common binary format.
‘Traditional’ addresses are base58check encoded, and consist of a single version byte (0 for P2PKH and 1 for P2SH) followed by some version-specific data.
SegWit addresses are bech32 encoded, and consist of a witness version (not the same as the traditional version byte) followed by witness-specific data). There is no ‘traditional’ version byte that represents a SegWit address.
As a result, you can’t unambiguously tell from the binary data what text encoding is correct. Using the wrong one will not give a valid address.
I can see a couple of solutions, and I’d appreciate community feedback on which one is best:
- Treat the scriptPubkey as the “binary encoding” of any Bitcoin address. This means translating each address type into the equivalent bitcoin script, which at the moment is a bidirectional encoding. This will require anyone who has already implemented the draft standard to change their code, and render any existing addresses invalid.
- Invent a new ‘version byte’ for SegWit addresses, and use that to encode them.
I think each Ethereum-derived chain should use its own chain ID. Deployments of resolvers on chains other than Ethereum that support backwards compatibility (eg, reading and writing the old
setAddr functions updates the values stored by the new functions) should have those modify the value for the appropriate chain ID.
So, if I call
addr(foo) on Ethereum, it should be equivalent to calling
addr(foo, 60), while if I call it on ETC, it should be equivalent to calling
@jgm @nickjohnson thanks for your input. I was mainly concerned about problems that arise if people where using ENS with chains that are Ethereum compatible but have their own SLIP-44 before multi-chain was a thing. But it seems to be non issue - just polling if people have this case and it does not seem to be the case (early though - just 5 votes in so far) - so it seems no need to complicate things.
Is there no way we can derive the type from the length of the bytes?
Unfortunately not - segwit programs can be 20 bytes, just like script hashes or public key hashes.
Sounds like option 2 is the better one, then, as long as we have enough libraries out there to mask the complexities that this (and whatever other exceptions we bump in to) causes.
Okay, I’ve updated the draft EIP to deal more explicitly with encoding, and to describe how Bitcoin and Ethereum address encoding should be done, with test vectors. I’ll update them as we go, adding more chains as necessary.
If you’ve already added support for Bitcoin, please note that how to decode and store this in binary form has now changed, to match Bitcoin’s
I read the EIP, one comment: segwit includes:n
we also added bnb address support: https://github.com/wealdtech/go-coincodec/pull/1