The Wallet of my Dreams

[Jan]

The wallet of my dreams is something I can carry around. Let's assume that it is an Android app on my smartphone. It contains a number of wallets with different security settings:

• It has a wallet for small change. The wallet is always open, i.e I can always see the balance or spend coins by just starting the app.
• It has a wallet for larger sums. This wallet is closed when I start the app, i.e. I have to enter a password to see the balance and to spend coins.
• It has my vault. This is where I store my stash. This wallet is closed when I start the app. I can open it by entering a long passphrase, and wait say 10 minutes. When the wallet is open I can see the balance and spend coins.

I want this with the following features:

• Feature 1. If I loose my device I want to be able to recreate my wallets on a different device.
• Feature 2. I do not want to do periodic backups.
• Feature 3. I do not want to trust a third party for keeping my wallet private keys.

All of the above can be achieved using the BCCAPI:

• Feature 1. All wallets are deterministically generated from passphrases. If you loose your device you can resurrect your wallets from their passphrases plus a salt.
• Feature 2. You do not need periodic backup beacuse of feature 1. You do however need to remember the passphrases + salt or write them down. (Going forward we may even avoid this. See the wiki on Managing Long Passphrases http://code.google.com/p/bccapi/wiki/ManagingLongPassphrases)
• Feature 3. The wallet private keys are never leaving the device.

Implementing the wallets using the BCCAPI:

• Wallet for small change: You already have it in the SimpleClient example of the BCCAPI. You just need to use an empty PIN and turn it into an Android app.
• Wallet for larger sums: You already have it in the SimpleClient example of the BCCAPI. You just need to turn it into an Android app.
• Vault: You already have it in the SimpleClient example of BCCAPI. You just need to reinitialize the wallet from scratch from a passphrase and salt, and never store the root seed on the device. This way every trace of your private keys are only ever in memory.

Of course each wallet should use be based on different passphrases. Read my wiki on the Security of Deterministic Wallets: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWallets

Apart from this the app should be able to scan QR codes containing receiver's address, display my own addresses as QR codes, have a nice UI and so forth.

All of the above is also available here: http://code.google.com/p/bccapi/wiki/TheWalletOfMyDreams

[etotheipi]

For your information, your post is essentially my goal in (BTC) life.  I suspect I may never actually finish a working client, in which case this just becomes a wishlist I hope other developers will consider.

Some additional features I plan to implement (or wish others would implement):

• "Watching-only" wallets/accounts.  Using a deterministic wallet on an offline computer, only pass the public key of the first address and the "chaincode" to your primary (online) computer.  Using some crypto-magic, this allows the online computer to generate a new address for the offline computer without actually needing any of the private keys.  The private keys never touch the internet, yet you can create addresses and confirm payments from your primary computer!  (The chaincode is sensitive for privacy purposes, but not security purposes--if this chaincode is compromised, someone could figure out that all the addresses are related, but can't get access to the money). 
• Easy transfer of blockchain data to offline computer, and completed/signed transactions back to online computer.  If your private key never touches the network, but it's not too cumbersome to send money from that account, BTC security gets a major upgrade.
• Extreme keystretching for encrypted online wallets. Your private keys are protected by encryption based on a passphrase.  But in order to get from the passphrase to the encryption key, it must be hashed/mangled 10 million times.  This means it will take on the order of 1-2s just unlock your wallet, which is acceptable for the user who enters the correct passphrase every time.  But for an attacker, he's gotta do 10 million hashes/operations just to brute-force-check 1 key.  This makes even simple passphrases much difficult to brute force, as it could take the attacker hours to test a million passphrases instead of seconds.
• Linking of phone accounts to computer accounts.  Computer has smartphone private keys but won't use them unless the user hits the "HELP!" button.  The wallet can then monitor/refill the phone account, and if the device is lost, the program can empty the money that was on the phone into non-phone addresses.  With key-stretching above, you only need to hit the HELP! button within a 1-10 days of losing your phone to re-secure your funds.

I've got all the algorithmic design capability to implement these things, but who knows if I've got the software skills to pull it off.  Regardless, I hope other developers consider these ideas.

[casascius]

The "watching-only" accounts will be vital for e-commerce to start accepting bitcoins.

Suppose someone sells porn for bitcoins.  If bitcoins themselves were stored on the porn server, it gives people a whole lot more incentive to break in.  All the better if the porn server just gave out pre-generated addresses and the porn meister collects the BTC on some computer other than his porn server.

You know what somebody needs to start?  A simple service that watches the P2P network for incoming bitcoins, given a list of bitcoin addresses (no private keys), and simply HTTPS POST's a secure notification to the interested party's website saying that unconfirmed bitcoins have arrived.  Perhaps it would also provide followup notifications giving the confirmation count, as well as perhaps the unexpected occasion that a transaction was lost as the victim of a double spend.

So someone could run a porn site, not need bitcoind - it could just dispense bitcoin addresses and wait for a POST to inform it that bitcoins have arrived, and then it can immediately redirect the user to the porn.  If the transaction somehow turns out to be a double spend, then the account can automatically be cut off just as quickly.

I bet such a service could charge 0.01 BTC per transaction and yet make a ton of money, as it would bring accepting Bitcoins well within the reach of those unfamiliar with talking to bitcoind.

[MoonShadow]

You know what somebody needs to start?  A simple service that watches the P2P network for incoming bitcoins and simply HTTPS POST's a notification to the website saying that bitcoins have arrived.  So someone could run a porn site, not need bitcoind - it could just dispense bitcoin addresses and wait for a service to inform it that bitcoins have arrived, and then it can serve the porn.

That's an excellent idea!  How long do you need to get it done?

[dayfall]

BItcoinNotify does that I believe.

For Feature 2, turning off address generation per transaction would be necessary.

[etotheipi]

The "watching-only" accounts will be vital for e-commerce to start accepting bitcoins.

The great part is, this is literally only a couple lines of code, to enable this kind of key generation.  It's a bit more work, but still not remarkably complicated to just allow for key-pool exchange -- i.e. with the current system, you get the offline system to generate 100,000 private keys and pass the 100,000 address strings to the online computer via USB key.  The computer can use the addresses one-by-one, and warn the user that they are running low and should get more.  It's not the most elegant, but it does work.

Actually, I should be careful saying how many lines of code something is.  It's in C++ and nothing is ever guaranteed to be simple.  But I can assure you that the algorithms are simple.

[Jan]

"Watching-only" wallets/accounts.  Using a deterministic wallet on an offline computer, only pass the public key of the first address and the "chaincode" to your primary (online) computer.  Using some crypto-magic, this allows the online computer to generate a new address for the offline computer without actually needing any of the private keys.  The private keys never touch the internet, yet you can create addresses and confirm payments from your primary computer!  (The chaincode is sensitive for privacy purposes, but not security purposes--if this chaincode is compromised, someone could figure out that all the addresses are related, but can't get access to the money). 

This is more or less what the BCCAPI allows you to do. The main differences are:

• clients built on top of the BCCAPI upload each public key they want the server to monitor, rather than letting the server determine the public keys using a "chaincode".
• the server is not one that you run yourself.

The obvious drawback is that the server will know the relation between the public keys you upload. The big benefit is that you do not need to run and maintain a server, and the client app gets to have minimal memory/communication footprint. IMO this makes the client perfect for the mobile consumer market.

Easy transfer of blockchain data to offline computer, and completed/signed transactions back to online computer.  If your private key never touches the network, but it's not too cumbersome to send money from that account, BTC security gets a major upgrade.

This is what the BCCAPI does. The client can create a request (binary blob of data) for the server to return a SendCoinForm (binary blob of data) for some amount of coins. The SendCoinForm is basically an unsigned transaction. The client can then sign the form and send it to the server, which in turn validates and broadcasts it. Even though the BCCAPI was meant for Android phones you could write a simple client on top of it and use USB sticks to send the blobs back and forth.

Extreme keystretching for encrypted online wallets. Your private keys are protected by encryption based on a passphrase.  But in order to get from the passphrase to the encryption key, it must be hashed/mangled 10 million times.  This means it will take on the order of 1-2s just unlock your wallet, which is acceptable for the user who enters the correct passphrase every time.  But for an attacker, he's gotta do 10 million hashes/operations just to brute-force-check 1 key.  This makes even simple passphrases much difficult to brute force, as it could take the attacker hours to test a million passphrases instead of seconds.[/li][/list]

The BCCAPI uses scrypt (http://www.tarsnap.com/scrypt/scrypt.pdf) to achieve this, which puts constraints on both CPU and memory bandwidth, making a hardware based attack extremely expensive.

Linking of phone accounts to computer accounts.  Computer has smartphone private keys but won't use them unless the user hits the "HELP!" button.  The wallet can then monitor/refill the phone account, and if the device is lost, the program can empty the money that was on the phone into non-phone addresses.  With key-stretching above, you only need to hit the HELP! button within a 1-10 days of losing your phone to re-secure your funds.

Since the wallet is deterministic you can recreate the private keys from your passphrase on any device (phone/computer) and move the funds elsewhere.