[PULL] private key and wallet export/import

[Pieter Wuille]

See https://github.com/bitcoin/bitcoin/pull/220

Introduces four new RPC calls:
* dumpprivkey: retrieve the private key corresponding to an address
* importprivkey: add a private key to your wallet
* dumpwallet: export the contents of your wallet in various ways
* importwallet: import/merge a dumped wallet into your own

The private key format is analoguous to the address format. It is
a 51-character base58-encoded string, that includes a version number
and a checksum.

The wallet format is JSON-based, and includes:
* addresses (informational, optional)
* private keys
* amounts and balances per address (informational, optional)
* blocks where addresses were first used (optional)
* ids of transactions in which addresses were credited (optional)
* labels (optional)

It specifically does not contain:
* sender address book
* settings
* account information
* unconfirmed wallet transactions

I will post a full specification of the dump file format soon.

Earlier posts:
* Hal's challenge: http://bitcointalk.org/index.php?topic=3638.0
* Early discussion of dump format: http://bitcointalk.org/index.php?topic=4448.0
* Early patch with only private key export and import: http://bitcointalk.org/index.php?topic=3906.0

[1714634066]

1714634066

[fergalish]

This is great work.

Now I have a better idea on how to do wallet backup.

1. Set up a directory on a usb key (256MB should be enough), and start bitcoin pointing to that directory, with no keypool. 
2. Generate as many addresses as you need with that client - e.g. suppose you have 100BTC and you want to store 5BTC in each address, then you'll need 20 addresses.
3. Now, with your main bitcoin client, send these 1BTC to each of those 20 addresses.
4. Watch the bitcoins roll into your usb-based client.
5a. Now dump all the private keys with these new functions,
5b. encrypt them with good software and a good passphrase
5c. (optionally append each of them to 1kb of random data, to get extra entropy)
5d. store the sha256 hash of the unencrypted and encrypted data
5e. Now save the encrypted data, and the two has functions.
5f. Make lots of copies, print them out & photograph them, upload the photos to flickr... whatever.  uuencode it and store the text on your bookshelf if you like.  Store the digital copies on your desktop, laptop, usbkeys, cellphone, dropbox, freenet, everywhere.
6. Now the important bit: you MUST erase all data on the usb key.
7. Better still, destroy the usb key 'cos good usb keys will do block remapping, so even if you wipe the key with random data, reformat and so on, you'll never be quite sure that some clever hacker can't extract one or more of your keys.

Result:
Now, anytime you need 5btc, you just need to recover one of those encrypted private keys, whether it's in an image, or if you have to type out a few pages of uuencoded data.  Then decrypt, check the hash, take the last 51 characters, and import the key into your day-to-day client.

Of course, this is all a bit excessive for just 100BTC, but who knows, given recent trends in USD/BTC, we may well soon reach the stage that even 100BTC need to be securely protected.

[fergalish]

Now, I just had another thought that maybe deserves its own post.

Why not create code that allows bitcoin to create a new address (not from the pool), then send some specified number of coins to that address, then dump the private key to screen, and then delete all trace of that private key from the computer - no saving it to disk at any time, not even permitting the OS to swap it out to disk.

Users would then have to take adequate steps to ensure they doesn't lose that key.

Obviously, there would have to be flashing black and yellow warning screens, telling the user that if they don't securely save the key that's now on screen, they'll lose their coins.

Thoughts?

[Gavin Andresen]

Thoughts?

That'd be exactly when the power goes out.

[Artefact2]

Now, I just had another thought that maybe deserves its own post.

Why not create code that allows bitcoin to create a new address (not from the pool), then send some specified number of coins to that address, then dump the private key to screen, and then delete all trace of that private key from the computer - no saving it to disk at any time, not even permitting the OS to swap it out to disk.

Users would then have to take adequate steps to ensure they doesn't lose that key.

Obviously, there would have to be flashing black and yellow warning screens, telling the user that if they don't securely save the key that's now on screen, they'll lose their coins.

Thoughts?

Or (and that's doable ATM) :

1. Encrypt the wallet.dat with OpenSSL, using a passphrase only :
openssl aes-256-cbc -a -salt -in wallet.dat -out wallet.dat.enc

2. Store the wallet.dat.enc (and its sha1 preferably) in various places : USB keys, portable media players, external hard drives, you can even email it to yourself !

3. If needed, get the wallet.dat back with :
openssl aes-256-cbc -d -a -in wallet.dat.enc -out wallet.dat

This method is really straightforward, you can put your wallet in several independent locations, and you don't have to keep a private key or something. Just a passphrase. This is imho the method that has the best security and reliability / complexity ratio. If you use bcrypt instead of OpenSSL, it's even simpler : bcrypt wallet.dat to encrypt, bcrypt wallet.dat.enc to decrypt. 

[Pieter Wuille]

A wallet dump is a JSON formatted file, with the following definition:


wallet_dump :: object {
  "keys" : list of key_entry  // the key information itself
  "loc" : locator             // information about the currently best known chain
}

key_entry :: object {
  "sec" : string              // private key in base58 format
  "addr" : string             // address in base58 format (verified on input, but ignored)
  "label" : string            // label for the address corresponding to this key
  "height" : int              // first block height this key is known to have been used in
  "heightAvail" : int         // first block height this key is known to have been used in
                              // with a not-yet redeemed transaction output to this key's address
  "value" : string            // decimal representation of total BTC sent to this key's address
  "valueAvail" : string       // decimal representation of available BTC sent to this key's
                              // address
  "tx" : tx_table             // list of transactions
  "reserve" : int             // nonzero if tx is a reserve key
}

tx_table :: object {
  string : tx_entry          // key is txid, or txid:outputid
  ...
}

tx_entry :: object {
  id : string                // txid in hex format
  height : int               // height of block this tx is known to be placed in
  value : string             // decimal representation of BTC sent to the address corresponding to
                             // parent key_entry's private key by this tx
  spent : bool               // whether or not this tx is known to be spent
}

locator :: object {
  string : int               // key is blockid, value is block height
  ...
}


The "addr", "heightAvail", "value", "valueAvail" and "spent" fields are not used when importing.
The "height", "tx" and "loc" fields are used to determining what to rescan.
Only "sec", "label" and "reserve" contain actual data that is imported.
Only 'sec" is really required.

[netrin]

I put all my keys in a git repository. Except for the fear that the 'authorities' are gonna knock on my door later in the decade, I'm far more afraid to delete keys than feel the need to obfuscate them. I'm considering sending a CD to my brother and next of kin with keys and instructions. I assume more BitCoins have and will be lost rather than stolen.

[SgtSpike]

I'm very interested in using this for importing custom-made key pairs (sec + addr) into a given wallet.  Would that be possible even though an address may not have yet been used in a block, and has a 0 value?

Also, when could we expect this sort of a change to be made?

[Stardust]

I'm really looking forward to this feature.  Ideally there should be no wallet.dat, but a directory in .bitcoin where all private keys reside, that would allow the user more flexibility.

[ffe]

I'm interested in this feature as well. Is there a current discussion going on?

[kwukduck]

Hopefully exporting and importing specific keys will be an option soon.

[riush]

Added an optional parameter to specify the account for importprivkey. I also changed it to use the default account "" instead of "imported" when no account is given.

https://github.com/mhanne/bitcoin/commit/a774c70727b616e8b9d42caaf2e8b5fbd9cd9087

[AntiVigilante]

About time! yes! thank you with sugar on top.

[Pieter Wuille]

Added an optional parameter to specify the account for importprivkey. I also changed it to use the default account "" instead of "imported" when no account is given.

https://github.com/mhanne/bitcoin/commit/a774c70727b616e8b9d42caaf2e8b5fbd9cd9087

Nice improvement - I've merged it in my branch.

[passerby]

Now this one is utterly lovable.

[seer]

Is there any chance of adding a method to export a new address/private key without it ever been added to your wallet? Reason is i am looking at using this store bitcoins offline as such but don't want to have to delete my wallet each time i generate a new exported address/private key pair. At this stage i am looking at creating a new data directory of the client so i can do this manually by deleting the wallet each time but just seems like a waste of time and effort that could be done in the method.  Maybe if you don't pass an address in it generates a new address/private key pair and returns them and never adds them to the wallet.

[joan]

Is there any chance of adding a method to export a new address/private key without it ever been added to your wallet?

It looks like you are trying to create valid Bitcoin private/public key pairs completely outside of the context of the client.
Maybe check this topic: how to bury some bitcoins without even installing the client.

[SgtSpike]

Is there any way to use this pull before it is included in the standard build?  I am anxious to play around with it...

[casascius]

Please put this in the regular build.  These features are highly useful and I find myself using them regularly.

They will also be vital in making Bitcoin attractive to people too afraid to store wallet.dat's on their computers or use the client.  If private keys can easily be exported and imported from human-readable characters, people can have paper wallets.

Once this is done right, the instructions for making a safe hacker-proof offline wallet become idiot proof:
1 - generate an offline wallet and print it on a piece of paper (or have one mailed to you in a letter from XYZ trusted provider for $1 PPUSD)
2 - transfer your BTC to the public key (the number that starts with 1)
3 - when ready to spend, load the coins with the secret key (the number that starts with 5), OR type the secret key into screen X at MyBitcoin/MtGox/TradeHill/wherever, and redeem your funds.

BTW, for anyone unfamiliar, this is what a sample private key looks like encoded in Base58: 5KVZnDNgk6VUpe1yWq7HFizU6K5vHCHSbQQonQ8JoqCkyLjDS2R

(Like a Bitcoin address, but about 51 characters, starting with a "5", and includes strong error detection built-in, so typos are virtually always caught automatically)

[SgtSpike]

Please put this in the regular build.  These features are highly useful and I find myself using them regularly.

They will also be vital in making Bitcoin attractive to people too afraid to store wallet.dat's on their computers or use the client.  If private keys can easily be exported and imported from human-readable characters, people can have paper wallets.

Once this is done right, the instructions for making a safe hacker-proof offline wallet become idiot proof:
1 - generate an offline wallet and print it on a piece of paper (or have one mailed to you in a letter from XYZ trusted provider for $1 PPUSD)
2 - transfer your BTC to the public key (the number that starts with 1)
3 - when ready to spend, load the coins with the secret key (the number that starts with 5), OR type the secret key into screen X at MyBitcoin/MtGox/TradeHill/wherever, and redeem your funds.

Just FYI, the public key and the bitcoin address are two separate things.  The address (that starts with a 1) is a series of hashes of the public key.  The logic is sound, the terminology is just off a bit.