Separating wallet from the bitcoin client

[just_someguy]

Would it make sense to separate the wallet from the bitcoin client? Right now they seem so tightly linked and separating them would enable some pretty cool use cases. I see talk about encrypting the entire wallet.dat but that would seem to give you all or nothing in the case of a shared system or business/personal system.

My little custom format at the moment (after I dump the keys from the client) looks like this:
SQLite (transactional + bindings for most languages)

MasterKey
AccountID (allows multiple users to share a wallet with different keys for each)
AccountName
Version (of the wallet storage format)
Format (Flags for format and usage of private keys) Current options: Public encrypted, Private encrypted
KeyForPublic
KeyForPrivate

Keys
AccountID
PublicKey
PrivateKey

For now everything is just AES but there could be more options.
In the case of the home user you would most likely store the public keys open and the private encrypted.
To decrypt you provide the AES passphrase for the account's KeyForPrivate field which then gives you the key to decrypt the private keys. This would only be necessary when spending or of course key generation.
I could also choose to encrypt the public keys. The wallet could then travel with me in my pocket and when lost would be meaningless even for figuring out which past transactions were yours.
I could also plug the wallet into someone else's machine and just give the key for my public keys to check balances but leave my wife's public keys unknown to the machine.
Have there been any talks about externalizing the storage of the private keys from the bitcoin client? I'm assuming the only time it uses the private keys is for sending and key generation. Is anyone working on something similar at the moment?
It would allow a lot more tools to be written such as custom key generators and backup/restore.

[Luke-Jr]

See https://en.bitcoin.it/wiki/Wallet_protocol

[just_someguy]

Good googley moogley thats complex! Nice work.

That appears to be a communication protocol.... I'm just worried about how the keys are stored which should be addressed well below that level.

If you had your wallet protocol up and running on your machine I should be able to walk up to it, plug in my usb stick with my keys and let err rip while only allowing your app to access what I want. What you've outlined has the application layer determining what keys can be accessed. What if I don't want to give your application access to all my keys? Or I trust your application with my business accounts but not the personal accounts? What if there are competing wallet protocols for different specialized purposes? Your keys should still be able to transfer seamlessly between them.

It seems to me with all the great and various development going on there is a glaring hole in portable secure key management which would be relatively easy to solve with a bare minimum, portable, agreed upon key storage format that exists outside the bdb.

In the wallet protocol example you would launch the providing service and give it the key to unlock your mining account but no matter what come hell or high water you don't want it touching your kid's account.

A simple example like the one I outlined above would even be backwards compatible with existing bitcoin client since encryption of keys could be turned off.

[Luke-Jr]

Good googley moogley thats complex! Nice work.

It's not done, and draft 0 is looking too complex to become final.

That appears to be a communication protocol.... I'm just worried about how the keys are stored which should be addressed well below that level.

How the keys are stored is strictly up to the Wallet software. The protocol allows you to easily export/import/access keys from any software using it.

If you had your wallet protocol up and running on your machine I should be able to walk up to it, plug in my usb stick with my keys and let err rip while only allowing your app to access what I want. What you've outlined has the application layer determining what keys can be accessed. What if I don't want to give your application access to all my keys? Or I trust your application with my business accounts but not the personal accounts? What if there are competing wallet protocols for different specialized purposes? Your keys should still be able to transfer seamlessly between them.

The point of protocol standards is compatibility. A good standard should need no competition for a long time. Specialized purposes can use extensions. A Bitcoin USB key would implement the protocol, allowing applications to only access keys you unlock with username/password-- or even make spends without access to the keys.

[just_someguy]

The problem I see with what you propose is that it requires a running program.
In a hypothetical situation where I want to use a bitcoin atm with the keys in my pocket, how would this work? Is the atm going to let me execute a program on its hardware so I can launch a wallet service? Thats assuming I have a compatible program of course.

[Luke-Jr]

Your USB device would itself be running the software for your Bitcoin wallet. Anything else would be a security hazard.

[just_someguy]

At that point you're not talking a plain storage device. You need to be walking around with a full fledged mini computer that the ATM just so happens to have drivers for.

[Luke-Jr]

At that point you're not talking a plain storage device. You need to be walking around with a full fledged mini computer that the ATM just so happens to have drivers for.

Of course. Any Bitcoin-enabled ATM is going to need a standard protocol and drivers implementing it. While some people might be crazy enough to allow random ATMs unrestricted access to their keys, that isn't something that should be enabled.

[just_someguy]

I guess thats my point. There needs to be a standard and secure way of allowing access to certain keys that doesn't require toting a processing device around.

[Luke-Jr]

I guess thats my point. There needs to be a standard and secure way of allowing access to certain keys that doesn't require toting a processing device around.

Access to keys is inherently insecure.

[just_someguy]

Only if the keys are stored unencrypted without selective reveal which is exactly how they are stored now.

[Luke-Jr]

Only if the keys are stored unencrypted without selective reveal which is exactly how they are stored now.

No, because keys can be reused.

[just_someguy]

Ok, I think we're just going to have to come to the conclusion we're talking about different things.

It doesn't matter to me how your wallet communicates with the ui etc.
I'm concerned with how your wallet, the piece of software that you are explicitly giving access to your keys, stores keys.
Its this piece that I think should be standard, secure, and portable. In other words lets say your wallet protocol was widely adopted.
I should still be able to try out different wallet management software. How would you move the keys between providers or ensure that you weren't just putting your keys into some black box that now has you locked in?
A standard key storage format for keys and only keys would be needed.
The format wouldn't be concerned with balances, etc, because the software accessing the key would assume its a lie and verify for itself anyway.
You wouldn't trust the software accessing your key file to only look at the keys you want it to so you would provide the information to decrypt only what you want it to see. That even includes accessing public keys.

Either way I wrote one for my own use for a larger project with the help of sipa's branch. I'll release the dump and load code and the file format after its cleaned up.

[Luke-Jr]

I'm concerned with how your wallet, the piece of software that you are explicitly giving access to your keys, stores keys.
Its this piece that I think should be standard, secure, and portable.

I disagree.

In other words lets say your wallet protocol was widely adopted.
I should still be able to try out different wallet management software. How would you move the keys between providers or ensure that you weren't just putting your keys into some black box that now has you locked in?

You would export your keys from the old Wallet software (using the Wallet protocol), and then import them to the new Wallet software (again, using the Wallet protocol).

A standard key storage format for keys and only keys would be needed.
The format wouldn't be concerned with balances, etc, because the software accessing the key would assume its a lie and verify for itself anyway.

A standard for communicating keys is needed for various purposes, including export/import, anyway. This can work just fine for the example you gave. Requiring a standard storage format can prove to prevent innovation in key storage.

[just_someguy]

Well then I'll guess we'll just have to agree to disagree.