Seperate wallet and website, the later brings a lot of exposure.
Secure the wallet server as much as possible. The only connection that may be established should be between those two servers and the P2P network.
Add guards and failsafes, maximal limits to spent over a given time, alerts and rather be safe, than sorry.
Topic: Best practices or guidelines for managing live-service wallets (Read 952 times)
Thank you for your very helpful feedback.
This will no doubt help me a lot. I've learned a lot since I last posted this, and you've only confirmed what I've been learning, so thanks.
As for #4, I'm not positive what I meant when I wrote it, but I think I was talking in terms of like how do you supply entropy for the RNG when generating the address. But I've tried out a NodeJS Bitcoin API and it generates addresses without me feeding it anything, so I think it is taking care of that part for me.
I appreciate your expertise, and thanks for the link to your project; I will check it out!
This will no doubt help me a lot. I've learned a lot since I last posted this, and you've only confirmed what I've been learning, so thanks.
As for #4, I'm not positive what I meant when I wrote it, but I think I was talking in terms of like how do you supply entropy for the RNG when generating the address. But I've tried out a NodeJS Bitcoin API and it generates addresses without me feeding it anything, so I think it is taking care of that part for me.
I appreciate your expertise, and thanks for the link to your project; I will check it out!
BTCump
Another programmer and myself are in the planning process for setting up a cryptocoin-based betting service. We have a very good idea regarding pretty much... well everything except one major crucial detail: wallet management.
Obviously, because we want to allow people to place bets immediately (without waiting for confirmations) and receive money immediately, this means we'll need to have wallets on our servers.
I was hoping someone who has already tread this scary path has some input regarding the best way to approach this. For example, some of my questions are:
1) is there an optimal ratio of how much of the funds you keep in cold storage versus hot storage?
2) is there a specific wallet format we should use - do we just swing it with the standard QT wallet.dat files? If so, is there a common API that is used to decipher these wallets?
3) is it better to immediately move funds over to one "master" wallet, or is it better in terms of security to keep all the funds in each users' respective wallet?
4) what approach do you use for generating wallet passwords?
5) or... perhaps I am looking at this all wrong and you don't even use wallet files, rather just a collection of public addresses and private keys?
My apologies if I am asking a question I should know the answer to already if I'm considering this, but well... I simply do not know.
Thanks for any advice you may have.
Obviously, because we want to allow people to place bets immediately (without waiting for confirmations) and receive money immediately, this means we'll need to have wallets on our servers.
I was hoping someone who has already tread this scary path has some input regarding the best way to approach this. For example, some of my questions are:
1) is there an optimal ratio of how much of the funds you keep in cold storage versus hot storage?
2) is there a specific wallet format we should use - do we just swing it with the standard QT wallet.dat files? If so, is there a common API that is used to decipher these wallets?
3) is it better to immediately move funds over to one "master" wallet, or is it better in terms of security to keep all the funds in each users' respective wallet?
4) what approach do you use for generating wallet passwords?
5) or... perhaps I am looking at this all wrong and you don't even use wallet files, rather just a collection of public addresses and private keys?
My apologies if I am asking a question I should know the answer to already if I'm considering this, but well... I simply do not know.
Thanks for any advice you may have.
Jump to: