Why? It's all the same thing, a group of private keys. If it needs to be more secure, require a password, biometric access, whatever. There's no good reason I can think of to distinguish between one keystore and another.

Why? It's all the same thing, a group of private keys. If it needs to be more secure, require a password, biometric access, whatever. There's no good reason I can think of to distinguish between one keystore and another.

Entering a password every time you want to send coins (or pulling out your... dongle... err, that didn't come out right, uhh, fetching your one-time-password-generating-device) might be annoying enough that withdrawing 50 or 100 bitcoins that you can spend with minimal hassle would be a nice feature.

How often do you get the chance to work on a potentially world-changing project?

It's just terminology but people probably already have two or more "wallets" that they use differently. It just clarifies that the safe is the place where you can put large amounts safely and the wallet is where you can put small amounts that are easier to access and don't have as many overheads, back-ups, off-site copies, etc.

If you had one wallet with BTC 50,000 in it you are going to treat that a lot more carefully than the wallet with BTC 50 in it, no? Just easier to call one the safe and the other the wallet ... take it or leave it, just trying to put some words with concepts that already in practice.

Entering a password every time you want to send coins (or pulling out your... dongle... err, that didn't come out right, uhh, fetching your one-time-password-generating-device) might be annoying enough that withdrawing 50 or 100 bitcoins that you can spend with minimal hassle would be a nice feature.

Hmm... that just gave me an idea for dealing with some of the problems of encrypting private keys. Divide private keys into two pools, encrypted and cleartext. Allow users to move keys from one pool to the other by entering an amount, and attempting to approximate that amount with the coins owned by one or more private keys.

Think it could work?

edit... Fleshed out idea, cross posted from github/issues:

Suppose we encrypt keys with the public key of a separate private key. That private key is encrypted with a symmetric algorithm, whose key is derived from the passphrase. I believe this is how GnuPG works. When we store this encrypted key in the wallet, we also store a reference to the associated private key. (Or, perhaps have it elsewhere on the file system... usb drive? smart card? keyring?) With this functionality, we could prompt the user for a password once and decrypt multiple keys. It also means that a wallet could be separated into virtual partitions with different encryption keys. I think it would allow a smooth transition, but would it be backwards compatible?[1]

Here's the way I imagine interacting with this. I would keep a small amount of bitcoin in the clear. This allows me to easily spend the small amount while assuring I won't lose much if my device is compromised (good for mobile devices). I can easily encrypt/decrypt keys by entering a target amount to "transfer". The actual amount is determined by picking keys with transactions (outputs?) summing to approximately the target[2]. In order to spend more than is in the clear, I must enter one (or more) passphrases, but the rest is automated.

[1]Can the structure of the wallet be modified for encrypted keys and a reference to the encrypting private key without causing a breaking change?

[2]You can't split the output of a transaction without writing to the block chain, right?