Yes, and it's also one of the most important issues for me. The question is, is it solvable?
One partial solution I have thought about, is to actally withdraw some of the online funds to an offline bitcoin adress, and then manually deposit/withdraw funds to the online host as neccessary. This would limit my risk since any potential thieving host would only be able to run away with a fraction of the entire project balance. But this still puts me at a risk I'm not entirely comfortable with, so I would really like if this is possible to secure some other way. Is it at all possible to solve this with encryption somehow?
Of course, the optimal would be to actually find a host I can trust 100%, but this is quite hard to do since even the most trustworthy may surprice you when money is involved.
One solution that I have already implemented is this:
Architecture: A server in a hosting environment that the users interact with. Also, a PC at your location that is permanently connected to the internet.
The PC contains your wallet. The PC communicates to the server using a "private URLs" and json to communicate the status of payments. The PC software can monitor the Bitcoin network looking for confirmed transactions. The PC software can generate wallet ID's for the server, so that when someone "pays" the server using one of the ids, the money is actually coming to your PC in your basement. Your PC detects the confirmed transaction, hits the server at a private URL saying that a payment came in, and the server handles the rest.
Essentially, you are building a 2-tier architecture, with the "front end" having zero money on it. The "backend" is in your basement, on a PC.
The way I set this up, the backend is just a simple Python program, running JsonRPC, and hitting the Bitcoin Server program which is installed on the PC. I wrote the program to "preload" a bunch of wallet ID's (like 10,000, to handle a lot of transactions and abandoned transactions on the server). Then send each of those wallet ID's to your server. When your server needs to send a Wallet ID to a user (so that the user can pay the server), it just draws from its pool, and the money follows this path: From the user, to the bitcoin network, to the backend PC. Then, the backend PC is in a loop, looking for transactions, and, when it discovers a confirmed transaction (using whatever confirmation you think is required. 1? 6? zero? it's your choice), then it sends a message to the server reporting that the funds have been received.
If you are sending money out, you can do the same thing. Have the backend PC check periodically with the server, asking "are there any outbound transactions?" If so, the backend gets the transactions, and verifies the sanity of it. (You can set whatever parameters you want. Want to make sure no one send more than 10 BTC without your manual involvement? fine.) The backend PC stays in contact with the server, informing the server of the progress the whole way.
The biggest risk in this setup would be that some guy at the hosting facility would change the wallet IDs to direct the incoming money to himself, rather than you. Or perhaps trigger a transaction to try to force money to be sent to him, from your PC. But that cuts out A LOT of risk.
I have built this already and have it "in production". (The software is not production grade, but it'd be simple to make it pretty bullet proof). Let me know if you are interested.
