Wouldn't getnewaddress require write access to the wallet to save the newly-generated private key?

Unfortunately even running bitcoind on a firewalled non-public back-end server is not sufficient if the public web server has the API credentials - any compromise of the web server would lead to full control of bitcoind.

A fully secure workaround is to pre-generate addresses on a secure system so that the private keys are only stored offline, then load them into a pool manually, in batches of, say, 1000 depending on how many orders you expect - similar to how you might run a one time pad encryption system.

Alternatively, you should at least operate a "No bitcoins stored on this server overnight" policy, whereby you transfer incoming payments to a "secure" address (i.e. private key stored offline) as soon as the payment is confirmed, limiting the scope of a break-in to very recent payments.

The bitcoind server exposes all its features over the JSON-RPC API. This is somewhat dangerous in a production environment, as any system (e.g. a world-facing web server) which has API credentials has the ability to execute commands such as sendtoaddress. What I would like is the ability to start the bitcoind server in "safe" mode so that it only responds to whitelisted commands - such as getnewaddress and getreceivedbyaddress; with these two, you can offer a customer an address, and check it for payment confirmation later.

I understand that I could implement a wrapper around the API, but this feels like standard practice and something that the client should provide by default.

Hi all.

I am investigating accepting bitcoins as payment on my website (which is nothing fancy), and it seems to me that the process looks something like this:

1. Run bitcoind.
2. Customer indicates that they wish to buy something.
3. Use getnewaddress API call to create a new address to which bitcoins can be sent.
4. Give this address to the customer, and tell them how much to pay.
5. Wait for a period of time, then use the getreceivedbyaddress API call to check whether the funds have been received to an appropriate level of confidence (say, 6 confirmations).
6. If the appropriate funds have been received, start your fulfilment process. If not, go back to step 5.

It's step 5 that bothers me; it requires a polling process to repeatedly perform the check, presumably with a timeout after which the order is cancelled. This seems inelegant and potentially resource intensive. Is there a better way?

Thanks,
James