Watching and spending from a huge number of offline private keys

Question

We plan to accept bitcoins on our eshop website. What we want plan on doing is:

1) Keep all private keys always offline (cold storage).

2) Generate at least 100,000 keypairs of which only one will be stored on our web server.

3) Frequently change our Bitcoin addresses on our webserver to prevent third parties from knowing how many Bitcoins we have received in total. The web server will only contain our public key (Bitcoin addreses), not any of the private keys.

Now my questions are:

I) Is there a way to monitor the SUM of all bitcoins sent to ALL of our addresses?

Something like a wallet that supports import of a huge number of "watch-only" addresses without requiring the import of the private keys? If the wallet is an application, it must support SOCKS proxy connections. (Armory allows watch-only keys, but I don't know if it supports mass bulk import and SOCKS proxies? Also, it seems to be suffering severe RAM overuse bugs as of now, according to its developer...).

II) Is there a way to sell the SUM of all bitcoins ever sent to ALL of our addresses AT ONCE?

III) Will an attacker be able to find out how many bitcoins we have earned in total?

Thanks!

Answer 1

Direct answers to your questions:

I) Technically this is not too difficult. Looping through every new transaction on each received new block does not take too many resources and checking each transaction against 100,000 public keys is no problem at all. However, I do not know of a tool that would do exactly so. (For example, blockparser can output all the balances of all the addresses in the entire block chain in under a minute.)

II) No. You can not transfer all the received bitcoins in one transaction as the maximum size for a transaction is 1 megabyte. That would be able to spend the money on, say, 4000 different addresses at once, but no more. Of course, you can give all the private keys to somebody else "all at once", which enables them to spend the coins - but such a party would be unlikely to accept the sale as successful before transferring all the coins in to new addresses, just in case you kept the private keys as well.

III) No, if you keep the attacker from learning all the public keys. If, for example, the public key currently on the web server is easily viewable, the attacker can just poll your website, note down all the public keys seen and then check all the transactions for the keys. However, if you reveal the public keys only to legitimate buyers (or something) or do not reuse keys ever, the attacker has no way of knowing the full set of keys that belong to you. This also requires some care on the spending side of the coins - if you do a transaction that links the coins to your site somehow, this can be observed.

However, there are some more advanced methods of using bitcoin public keys that will achieve more than what you have asked here. You can see for example Hierarchical Deterministic Wallets. The choices are numerous and the best way to achieve your goals might not be the most obvious one.

Answer 2

In order for your server to monitor all the addresses, you'll need to have all of them on the server which contravenes your requirement that a hacker not be able to see your combined balance.

With that in mind, as far as I see it you have two options:

1) Use a desktop app. Armory, QT, etc - though I'm not sure how well they would cope with 1M+ addresses or keys, and I'm 75% sure they don't have a bulk import.

2) Use another server - hosted or even in your home network (Raspberry Pi anyone?) that knows all of your public keys but is completely separated from your frontend server. It can then use a Bitcoin API (Blockchain, BTCBalance.net, blockexplorer) and periodically work its way through all 1M keys checking their balance. From within your network (this is ideal as very low chance of external access without being on site) you can call up the server and it'll tell you how many Bitcoins you have in total at your last count. I currently have a Raspberry Pi setup to do similar repetitive operations (though with backups not Bitcoin) and it does a fantastic job.

You would also likely be able to route option 2) through a proxy.