WIF Format and Storing Private Keys

Question

I'm writing an Android app which will be storing private keys for Bitcoin and a few Altcoins in an SQLite database. To store my private keys, I was initially using the WIF. When I take them out of the database, however, I just Base58 decode them back into the 32 byte private key. Is there any real advantage to using the Base58 format for storing the keys in WIF vs basic hex encoding (0x12 to "12")? I know the WIF is useful for human transposition, but I'm specifically wondering about storage here.

So far, what I've come up with is that the Base58 format:

1. Takes slightly less space
2. Tells me what coin type the address is used for
3. Has error checking
4. Tells whether the private key is used for a compressed or decompressed address.

Items 2-4, however, are things that I could get from other entries in my SQLite database, so they're not critical. How does the Bitcoin-QT client store its private keys? I know when it dumps them to the user it gives them in WIF, but I'm wondering what it does internally to save keys on the machine and if I should do it the same way.

Answer 1

The Bitcoin Core client stores private keys typically in DER encoded format, at 279 bytes per key, for compatibility with older versions. There is no good reason for that though. For encrypted wallets, which are more modern, keys are stored using just the (encrypted) 32 byte secret plus the full public key. Compression is derived from the length of the corresponding public key, so it doesn't need to be stored separately.