Long-term, safe, store-of-value about bitcoin

[davout]

File should be human-readable

[mgiuca]

Seconded. I have been using Bitcoin for a couple of days, and while many users will not care about the details, I want to know (at least during my initial testing of the system) exactly how it works. This will help me, and other tech-savvy users understand the security implications.

To me, the biggest "black box" of the whole system is the wallet. It's a binary blob which I am told to keep backed up or else. It's unclear to me how I would restore it without erasing recent transactions. I'm not sure which data is stored in it and which is not -- from the look of some other bugs here, it seems to store more data than just the public/private keys (such as config data). Does it store the names I have associated with the addresses? (I wouldn't want to lose my PC, restore my wallet.dat, and discover I can't tell who sent me what, so I'd hope it does store those names.) Does it store sending addresses? (I don't think it should, as that's more of an address book than a crucial wallet.) And it isn't encrypted with a password.

I'm not asking for answers to these questions -- I can find them out if I really want to. I'm saying that these answers should be immediately obvious from inspecting the wallet file. There should be nothing "magical" about this file, for an advanced user.

I would like to see a transition to a "Wallet 2.0" file format, which is simply a PGP-encrypted text file (so, binary, but a simple gpg -d will get the text out). I should be able to encrypt it with either a symmetric or public key.

Inside the file, there would be a simple ASCII format, such as:
<address> (active|inactive) [name] <pub-key> <priv-key>

with one address per line (or split into "sections" if the pub-key and priv-key are too long to put on a single line). The active|inactive determines whether the address shows up as a receive address in the GUI (so when it pre-generates 100 addresses, they all show up here, and are all marked inactive until the user presses "New Address" in the UI).

This would only contain receiving addresses. Sending addresses would be in a separate address book file, which would hopefully also be a text file, and I could back up too if I wanted to but isn't critical.

Now, at a glance, I (as a technical user) can tell exactly what data is stored in the wallet. And it should be significantly easier to write tools for listing all the money associated with each account in the wallet, splitting up a wallet into separate files, and so on.

[Kiv]

Agree about human readable, I would love to actually understand the contents of my wallet.

[gavinandresen]

See my bitcointools tree for a (python) tool that dumps out the information in the wallet in a human-readable form.

[sipa]

I'm currently working on a patch that will allow export and import of wallets in a human readable form.

The format i've been using currently has lines of this form:
[privatekey] [block nr of earlest unredeemed output to this key] # [address] [available BTC]

The part after the # is optional, since only the private key suffices, the rest can be derived, The block number was suggested by Gavin on the forum somewhere, as an optimization.

Maybe adding address labels is useful as well.

[mgiuca]

There has been some discussion relating to a so-called ".bitkeys" format, which would be a standardised human-readable text file format for storing Bitcoin private key data. It seems to have been suggested here by [mike]:
http://www.bitcoin.org/smf/index.php?topic=3638.40

I don't know if the format discussion has moved elsewhere, but you should try to be compatible with this format.

Basically, this means your file should start with v=1 (version, I assume). Exporter should write v=1, importer should check for v=1.

Otherwise, what you suggest is almost right, but the private key and block number should be comma-separated:
base58 encoded privkey,block number # comment

Everything after the hash is a comment. You said it was "optional" but that sort of implies that your software will possibly be looking for an address and available BTC. It should not, since the format should allow arbitrary machine-ignored text after the #. So your exporter should write # [address] [available BTC] or whatever you want, but your importer should completely ignore everything after the comment and just use the privatekey to derive the public key and address.

Also note, if you haven't written the code for this already, that I already implemented, in C using OpenSSL, the code to take a 32-byte private key and generate the full 279-byte DER key (which Bitcoin internally calls the "private key") and 65-byte public key. My intention was for my code to eventually be used inside Bitcoin itself, so please use it if you can:

• bitcoin-import Bazaar branch
• priv_der.c

It is currently a command-line program which takes the private key as input and produces the DER key (of which the public key is a substring), but it is very well documented and could easily be adapted into a bitkeys file reader.

[sipa]

Sure, that thread is where i got the idea, i couldn't remember where it was. The code for importing and exporting private keys also already exists, see http://www.bitcoin.org/smf/index.php?topic=3906. The hard part is keeping the data structures in bitcoind intact and up to date when importing things.

The precise formatting is only a detail that can easily be changed. Clearly, the importer will ignore everything after a #, as the address and available BTC to an address can be derived from the private key and the block chain, but still useful for human readers, so the exporter will put them in comments.

Maybe we should start the format discussion again, since there are additional useful things to put in such a file, it seems. Whether or not the key is only a reserve key, a possible label for a key, ...

[enterprisey]

+1 on human-readable.

[laanwj]

No +1ing here please. If you comment, add something substantial. Otherwise, code or gtfo :)

[jgarzik]

I think this issue is too vague and outside the scope of what we normally consider issues/pull reqs, these days. Recommend closing.

[Diapolo]

@jgarzik ACK