Quote from: gmaxwell on July 14, 2011, 05:01:37 AM

You've missed a whole use case here:

Say I want to run a webserver that accepts paymets.

Actually, my post specifically mentions this use case:

Quote from: Stefan Thomas on July 03, 2011, 04:06:01 PM

To generate a new public key for the wallet, you need to know A, t and the next serial number to use.

Quote from: Stefan Thomas on July 03, 2011, 04:06:01 PM

For example, a merchant server whose only job is generating addresses would encrypt metadata for those transactions using a public key and the wallet would retrieve it using the corresponding private key. That way, if the merchant server is compromised, privacy for previous transactions is still guaranteed.

You don't need a seed to generate addresses securely. Knowledge of A is enough to generate addresses and you don't need to have the master private key at all.

The only problem is that if the hacker has A, he knows all your addresses, so while he can't spend your money, he can see all your blockchain activity. If you extend your seed concept a bit you could use a changing seed, so that an attack would only compromise the current seed.

Going one step further, I've recently been thinking about using a hashing chain. I.e. the hashes no longer depend on A, but instead depend on the previous hash plus the serial number. Then you make the server forget each hash as soon as it's no longer needed. The first hash would be derived beforehand from the master private key in some fashion and is then part of the deployment package to the webserver. That way you can still generate all private and public keys from the master key (full determinism), but a hacker gaining access to the merchant's webserver would only be able to spy on future transactions, not past ones.