Topic: Hosting provider + wallet.dat... How to get around trust issue? (Read 1273 times)

I don't know exactly how the state of current software implementations is. I am talking about what the bitcoin protocoll makes possible.

I think most of the current bitcoin businesses are total trash. Gambling sites are a special case, they can transfer their profit to an offline wallet and don't have to care about the security of the jackpot. If somebody steals it, why should the gambling operator care?

FWIW, I tried storing the private keys for a user in encrypted form, so they are only accessible when he enters the password. Of course this still doesn't help against a malicious admin, but someone who broke into the server would only have access to the currently logged in users bitcoins.
Unfortunately, the account handling turned out to work differently than I expected, so the next step would be to use the wallet encryption and get the client to handle multiple wallets.

But as I don't see a reasonable way (for me) of dealing with the legal implications of running such a site, I've mostly given up on it...

http://forum.bitcoin.org/index.php?topic=19451 [patch to remove private keys]
https://forum.bitcoin.org/index.php?topic=12403.0 [online wallet]

Edit: I'd be glad to team up with somebody who thinks he can take that responsibility..
My fear is what if my (german) government decides bitcoin is terrorism/childporn/drugdealers/whatever tomorrow, would I have a clean way of 'getting out'?

Duuuuh, okay then... how do you do it?

How does one run a gambling game for example where there's hundreds of incoming/outgoing payments on a daily basis?

...or to put it another way, where is the server for mt gox or tradehill physically located? In a professional datacentre somewhere or in someone's basement?

Doesn't matter to monitor incoming payments.

You don't put a wallet on a hosting machine - ever. That's the most stupid thing I have ever heard, there is absolutely no need for that and there is no way to do that in a trustworthy way.

Another way to achieve the same: Generate a lot of priv/pub keys and the bitcoin addresses for them. Store only the addresses on your server, keep the keys for yourself. When a user wants to make a payment, give them one of the addresses. Later, use the blockexplorer API to check if the payment arrived at the address. You rely on blockexplorer now, but it might be easier than hacking bitcoind to work with pubkeys only.

Oh yeah of course, I was thinking 'refunds' but accidentally typed 'change'.

The sending client sends itself the change, the receiver deliberately doesn't touch the change (say you had 10,000BTC on an address and you wanted to buy a $1 shirt - could you really trust the node the other end to hand back the rest of the BTC?)

And no, you're right - it's 100% by design that such a setup would be unable to send coins. It's an idea for merchants, it wouldn't really work for exchanges and such who have a higher send ratio.

Some great ideas there elggawf, too complicated for me at the moment, but a good start to get the ideas flowing.

That would of course only work for automated receiving... your version wouldn't be able to send anything.

So it would be handy for sites that sell stuff like t-shirts that don't need to pay out any change or affiliate payments.

Those affiliate payments could go out manually from home pc anyway; they wouldn't need to be instant.

I haven't actually gotten around to hacking on bitcoind to see if it's possible yet, but I can't think of why it wouldn't be (all the data is right there for it to see), but my idea is basically this:

Create a wallet on a secure computer in the typical fashion, but use -keypool with a nice large figure to preallocate a large number of addresses. Feed the wallet through a script which obliterates the private keys and saves it as a separate file (basically only containing the public keys the wallet needs to watch) which you then upload to your server.

On the server, you load the public-key-only wallet into a modified bitcoind, which is setup to disregard the fact that it doesn't possess the private keys (I would imagine it doesn't already act that way, but again, I've honestly not even looked). The daemon is also modified so that if it runs out of addresses, any attempt at creating a new one simply fails loudly - and possibly even a way to tell how many un-used addresses exist, which you could then monitor with nagios or something similar, topping up the pool as necessary.

Your merchant application then acts as it would any other way - when a client wants to make a payment, it uses RPC to ask for a new address. The daemon can watch the addresses it's handed out, and the application can check when a payment is confirmed as usual.

If someone roots your server, the only thing they could possibly do is modify the wallet so that new payments are sent to their wallet instead, but I don't think there's any way to get around that and keep the process automated. If you're sufficiently large, you probably want a separate billing/application server specifically for this, so that if someone roots your web server they don't automatically win the Bitcoin server as well.

As I said, I've not put a whole lot of thought into it yet (my Bitcoin stuff has been so lackluster that it's just easier to manually deal with them and keep the wallet entirely offline), but I think this is a way that Bitcoin merchants can operate in not-so-high-security scenarios without completely exposing themselves to unnecessary risk.

Anyone with physical access to a drive can get any data they want from it. The only way would be to encrypt it, but this wouldn't work for active transactions. I think you need your own server.

Home PCs do not have guaranteed up-time, and they would be bad for reliable business transactions, in any case.

For those merchants that are keeping a wallet.dat on a hosted server, how do you get around (or not care about) the trust issue of hosting company employees getting your wallet.dat?

Is there any way to set it up so that the host can't actually get to it?

(eg. by keeping the wallet.dat on your home PC and somehow connecting your websites to it via JSON? ...in that case, the host could still see your JSON password and do a 'sendfrom')

My only step so far has been to get my bitcoin directory on their 'exclude' list for their automated backups... so at least the wallet.dat shouldn't be getting copied elsewhere. (I back it up manually to my home pc).