Posting here related discussions about unique dApps keypair paths scheme happening around EIP1775 and EIP1581
See discussion here EIP ERC App Keys: application specific wallet accounts - EIPs - Fellowship of Ethereum Magicians
and discussion here https://github.com/ethereum/EIPs/pull/1775
and the EIP itself https://github.com/ethereum/EIPs/blob/6671145ef6561a79e4e484fb26629ad2dd8b18a9/EIPS/eip-1775.md
I want to just give a breakdown to clarify things. Seems like some confusion around EIP 1775, and also I suggest that we have a ERC1581+ERC1775 .
Fix the weakness of using the same public key for ethereum address and chat key.
m/43'/60'/1581'/ [key type]' / [key_index]Fix the privacy weakness of reusing the same ethereum address for several dapps.
m/43'/60'/1775'/ [persona path]' / [application uniquely assigned path]' / [app's custom subpath]Fix the privacy weakness of reusing the same public key for several dapps.
m/43'/60'/1581'/1775'/ [persona path]' / [application uniquely assigned path]' / [app's custom subpath]Must be 1581+1775 (1775 in top of 1581), not 1775+1581 (1581 in top of 1775). Because if 1775+1581, for every new dapp asking key then keycard/password will need to be given, even if is a nonwallet key. In case of 1581+1775 , Status already know the 1581 key, so it can derive the dapp specific key without asking keycard/password.
https://eips.ethereum.org/EIPS/eip-1775
cc @andre
This is a great update on the current state @ricardo3!
About 1775, how would funding a dapp specific Ethereum address work? Do you see any ways to allow transactions using this address to draw funds from another account?
Ideally I imagine these addresses to be generated on the fly when using a dapp. Basically offering the user to choose from a list to use
Where ‘a new account’ is most likely to be dapp specific as it’s the only way to know it hasn’t been used anywhere else. The issue then being that this new account doesn’t hold funds.
The alternative of first creating and funding an account before sharing that address would rely on the user be hygienic in creating dedicated accounts for dapps they might use, which I don’t see likely to happen.
this does not answer @hester question which is a hell of a good question, but I encourage those who have not to check metamask mobile (released a month ago) UX
https://medium.com/metamask/metamask-mobile-public-beta-a-feature-guide-and-walkthrough-9d01de7190ae
The UX to manage mutliaccount and in particular to let know the user, while in the browser, which account he’s using, and if he’s got assets on this account is really clear and simple.
@guylouis
What about use “Themes” for different accounts or “personas”? We can make that each new account gets a random theme, and the browser gets this theme whenever user is exposing that account.
Not sure of this one.
The solution I see would be:
Therefore this creates an way of user setting up a new session for each dapp, and archiving or deleting old ones, just like users would do with apps installed from a store.
I’ll be happy in discussing further how we can make a better DApp experience for users and developers.
It’s like everything always used “privacy mode”, and we can totally do that because we dont need anymore cookies to login, because for dapps login is digital signature coming from user identity. However cookies and local storage of browser might still be used for dapps, e.g. to save information about secrets on ENS bid-reveal, e.g. cryptokitties uses cookies to dont request signature everytime again, so server knows user is owner of one address