Why shouldn't my application handle private keys for my users?

Question

I'm in the early stages of planning the architecture of our Dapp, and one of my concerns is the barrier to entry of requiring the user to already be using Metamask or Mist. My understanding so far is that these are required to execute contracts on the blockchain because they know the users' private keys, and can hence sign transactions on behalf of the user.

That's all very well, but for users who are new to blockchain, I would like to be able to set up an address/key pair and let them get started immediately. I would happily encourage them to subsequently move to their own wallet. If I'm only storing the new keys on the client, which is open source and externally audited, is this really less trustworthy than using Metamask?

Answer 1

Some thoughts on this:

They would only be able to use that private key & address for your DApp. You would not only be an app to them, but you would become their de facto wallet application. Maybe only for a short time, but still.

As a wallet application, your software is responsible for the security and safe-keeping of your user's money. That's a big responsibility to carry. You really really need to make sure you get the security aspect right. The smallest mistakes can cause loss or theft of funds.

As a wallet application, you need to make sure the user backs up their private key, or a seed used to generate their private key.

Of course, you need to make sure the random generator you use is secure, and cannot be predicted by anyone.

Just creating a private key & address does not get the user started. It helps, but the user still needs to acquire Ether and send it to that address. That will most likely take them longer than installing MetaMask or Mist.

Users may not understand why they can't use the Ether in your wallet application for other DApps. This may actually slow them down and annoy them more than it helps them in the long run.

My conclusion is: I would not generate the private key & address in the DApp. In the Ethereum ecosystem you can make clear distinctions between full nodes, wallet applications and DApp's. As a DApp, you are overstepping your bounds. As a wallet application, your security and code quality requirements are brought to a whole new level: the level of banks! Also, as a wallet application, you would lack many features that other wallets do have.

I hope this helps.

Answer 2

Not a lawyer, but I'm pretty sure that if you're holding user's funds non client side (and I would argue you are if you're holding their private keys), you actually have to be registered in every state or you're running afoul of banking regulation.

As the other answer pointed out. If you're creating a client side app that holds the keys client side why not just let Metamask do that and avoid the work of duplicating Metamask.

Answer 3

You definitely want your application to download some sort of local node (full, light, etc) into the user's local storage. This would eliminate the need for things like Metamask, as you can write code that let's your user interact with their local node, and then consequently with the entire Ethereum network. All of this functionality can be programmed so it is transparent to the user.