2

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?

  • 1
    Note that you can generate private keys and store them client-side in the browser, all transparently to the user. See github.com/ConsenSys/eth-lightwallet for example. Just generate the key for them, and have them write down the mnemonic, so if something happens to the browser cache they can recover their account – Tjaden Hess Oct 6 '17 at 14:23
  • @TjadenHess I think this is pretty much what I had in mind. Is there any particular reason this would be a bad idea? – cjol Oct 6 '17 at 14:32
  • Well, browsers are more likely to have their storage deleted accidentally, so you need to make sure that the user backs up their mnemonic – Tjaden Hess Oct 6 '17 at 17:34
2

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.

  • Thank you for your thoughts! For my use-case, I'm talking about a custom token which is unique to this DApp, so the "locked-in Ether" confusion shouldn't be such a problem. Your point about the increased security requirements are quite valid, however! – cjol Oct 6 '17 at 8:08
  • @cjol To call function on an Ethereum contract in the blockchain, you still need some amount of Ether to pay the transaction fee. If the contract is complex, the transaction fees can become significant. – Jesse Busman Oct 6 '17 at 8:11
1

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.

  • Totally agree that holding funds server side would be a mistake. My suggestion is more like duplicating Metamask, but with a simpler UX afforded by limiting functionality to my application, rather than needing to perform all wallet functions across multiple applications. – cjol Oct 6 '17 at 12:46
  • What is the motivation? So your users don't have to know about ether? Just curious. – Thomas Jay Rush Oct 6 '17 at 14:50
  • That's exactly it. Ethereum brings many benefits to application writer, but the world of crypto is still a little scary to new users. I'd like to give them an application which leverages blockchain behind the scenes, without users needing any crypto knowledge. – cjol Oct 6 '17 at 14:53
  • Probably doable but you duplicate wallet functionality and if things go wrong, you take the blame. Plus where is the node running? The original idea behind the Mist browser was basically a web browser with a wallet. I'm not sure what ever happened to that idea. The "node sync" issue got in the way of that idea. What Ethereum node would you connect to in your case? Certainly not a local node. – Thomas Jay Rush Oct 6 '17 at 15:06
  • @cjol The main point of cryptocurrencies is not the benefit to the programmer, but the benefit to the user. It's the fact that all contract execution is completely transparent, that the user does not need to trust any person or organization but can still trust the system as a whole. Trying to hide the blockchain layer from them is like not giving people 3D glasses when showing a 3D movie. – Jesse Busman Oct 7 '17 at 8:40
0

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.

  • What makes you say I definitely need a local node? Isn't the whole point of Metamask not to need that? – cjol Oct 8 '17 at 7:24
  • You could use Metamask but that wouldn't be a fully decentralized app. – jojeyh Oct 9 '17 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.