Bitcoin Forum

Hello all,

I'm a programmer proficient in LAMP setups. Having built websites for large and small customers. I have always been facinated by Bitcoin and everytime I think up a new business venture for Bitcoin, one thing stops me. My lack of understanding for handling bitcoin and the server infastructure required. Obviously I dont want to be making any mistakes and the trouble is most my ideas result in me holding money is some sort of hot wallet. So what can you the bitcoin community suggest to me? I've learnt from the mistakes of others and I don't want to repeat history, so is there any direction I can go?

Regards

http://bitpay.com until you are comfortable.


And thank you for not being afraid to ask instead of experimenting with possible disaster.

I have struggled with this as well. I think the main solution many sites have come up with is to hold large amounts in cold storage (printing out to paper and keeping it somewhere safe) and only keep online funds necessary for automated transactions throughout the day.

Also, there is the option of making it so that every spend done by the service requires a second authentication. I think I may go this route for almost all spends done on my site. Either require a text or e-mail or something. If it is thousands of tiny transactions then it may be best to just allow for the private keys to sit on the server. If there are thousands of large transactions then you are in a bigger business than any out there right now and you could hire people to help with that.

But I am also curious as to other approaches.

If you look at the $12,000 BitInstant hack, that is not actually too bad since they likely move a lot more money than that. So you may just need to price small thefts like that into your plan in exchange for quick automation.

I guess it depends on the idea you want to implement, but most of the time, you can do away with hot wallets altogether.

A good way to get started is; to print out a huge list of paper wallets (on an offline computer) and process any withdraw request from user manually. you can process deposits automatically with a third party tool ("bitcoin Notify" ? not sure of the name)that send a HTTP POST to your specified script  when ever one of your wallets gets a deposit.

this way you can be sure as long as the paper wallets are safe, your safe, even if your site gets hacked to shit.

you can automate everything expect for withdraws request. this way you can make sure your system hasn't been comprised (should be as easy as checking that your books are balanced) and then process the withdraw in a batch once a week or something...

bitfenix works this way, and i like that they do because everyone can be sure their funds their are safe!

hackers will not care to hack you even if your system can easily be compromised,  because they know even if they do, they wont get any coins out of it.

What are the benefits of what you propose vs simply using the Armory client?
Which allows offline payment signing, so as to never expose your private keys to the internet.

http://bitcoinarmory.com/armory-quick-start-guide/

For this case (no automatic withdrawal by users necessary), you could use a similar but probably a little more elegant technique called type 2 deterministic wallet (https://en.bitcoin.it/wiki/Deterministic_wallet): a public seed can be on the server and is used to generate a sequence of addresses. A corresponding private seed (on a non-exposed machine) can be used to generate the sequence of matching private keys. In fact, I think you can just use electrum or armory (dunno if multibit has caught up yet) to "spend" the money.

http://acceptbit.com/ uses this approach, for example.

Develop a relationship with someone who does understand the Bitcoin infrastructure.  Offer them a piece of the pie for programming that part.  That why they have a vested interest in making things work initially and on a continued basis.

I would suggest this as well.  Tons of knowledge on this forum and someone who knows even more can probably even suggest someone for you.