Topic: Wallet import/export: bitkeys format - page 2. (Read 19324 times)

According to wikipedia and this site, PEM is specifically used for X.509 certifications (public keys).

edit... Yeah, I don't think PEM is a good fit, though maybe something following that general convention...

-----BEGIN BITCOIN PRIVATE KEY-----
...
-----END BITCOIN PRIVATE KEY-----


I agree.


In addition to the uses for security, this use case would also work for transferring some coins between devices you own without having to do a transaction. For instance, if you wanted to transfer 100 BTC to your mobile device to spend, you could do so using this method.

I would focus on use cases.

1. Back up all the keys in a wallet, and later restore the wallet state if the wallet is deleted or corrupted.

2. Merge two wallets by exporting all the keys in one, and importing to another.

3. Export and remove selected keys from wallet, for moving to safe long-term storage in case the wallet is hacked; later, move the keys back to a wallet for spending.

4. Export selected keys for transferring their funds to someone else; the recipient imports the keys and gains access to the funds.

Any others?

I wonder whether it makes sense to use bitkeys format for case 1 and 2. Wallets do have other things, which is part of your problem. I'd suggest that case 1 & 2 should use wallet formats.

This would mean you don't have to worry about reserve keys. I'd treat the other key classes the same.

Case 3 & 4 are very similar. They suggest you should have an export-and-delete function. Gavin suggested: 1. export key to disk file; 2. read disk file, make sure key is there; 3. delete key from wallet.

Case 4 probably should delete the exported key. You can save a copy and re-import it if the recipient never uses it.

For the case 4 import you really want to do: 1. import keys; 2. do a spend from these keys to one of yours; 3. delete imported keys. That assures that ownership transfers. You don't need this for case 3 import as it's your key.

Finally, as far as the address and balance: I don't like putting them into CSV fields, because they are redundant and unnecessary. Your comment fields seem okay, but note that the balance may be out of date. How about a command that would take a bitkeys file, and display the address and current balance? Then you could leave the comments out.

Keys have a standard PEM format...

I'm assuming this functionality is going to be exposed via JSON-RPC, at least at first. Why not have it return a JSON representation of the private keys?

I'd suggest using a standard, existing format instead of inventing a new one.

Either get rid of the version number and do standard CSV:

Or maybe .ini-format, with each private key a different section:
(bitcoin already contains .ini-file-parsing code, from boost)


I think there are lots of advantages to using an already-standard file format.

As you're writing the code for this, it's best if you take the lead. Adding additional fields for labels sounds OK to me, however please be aware that allowing arbitrary user-provided text in the format complicates it significantly (character encodings, escaping of the commas/newlines/hashes etc).

Hello all,

I've been working on a patch for bitcoin which allows exporting and importing of wallets in the so-called bitkeys format (initially suggested here: https://bitcointalksearch.org/topic/m.52066).
Now there are still some issues with this, so i thought maybe it's a good idea to discuss some details in a separate thread.

First of all, there are basically four classes of keys:

• (1) Used keys, which have unredeemed transaction outputs linked to them (and thus contain funds)
• (2) Used keys, which only have redeemed transaction outputs linked to them (worthless, but the addresses may be used still by others)
• (3) Unused keys (whose corresponding addresses may have been published)
• (4) Reserve keys (whose corresponding addresses have typically never been divulged, but may have been divulged at the time the export is imported again)

Furthermore, for the first three classes, each key may either be in the address book or not, and have a label/account name or not (which may or may not be considered relevant information for a wallet export).

Especially for the reserve keys, I'm not sure what the best way to proceed is when importing. Clearly, you don't want to add them to the reserve keys when importing (either they've been used in between already, in which case they should definitely not become a reserve key but still imported, or they haven't ever been used, probably never will, and importing them would just clutter the wallet).

The current proposed bitkeys format does not contain information about how the key was used, whether it is a reserve key, or what label it has. Maybe it is useful to add that information to the format?

Currently, my dev branch (https://github.com/sipa/bitcoin/tree/walletdump) produces exports with lines like this (warning: valid, importable, testnet keys):

v=1
91iwnurxhWmDF9gqwc4CbuLCB4HxuMXf5B2vEhTPDftY3rkMgDY,10806 # moura6ybHvwzMtrWdyqiEN6n2mMakf8HxD (50.01 BTC)
92JsNVMJgG4RiC2ARxpduJp8DXKgdDMj9WREE5jo66Hg8UMdr3L,10870 # mmFPR1oaDExBfJqpRohWBvbE2aCg86Kwcx (0.00 BTC)
91s3swvX2a3F7FDoypEV7rTVhWUKiw8RCBmDuHMN8xMksLn3YtV,10870 # midiVjwgBCkMSup4X2FifFinwLhpHYe2wn (unused)
93NM1B7y35d9VxqGBvc8DZcAvEB9kE5UZV7WqNGMTNWhPBdhsJT,10870 # (reserve)

The first line is a class-1 key, with an unmatured generation output (so not yet really 50.01 BTC). The second line is of class 2, the third of class 3, and the fourth of class 4. Notice that the block number for keys without balance is always the current block number (since there is definitely - unless in case of a chain split - no available money transferred to these before), and that the address for reserve keys is not revealed.

So, I suggest to a third field, which distinguishes between those classes, either a boolean active/inactive, or some more elaborate form. Maybe an optional fourth field that contains the label for adding it to the address book is useful as well?

The format of the private keys is described on https://bitcointalksearch.org/topic/m.55643, and also contains a version number and a checksum, like addresses.

Ideas/comments/suggestions/remarks/bitcoins?