Best practices to use a 2013 wallet on current versions?

[takuma sato]

If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?

The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.

[seek3r]

Upgrading from 23.0 to 25.0 shouldnt require any special steps. Just make sure that you backup ur wallet.dat before these upgrades. You always want to be on the safe side. 
Descriptor wallets were already supported with the update to 0.21.0 in 2020. There is a very informative article from @achow101 where he mentioned the benefits.
If you want to use this new feature, you might need to create a new wallet and transfer your funds to it. For basic operations your old wallet format should still work fine and requires no changes.

The upgrade to 25.0 of course brings general improvements in functionality and security and is therefore certainly not a bad idea.
I would always recommend reading the release notes of the new version to always be on the safe side. This knowledge, combined with a current backup of wallet.dat, should make your last doubts fade away.

[takuma sato]

If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?

The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.

If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).

Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.

It was 0.17 and it seems it doesn't work or poses some problem when the wallet is encrypted:

https://github.com/bitcoin/bitcoin/issues/14422

I would honeslty pass on fiddling with the wallet file unless 100% necessary. Is there any problems at all if I just keep the legacy format? as far as I know, the only issue one would encounter was that there is a limit of addresses you can generate in non-HD wallets before you needed to backup:

1.5 Backup Frequency

The original Bitcoin Core wallet was a collection of unrelated private keys. If a non-HD wallet had received funds to an address and then was restored from a backup made before the address was generated, then any funds sent to that address would have been lost because there was no deterministic mechanism to derive the address again.

Bitcoin Core version 0.13 introduced HD wallets with deterministic key derivation. With HD wallets, users no longer lose funds when restoring old backups because all addresses are derived from the HD wallet seed.

This means that a single backup is enough to recover the coins at any time. It is still recommended to make regular backups (once a week) or after a significant number of new transactions to maintain the metadata, such as labels. Metadata cannot be retrieved from a blockchain rescan, so if the backup is too old, the metadata will be lost forever.

Wallets created before version 0.13 are not HD and must be backed up every 100 keys used since the previous backup, or even more often to maintain the metadata.

If you were to generate 101 addresses, what happens to address 101 in practice?

Also this always sounded more secure to me even if you required to make backups each time you generated new addresses to keep them:

The original Bitcoin Core wallet was a collection of unrelated private keys.

[nc50lc]

I would honeslty pass on fiddling with the wallet file unless 100% necessary.

You can always work on a backup rather than the original wallet.dat file.

Is there any problems at all if I just keep the legacy format? as far as I know, the only issue one would encounter was that there is a limit of addresses you can generate in non-HD wallets before you needed to backup:

In the future versions, yes.
In not-so-distant versions of Bitcoin Core, you wont be able to load old bdb wallet.dat files without upgrading it first into sqlite.

Here's the proposed timeline with checklist of the implemented parts: https://github.com/bitcoin/bitcoin/issues/20160

[takuma sato]

Is there any problems at all if I just keep the legacy format?

achow101 mentioned legacy wallet support will be dropped on Bitcoin Core 27.0[1]. If you decide to use that version in future, you must convert legacy wallet to descriptor wallet.

Also this always sounded more secure to me even if you required to make backups each time you generated new addresses to keep them:

The original Bitcoin Core wallet was a collection of unrelated private keys.

I don't see how it's more secure unless you assume master private key alone could be brute-forced or stolen.

[1] https://bitcointalk.org/index.php?topic=5469585.msg62962204#msg62962204

I see a problem with this:

This is one of the most noticeable differences. With descriptor wallets, you cannot export the private key for one address. This is because a child private key combined with the parent public key can be used to compute the parent private key (and hence all other child private keys). This is a risk inherent in BIP 32's unhardened derivation. As such, descriptor wallets disallow the export of child private keys in order to mitigate the risk of accidentally exposing the parent private key.

But you shouldn't be exporting individual private keys anyways. The wallet does not use just one private key, so having an individual child private key is really not that useful.

If you want to export a private key that contains a reasonable amount to carry on a phone and import it into the phones Electrum wallet or whatever, then with the new format you wouldn't be able to do this, because apparently you will not be able to export individual private keys due the new format.

What I've read is that it makes watch only wallet creation much easier.

Also can you finally have a seed that generates the wallet safely like on Electrum if on a worst case scenario you lose your wallet file or that's not possible? From what I read this wasn't really secure but I only use Electrum for phone with small amounts anyway.

--snip--

I see a problem with this:

This is one of the most noticeable differences. With descriptor wallets, you cannot export the private key for one address. This is because a child private key combined with the parent public key can be used to compute the parent private key (and hence all other child private keys). This is a risk inherent in BIP 32's unhardened derivation. As such, descriptor wallets disallow the export of child private keys in order to mitigate the risk of accidentally exposing the parent private key.

But you shouldn't be exporting individual private keys anyways. The wallet does not use just one private key, so having an individual child private key is really not that useful.

If you want to export a private key that contains a reasonable amount to carry on a phone and import it into the phones Electrum wallet or whatever, then with the new format you wouldn't be able to do this, because apparently you will not be able to export individual private keys due the new format.

I get your point. But importing Bitcoin private keys to another device/wallet usually isn't recommended. Just create new wallet on your phone and send some Bitcoin to it.

Look at the fees, not really great to waste money on fees when you are looking at current rates, and we aren't talking settling big amounts, but small amounts to use on a phone number, so it's really not worth it. Importing and exporting private keys could be reasonable if were you hold your keys is an airgapped device, and you could use a QR code reader so nothing is leaked, and we are talking private keys that don't hold some huge amount so it shouldn't be a problem. I'll need to evaluate what is the best way. At least I've seen an achow interview where he says they will keep support for old wallets for at least 3 years, beyond that you'll have to convert the format

If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?

The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.

If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).

Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.

So could someone confirm that this is all one has to do? I would prefer to avoid mistake here. Im going to keep using the old wallet for as long as possible until I know exactly what im doing. I've never had any problems, and I make backups all the time, so the lack of HD was never an issue (because of the limit o addresses being saved thing). Im also not going to be using any features beside simple transactions.
And I do not want to move any funds, so sending tx's to myself in other addresses isn't an option.

[moderator's note: consecutive posts merged]

[achow101]

If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?

The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.

If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).

Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.

So could someone confirm that this is all one has to do? I would prefer to avoid mistake here. Im going to keep using the old wallet for as long as possible until I know exactly what im doing. I've never had any problems, and I make backups all the time, so the lack of HD was never an issue (because of the limit o addresses being saved thing). Im also not going to be using any features beside simple transactions.
And I do not want to move any funds, so sending tx's to myself in other addresses isn't an option.

Recent versions of Bitcoin Core maintain backwards compatibility, you can just open the wallet with them and it should all work. There are a few background upgrades that will occur but these are all backwards compatible (you'd be able to downgrade with no ill effect). If you do not use upgradewallet or migratewallet, then no backwards incompatible upgrades will occur. Otherwise, your wallet should still open and work as you expect it to.

[takuma sato]

If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?

The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.

If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).

Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.

So could someone confirm that this is all one has to do? I would prefer to avoid mistake here. Im going to keep using the old wallet for as long as possible until I know exactly what im doing. I've never had any problems, and I make backups all the time, so the lack of HD was never an issue (because of the limit o addresses being saved thing). Im also not going to be using any features beside simple transactions.
And I do not want to move any funds, so sending tx's to myself in other addresses isn't an option.

Recent versions of Bitcoin Core maintain backwards compatibility, you can just open the wallet with them and it should all work. There are a few background upgrades that will occur but these are all backwards compatible (you'd be able to downgrade with no ill effect). If you do not use upgradewallet or migratewallet, then no backwards incompatible upgrades will occur. Otherwise, your wallet should still open and work as you expect it to.

Yeah but I want to know what to do when Bitcoin Core stops wanting to open good ol 2013 wallets. Do I just run these 2 by then and we are good?

[achow101]

Yeah but I want to know what to do when Bitcoin Core stops wanting to open good ol 2013 wallets. Do I just run these 2 by then and we are good?

There will never be a point where Bitcoin Core refuses to open an older wallet without any additional information. The plan for removing support for legacy wallets includes a migration step that will still work even after the removal has been completed. This migration will remain in Bitcoin Core probably for the rest of time, so if you have an old wallet and open it in a future version, you would get a message informing you to perform the migration so that it can open the wallet.

[tiffy]

If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).

Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.

Sorry, I have a small OT question about this:

I thought all wallets were HD wallets. But I think I misunderstood something. Legacy wallets newly created with Bitcoin Core are HD wallets, but the old ones from 10 years ago are/were not, right?

[nc50lc]

-snip-

Sorry, I have a small OT question about this:

I thought all wallets were HD wallets. But I think I misunderstood something. Legacy wallets newly created with Bitcoin Core are HD wallets, but the old ones from 10 years ago are/were not, right?

Seems on-topic to me.
Yes, but the actual timeline is about 7years and 2months ago.
HD Key Derivation is implemented in Bitcoin Core version 0.13.0. (November 2, 2016)

Here's the link to version 0.13.0 release notes: github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md

[Cricktor]

I thought all wallets were HD wallets. But I think I misunderstood something. Legacy wallets newly created with Bitcoin Core are HD wallets, but the old ones from 10 years ago are/were not, right?

Before hierarchical deterministic keystores were introduced to Bitcoin Core (to my knowledge called BitcoinGUI earlier, don't remember when the name was changed to Bitcoin Core) the legacy keystore contained independant random private keys. Such wallets with a keystore of random independant private keys needed to be backed up regularly. And it was possible to loose keys and funds under certain conditions when you restored an old backup.

Bad things happened under the following circumstances:
The wallet created new fresh private keys in batches when needed, i.e. when the number of unused private keys were exhausted, e.g. in batch sizes of 100 keys (don't remember the exact batch size). Suppose your recent wallet backup contains a keystore size of 500 keys with only a marginal number of unused keys left (you don't see that). You make a few transactions which exhaust the number of unused keys and this triggers the creation of a new batch of fresh keys (keystore size now 600), you still make a few transactions which transfer funds as change to addresses of those newly generated keys (or you consolidate your UTXOs to such "new and fresh" addresses). For whatever reason you still don't have a backup of your wallet with the bigger replenished keystore.
Now something bad happens which forces you to restore from your most recent wallet backup file (which has a smaller keystore size!). This leads to the loss of the most recent new keys batch and subsequently in this case to a loss of funds. In the worst case you loose all your coins in this wallet!

This unwanted situation was the main problem of a keystore of independant random keys. In a HD wallet all present and future keys are deterministic and recreatable from the HD seed key. With a HD wallet it doesn't matter which wallet backup file you restore, you can't loose keys. You may only loose some commentary metadata of addresses/transactions, but nether any keys or any past transactions (a blockchain rescan may be needed after a restore of a backup wallet file).