Accepting Bitcoin payments on my website using bitcoind? Many questions... no apparent answers

Question

I am trying to design a system that lets me accept Bitcoins on my website. I would like to use bitcoind, or bitcoinj. However, I have many questions regarding this setup.

FYI, I already read similar questions on this website and haven't gotten my answer.

Bitcoinj:

• Seems tricky. I wasn't able to find any example code that works for me. Don't take it as a sign of incompetence or laziness on my end. The examples on their site didn't work properly because they renamed many of their classes and I can't get it to work. If you have a piece of code working with the latest version, please point me to that direction.

Bitcoind:

• How many addresses can bitcoind reasonably manage? Is it a good idea to create tons of addresses and have bitcoind watch all of them?
• How often should I 'flush' the wallet? It doesn't make sense to me to keep the same wallet all the time since that file will grow huge in time.

• I am planning on doing the following:

  1) User generates the address on my website, sends BTC.

  2) I start polling 'listunspent' every X minutes. When I see that the TX got N confirmations, I send the money to the cold storage. I also put money down on the sender's account on my website.

  3) Now how do I get rid of this address? It sounds like these addresses will accumulate and break bitcoind after some point.

I have read a lot about this but nobody explains this aspect. They just revolve around the problem.

Answer 1

Actually Ive done this.

What I would say is that if you are planning to it your self it requires some amount of time and expertise if you really want to implement a custom solution that can integrate with your web platform. I did some research and in the end this is how I did it.

I use Bitcoind

It runs on a private server well away from the web server. On the private server there are several encrypted wallets running on different ports under different user accounts each of them runs the RPC deamon that only responds to ssl from the local host.

Users have an account on on the web application, when they are created they are assigned to one of the private wallets and given an account in that wallet.

The web application sends an RPC request for getaddress using a message queue that a process on the private server listens to. This issues a new address for payment and puts it in the web applications database.

When we want to accept payment we display the new address to the user on the web page

On the private server a deamon runs every minute or so that calls getreceivedbyaddress -minconf with the addresses we have displayed to users to receive payment.

when it sees a new payment it updates the webservers database with the record of the payment.

To make it more complicated but secure the communication is also encrypted and the details of the transaction signed using a shared secret between the web server and the wallet daemon process. So for example the web application wont regard the payment as accepted until it sees a signed transaction in its database and the deamon wont put one there until it has seen the minimum number of transactions confirmations on the network.

It took me a couple of days to implement but I had quite a big head start. The easiest way is to go with one of the payment vendors who have done the hard work for you unless you plan on becoming one of them.

There are several other gotyas you have to be aware of.. for example Keeping a secure backup of the remote wallets Keeping the address pool in the remote wallets primed and making sure you have backed up the wallet after priming it. Storing the wallet pass-phrases so you don't lock your self out having a way to change them..

What I do is have a multi signature approach where half the wallet phrase is sotred in the daemon binary so the developer could get hold of it.. The other half entered at run time by the support guy. Neither of them would have the full pass phrase so cant steel the wallet and run away with it easily.

Regarding the problem of creating too many addresses and not being able to remove them. At them moment this is not a problem for us as our solution will scale as we get more users we can create more wallets.

As for cold storage I'm not completely convinced this offers us any more security than we have now with out giving us more problems associated with managing the cold part of the storage. At the moment its a numbers game. where by if we only have $5000 in a wallet its probably not worth it. If we have $3 million in a wallet then we would firstly be ecstatic our business was that successful, Then probably invest in a more secure private data center some brand new servers and some very clever security people

Answer 2

How many addresses can bitcoind reasonably manage?

it is not the amount of addresses that matters but the amount of transactions going in and out of those addresses that can stress out the server.

Is it a good idea to create tons of addresses and have bitcoind watch all of them?

If you have it nicely organized in a database or some other file then go for it.

How often should I 'flush' the wallet? It doesn't make sense to me to keep the same wallet all the time since that file will grow huge in time.

someone stated I have a wallet with many transactions. It's around 200M. and each wallet flushing takes 4 seconds and blocks JSON RPC calls. from github. So unless you pass 200M transactions do not worry about flushing.

in regards for your second part why not use an open source bitcoin front end such as coiniv. That way you do not have to worry about the customer generating new bitcoin addresses you just inegrate it with coiniv which already has an api

Answer 3

I was able to get this working with some outside help (I paid him with Bitcoin).

http://www.bitcoinmonitor.net/

It monitors the block chain for payments to an address you provide (I use a cold storage address so it is never exposed to hackers). When a payment comes in it sends the details and then I can process the data received.

Answer 4

bitcoind is a very huge app

You should test this by yourself before. I'm currently trying to test dictionary attack. 100k addresses made my wallet.dat to 50mb. After first 50k speed of adding new address radically decreased.

There is no option to remove address from wallet.dat for secure reason, to preventing loss.

You might look at pywallet, This little python script can dump you wallet.dat in plain-text. Probably, wrapping back from plain to binary not a hard task, for even a young programmer.

Looks like side api, what @mulllhausen has mentioned, is the best, light solution.

Look at vanitygen, you can generate vanity addresses by ajax+cgi user's request and check by blockchain.info api confirmation, and send e-mail to your work-box with privkey.

However, I don't know what kind of obfuscation exchanges used, like cryptsy or mtgox. Anyway, looks like keeping alive default bitcoind daemon on the webserver not a good idea.

Answer 5

If you really want to use bitcoind instead of a payment processor and you have a volume that a single instance of bitcoind can't handle (say, 5 figures of addresses) then you're going to have to build a cluster. Use a database to keep track of which addresses are on which bitcoind instance.

A vanitygen app might be useful for creating addresses and waiting for a payment before committing the address to a bitcoind wallet to save yourself from filling up servers with unused wallets.

There are a few tools out there to check balances of Bitcoin addresses without having to import them into bitcoind (and without revealing the private key to the tools).

Answer 6

You should check out http://bitpay.com or http://coinbase.com. They host the payment processor for you.