Introduce explicit -walletupgrade option #974

Do not automatically change the wallet format unless the user takes an explicit action that implies an upgrade (encrypting, for now), or uses -walletupgrade.

-walletupgrade optionally takes an integer argument: the client version up to which upgrading is allowed. Without an argument, it is upgraded to latest supported version. If an argument to -walletupgrade is provided at the time the wallet is created, the new wallet will initially not use features beyond that version.

Third, the current wallet version number is reported in getinfo.

Thumbnail sketch of test plan:

• Create a wallet using 0.3.* version of bitcoin
• Run 0.6, create a couple of new keys via getnewaddress RPC
• Verify: 0.3.* version of bitcoin can still read wallet, version number in wallet is old

Repeat for 0.4 and an encrypted wallet.

• Run 0.6 with -walletupgrade arg
• Verify: version number in wallet is new, new keys are compressed
• Run 0.6 with a brand-new -datadir
• Verify: version number in wallet is new, keys are compressed

Those are the use-cases I care about.

Results of test:

start with a 0.3.24 wallet start 0.6.0 (master + this pull) reported wallet version is low request 101 new addresses validateaddress reports that all are uncompressed start 0.3.24 validateaddress reports that earlier address are 'ismine'

start with an encrypted 0.4.1 wallet start 0.6.0 reported wallet version is 40000 request 101 new addresses keypool runs out unlock wallet request 101 new addresses validateaddress reports that all are uncompressed open 0.4.1 validateaddress reports that earlier address are 'ismine' unlock wallet unlock succeeds

start with an 0.3.24 wallet open 0.6.0 -upgradewallet reported wallet version is 60000 request 101 new addresses validateaddress reports that the last one is compressed start 0.5.3 error

start with an 0.3.24 wallet open 0.6.0 with -upgradewallet=50000 reported wallet version is low encrypt wallet open 0.6.0 report wallet version is 40000

start with an 0.3.24 wallet open 0.6.0 encrypt wallet open 0.6.0 reported wallet version is 60000

start with no wallet open 0.6.0 reported wallet version is 60000 request new address validateaddress reports it is compressed

start with no wallet open 0.6.0 with -upgradewallet=50000 reported wallet version is low request new address validateaddress reports it is uncompressed

ACK

Code-read ACK, though do we want to enable compression when we encrypt wallets in 0.6 or only encrypt and set minversion to 0.4? Though maybe I dont understand why we would want to do an "explicit" upgrade when encrypting. Also, what, exactly, is meant by an "explicit" upgrade?

Explicit upgrade = the user takes an action from which one can reasonably expect that it makes the wallet incompatible with older versions. Wallet encryption is such an action (and for now, the only one).

Also, when an upgrade is done, it always upgrades all the way, unless a parameter is passed to -upgradewallet, and that constraint does not need to be broken.

ACK

A summary of the policy implemented by this patch:

• -upgradewallet and -upgradewallet=0 force an upgrade to the latest version
• -upgradewallet=<version> allows (but does not force) upgrades up to version <version>, unless the user takes an explicit action that requires upgrading beyond <version>, in which case an upgrade to the latest version is done.
• no argument is identical to -upgradewallet=10500

A simplified summary:

• Wallets are not automatically upgraded, unless the user specifies -upgradewallet, or takes an explicit action that requires an upgrade. In both cases, we upgrade to the latest supported version.