Developing a secure Bitcoin service

Hey, I'm helping a coding bounty website get set up with Bitcoin, with an eye toward Bitcoin Bounties possibly getting absorbed into it. I'm trying to come up with some secure ways to handle receiving payment and paying out rewards and would like some feedback on what I've come up with so far. I figure this thread could also help anyone in the future who might need to handle coins in a similar manner.

Anybody have any thoughts on the methods proposed below? Any security holes come to mind?

Thanks!

Bitcoin cold wallet + hot wallet, no coins on server
Basically we run a copy of a Bitcoin client on an isolated machine and periodically generate batches of public addresses which we can transfer via thumb drive to a MongoDB collection on the web server. The web server then just pulls public addresses from the collection as it has need. We'd have to make sure there's always a buffer zone of unused addresses so the server never runs out of addresses. Then, once it's time to release the funds, we export the bounties to be paid to a thumb drive, import them into a local MongoDB database, run a script to create the relevant transactions, then (after auditing the DB and the transactions to make sure everything lines up) copy the transactions to a web-connected machine for execution.

If we wanted to further strengthen our security model, we could also keep the transaction-signing machine separate from the address-generating machine by having one private key per Bitcoin address and then exporting the relevant keys to the transaction-signing machine via thumb drive when it comes time to pay out.

Either way, this minimizes the risk of theft since the machine containing the primary wallet file is never connected directly to the Internet. If we keep the thumb drive and the machines involved locked down and clean, it should be nearly impossible. The weakest point is the fact that *someone* has to be responsible for physically transferring the funds, and that person could be a point of failure. (I.e., they could very well siphon funds into their own wallet, or do something stupid to compromise the machines.) If we gave responsibility for each step of the process to a different person, with each person auditing the steps taken by the person before, that would further limit the possibility for theft.

On the web server there would also have to be a copy of bitcoind running to allow us to query the blockchain and update donation amounts periodically. We would have cron run a script every five to ten minutes that would iterate over every active, in-use bitcoin address and ask bitcoind what the balance is. It would then update the reward amount in the corresponding bounty.

Benefits:
This is the most secure and the simplest of the setups I've so far come up with. No coins, aside from those about to immediately be sent out, are ever on a machine connected to a network, and all the technology involved is mature and production-ready.

Drawbacks:
Aside from being the most labor-intensive of the possibilities, the batch processing involved means the waiting period for the release of funds would be somewhat variable. Rather than having an automatic release of the funds after exactly 72 hours, we would see some variability based on how often the payout process is done. (This is why I say "at least 24 hours" on the "About" page of Bitcoin Bounties.)

The above process, plus timed-release transactions
If, during the transaction-signing process, we created multi-signature transactions requiring an additional signature from a private key owned by us, we could feasibly automatically complete the transactions at exactly the right time by having a script that signs the transactions with the final key when the 72 hour waiting period expires. This would also allow us to run the process with longer intervals in between. The risk would be that if the transaction-execution machine got compromised, all transactions "in holding" could get released early, which could cause problems for any claims in dispute. However, since the transactions are already locked to a certain address, they could not be rerouted to the attacker's address, so there would be very little incentive for an attacker to do this unless they happened to be the potential recipient of a disputed bounty.

Doing this would complicate the process a little further, though, and take more time to implement.

Either of the above processes, but with bitcoinjs-server instead of a cron job to keep the bounties updated
This is, honestly, what I would prefer if bitcoinjs-server were mature and production-ready. It would reduce our server resource requirements as bitcoinjs-server is supposed to be much lighter-weight, and it would allow for events to be automatically and immediately triggered by changes in bitcoin address balances. But it does not currently work on Node.js versions greater than 0.08, and it does not seem to be very actively maintained. We could adopt the project, but I don't think that would be wise at the present moment. This is a road I'd like to further explore post-launch, though, as I suspect we may run into scaling problems with bitcoind.

On the periphery, there also the possibility of using a third party service like Blockchain.info. We would have to negotiate things with them, though, since I get the feeling from their API page that they don't expect to have to suddenly deal with the amount of volume we might end up sending their way.

Summary
My own feelings are that we should start with the simplest version of option #1 (a wallet and transaction signing machine + a transaction execution machine + the web server), then transition to using time-released multi-signature transactions as soon as possible, then separate out the wallet and transaction signing machines, and then consider getting bitcoinjs-server to a state where it's useful to us.

And if all of this seems too byzantine for now, we could just start with the model I'm currently using for Bitcoin Bounties, where all the funds on the web server get sent to an offline machine from time to time, and where the offline wallet gets periodically connected to the Internet in order to send payouts. It's the simplest, and it's reasonably secure, but it's far less secure than I'd like any service of decent size to have.