Author

Topic: wallet.dat file format versions (Read 273 times)

brand new
Activity: 0
Merit: 0
April 01, 2019, 01:45:19 AM
#6
I wouldn't take any risks and simply move my assets to another wallet. Beginning bitcoin center without a wallet.dat document in the information registry should compel it to produce another wallet. At that point you simply send from the old wallet to a location in the upgraded one.
brand new
Activity: 0
Merit: 0
April 01, 2019, 01:03:07 AM
#5
Thanks. It was indeed strange for nFileVersion to actually mean "nLastClientVer".
It's due to legacy reasons. The original Bitcoin client had one consistent version number for everything, including the client version, the wallet file version, network protocol version, etc. Over time, these have been separated because it doesn't make any sense to have one version number for everything as they aren't all tied to each other that strongly. However, because of this original versioning model, the wallet version number would increment for every new client version and this was reflected in the wallet file by updating the "version" record.

As the version number was separated from the client version number, it became necessary to have the wallet have its own actual version number.
krogerfeedback Unfortunately the "version" field could not be used for backwards compatibility reasons. It's old behavior of updating for every new client had to be maintained, so it effectively became an indicator for the highest versioned client that has opened that wallet file.

I guess the WalletFeature values correlate roughly with software versions. Why the ..99.. in the newer ones?
This is also due to legacy reasons. As I mentioned above, the wallet version number was tied to the client version number. The client version number for the development version of Bitcoin Core ends with 99, so wallet versions where the version number was bumped during development just followed the client version number and thus also ended with 99. The client and wallet version numbers are no longer tied together so we can use other version numbers. However the same convention may remain as it does obviously indicate which software version first introduced a feature.

Happy to hear that! Your comment made mine.
staff
Activity: 3458
Merit: 6793
Just writing some code
March 13, 2019, 03:16:18 PM
#4
Thanks. It was indeed strange for nFileVersion to actually mean "nLastClientVer".
It's due to legacy reasons. The original Bitcoin client had one consistent version number for everything, including the client version, the wallet file version, network protocol version, etc. Over time, these have been separated because it doesn't make any sense to have one version number for everything as they aren't all tied to each other that strongly. However, because of this original versioning model, the wallet version number would increment for every new client version and this was reflected in the wallet file by updating the "version" record.

As the version number was separated from the client version number, it became necessary to have the wallet have its own actual version number. Unfortunately the "version" field could not be used for backwards compatibility reasons. It's old behavior of updating for every new client had to be maintained, so it effectively became an indicator for the highest versioned client that has opened that wallet file.

I guess the WalletFeature values correlate roughly with software versions. Why the ..99.. in the newer ones?
This is also due to legacy reasons. As I mentioned above, the wallet version number was tied to the client version number. The client version number for the development version of Bitcoin Core ends with 99, so wallet versions where the version number was bumped during development just followed the client version number and thus also ended with 99. The client and wallet version numbers are no longer tied together so we can use other version numbers. However the same convention may remain as it does obviously indicate which software version first introduced a feature.
member
Activity: 301
Merit: 74
March 13, 2019, 02:47:36 PM
#3
Thanks. It was indeed strange for nFileVersion to actually mean "nLastClientVer".

I guess the WalletFeature values correlate roughly with software versions. Why the ..99.. in the newer ones?
staff
Activity: 3458
Merit: 6793
Just writing some code
March 13, 2019, 02:30:19 PM
#2
A list of wallet versions can be found in the source code itself: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L108. The names for each version are fairly self explanatory. There are also brief comments for each one.

What are some reasons to want to -upgradewallet, or the contrary, to not upgrade?
Upgrading lets you use new wallet features that are not backwards compatible.

Conversely if you think you will downgrade at some point in time, you probably won't want to downgrade in order to maintain compatibility with old wallet software.

While debug.log reports nFileVersion, it isn't the format version.
Is there a way to get Core to report the actual format version?
AFAIK, no, at least not logged to the debug.log file. This is being changed in this PR: https://github.com/bitcoin/bitcoin/pull/15588

You can get the actual wallet file version using the getwalletinfo RPC command.
member
Activity: 301
Merit: 74
March 13, 2019, 02:16:13 PM
#1
Is there a list of wallet.dat format versions, and what's changed in each?

What are some reasons to want to -upgradewallet, or the contrary, to not upgrade?

While debug.log reports nFileVersion, it isn't the format version.
Is there a way to get Core to report the actual format version?
Jump to: