Thanks for your detailed answer @gravityblast. Now I think understand better what you are aiming at and how our efforts relate.
A] First of all a few comments about your EIP1581 and what you mentionned about your choice of an HD Path:
- HD path BIP44:
HD Path BIP32 compliant
BIP 43 only suggests that the first field should be a purpose field,
m / purpose' / *
Then there is BIP 44 that specifies the whole path as
m / purpose' / coin_type' / account' / change / address_index
and SLIP44
This uses a purpose field of 44
and not 43 as mentioned in your link by arachnid and a PR (not merged by LukeJr).
See my references and also the Ethereum EIPs that specifies that we should use
m/44'/60'/a'/0/n'
and slip44 list : https://github.com/satoshilabs/slips/blob/master/slip-0044.md
So in any case if you are willing to use BIP44, I think you should use purpose field 44’ and not 43’, no matter the coin type.
- HD path BIP43 deviating from BIP44:
When deviating from BIP44, one should use a different purpose field than 44’ but it has not been standardized to use 43’ and cointype’.
In fact several other indexes have been already used and standardized see:
and what I mention in the EIP, where I reference all these:
Importantly, I don’t see why these standards should be related to a coin type and I would refuse to restrict to what luke JR suggested (that wasn’t merged) as :
m / 43' / coin_type' / subpurpose' /
Imho that’s too restrictive to subject these to a coin_type.
B] Now about your use case and how EIP1775 could allow for it:
I understand and agree that it’s an important use case to be able to implement non transacting, cross apps/domains keys (for instance for chat or others).
For that I see two alternatives:
-
develop an EIP alongside 1775, such as yours
but then I’d recommend to use a different purpose field than 43 and 44, and not used already also I think we should remove the coin type since apps such as chat are not necessarly related to a coin. -
[I favor this approach for the sake of simplicity] Use EIP 1775 to encompass all in the following way:
For cross applications non transacting keys (not main accounts), we need a different naming scheme than DNS or ENS and we assume that the wallet or the clients will not have to authenticate these but will include them in their core logic.
This naming scheme would be something like cak:[name]
where cak (cross app key is just a header that allows to fully distinguish these from DNS/ENS) and name is the standardized name of the use case.
e.g.: cak:whisper, cak:ssh, cak:swarm …
we also need to specify the hashing scheme for these in a way that ensures no collision with the current hashing in EIP1775 of ENS/DNS names. It should be fairly easy.
With this 2nd approach, this would mean 3 types of keys:
- main accounts (along BIP44 eth standard, and potentially for other cryptocurencies too)
- EIP1775 app specific keys authenticated through ENS and/or DNS
- EIP1775 cross apps/domains keys not authenticated but included in the wallet/client.