I wonder if this would work well when combined with a majority secured wallet.dat
A shared secret allows you to split a secret into n pieces and it can be recovered as long as you have k of the n pieces. k and n can be set to anything desired.
For example, if you split the secret into 5 pieces and set k to 3, then you could only recover the secret with 3 of the 5 files.
Each of the shares is the same size as the original file.
This would allow a user to split their wallet "seed" over 5 locations. As long as at least 3 of them remain secure, then the wallet is secure and recoverable.
The problem is that every time you make a transaction with the default client, it writes to the wallet.dat file. This means you have to collect all 5 pieces together, spend the money and then redistribute the 5 new pieces. This is a massive hassle.
If this process is not performed correctly every time, it could cause the wallet.dat file to be unrecoverable.
With a deterministic wallet, you could make the password a few thousand bytes long if you wanted and protect it using the secret sharing method.
Alternatively, you could make the password a hard to guess/remember password and then distribute the shares to the 5 locations. If you ever forget your password, you can recover it with 3 of the 5 shares.
This wouldn't even necessarily require that the default client is updated. A utility could work entirely by updating the wallet.dat file.
It would require a utility that can generate a wallet.dat file with a few hundred unused keys from the deterministic program. I assume that if there are free keys, the standard client uses them?
The method would be only a little hassle for the user.Utility
read list of public keys in use for this wallet (stored in plain-text*).
run the deterministic wallet generator and generate a wallet containing the keys matching the public keys and also 100 additional keys.**
Start the default client
send your money (change will be sent to one of the 100 generated keys**)
Only perform a few transactions***
Close the clientUtility
Have the utility scan the wallet.dat file and write any used public keys back to the public keys file.*****
This could be scripted
utility -gen-wallet.dat -f pub_key_file_list -n 5 -s1 share1.dat -s3 share3.dat -s4 share4.dat -o /path/to/wallet.dat
utility -extract-keys -f /path/to/wallet.dat -o pub_key_file
The actual wallet.dat could be a link to a random disk, so it would clear when you remove power.
ln -s /path/to/ramdisk/wallet.dat ~/bitcoin/wallet.dat
I think this will cause overwrites to be redirected to the link target right?
*: This can also be determined from the block chain
**: This wallet should be written to a RAM drive
***: This is correct right? The wallet won't generate a key if there are spare ones available in the wallet
****: It is critical that the spare keys are not exhausted
*****: Even if this is messed up, you can still get the keys back due to *
The main thing that could go wrong is if the client generated new keys.