Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Wolf0 on February 20, 2013, 01:34:50 AM



Title: What is stored in the wallet.dat file?
Post by: Wolf0 on February 20, 2013, 01:34:50 AM
NaN.


Title: Re: What is stored in the wallet.dat file?
Post by: deepceleron on February 20, 2013, 10:48:25 PM
1. The wallet can be encrypted, you must know how to recognize this and properly decrypt and reencrypt data,
2. Examine the code of pywallet, and run pywallet to do a wallet dump to get an idea what data is stored,
3. Understand what you are doing 110%, there's stuff in there like reserve keys, transactions, address book, etc.


Title: Re: What is stored in the wallet.dat file?
Post by: niko on February 22, 2013, 12:17:43 AM
Could someone point me to pywallet? I searched for it, but couldn't find it.
Try searching the Internet using your favorite search engine.


Title: Re: What is stored in the wallet.dat file?
Post by: etotheipi on February 22, 2013, 12:48:19 AM
For reference, Armory's wallet format is documented here:

http://bitcoinarmory.com/armory-wallet-files/

Armory, at one point, also had code for reading the Satoshi wallet, encrypted or not.  The code (https://github.com/etotheipi/BitcoinArmory/blob/master/qtdialogs.py#L2633) was based on pywallet's code.  However, that code is commented out because Armory couldn't support Bitcoin-Qt's switch to compressed public keys.  Thus, there actually is not a way to convert new wallets to Armory format, because it will calculate different (incorrect) addresses for the private keys.  This will be fixed soon in Armory (with new wallet format), but I suspect Armory won't be the only app that has this problem.


Title: Re: What is stored in the wallet.dat file?
Post by: DannyHamilton on February 22, 2013, 05:02:45 PM
Could someone point me to pywallet? I searched for it, but couldn't find it.

http://bit.ly/WZmG1x


Title: Re: What is stored in the wallet.dat file?
Post by: etotheipi on February 22, 2013, 07:19:02 PM
For reference, Armory's wallet format is documented here:

http://bitcoinarmory.com/armory-wallet-files/

Armory, at one point, also had code for reading the Satoshi wallet, encrypted or not.  The code (https://github.com/etotheipi/BitcoinArmory/blob/master/qtdialogs.py#L2633) was based on pywallet's code.  However, that code is commented out because Armory couldn't support Bitcoin-Qt's switch to compressed public keys.  Thus, there actually is not a way to convert new wallets to Armory format, because it will calculate different (incorrect) addresses for the private keys.  This will be fixed soon in Armory (with new wallet format), but I suspect Armory won't be the only app that has this problem.

Why not simply decompress the keys?

Because you get a different address.

EDIT:  It's not terribly complicated to implement the correct logic, it's just that I tested the bejeezuz out of the current wallet format, and it is the most sensitive part of the application.  I didn't want to mess with what was working.

If you're not clear on why compressed keys give you a different address and how they are handled in Bitcoin-Qt, you should do a little research before moving keys between wallets.  


Title: Re: What is stored in the wallet.dat file?
Post by: etotheipi on February 22, 2013, 07:59:35 PM
If you're not clear on why compressed keys give you a different address and how they are handled in Bitcoin-Qt, you should do a little research before moving keys between wallets.  

I'm working on that right now. From my existing knowledge of compression, however, compressed keys should just need to be decompressed. Obviously, that's not the case, so I'll be looking into it.

I was short because I was in a hurry to respond.   Now I have 30 more seconds :) 

The reason is that your bitcoin address is the hash of your public key.  If you use a compressed public key, you get a different hash than if you used the uncompressed key.  The ECDSA is all the same after uncompressing, but you need to make sure you're using the right address.

As such, the Bitcoin-Qt devs decided to add a 0x01 byte to the end of all private keys that use compressed public keys.  If it was not there, then having the raw ECDSA key would give no indiciation of whether to use compressed or uncompressed for hashing to create the address.   For instance -- in Armory, the 0x01 byte will be added when keys are "encoded" to be moved around, but in the file format, they will be stored as 32-byte integers with a one-bit flag identifying whether they are compressed.  That's why it matters.