Why did my bitcoin core descriptor wallet generate 16 output descriptors?

[Forsyth Jones]

Bitcoin Core v26.0

When I create a wallet in Bitcoin Core, then I gave the _{listdescriptors} command, I could see that it generated 8 output descriptors, two for each scripts (receiving and change), but when I checked the other day, giving the _{listdescriptors} command, I came across with 16 descriptors.

I don't remember importing any descriptors in this new wallet.

Remembering that the new generated descriptors generated a new xpriv, I checked it with the true argument.

Detail: I never transferred any funds to this new wallet.

[Churchillvv]

I'm not too aquatinted with technical knowledge but from a quick search I just did, such thing happens if you have created or imported an old wallet while the Bitcoin core is running and then you deleted it from the disk while it's still in memory and then you created another one using the same name, it proceeds to write both the deleted and new wallet descriptors to the wallet.dat [1]

This might be totally wrong because from the source I read it from it was specifically for ordinals issues.

[1] https://github.com/ordinals/ord/issues/2719#issuecomment-1866006258

[achow101]

If you've encrypted your wallet since creating it, you'll get new descriptors. This behavior is analogous to the legacy wallet dropping the keypool and generating new keys when encrypting.

[Forsyth Jones]

I'm not too aquatinted with technical knowledge but from a quick search I just did, such thing happens if you have created or imported an old wallet while the Bitcoin core is running and then you deleted it from the disk while it's still in memory and then you created another one using the same name, it proceeds to write both the deleted and new wallet descriptors to the wallet.dat [1]

This might be totally wrong because from the source I read it from it was specifically for ordinals issues.

[1] https://github.com/ordinals/ord/issues/2719#issuecomment-1866006258

I still can't prove whether the new wallet descriptors are the same as those excluded by the previous wallet.dat.

If you've encrypted your wallet since creating it, you'll get new descriptors. This behavior is analogous to the legacy wallet dropping the keypool and generating new keys when encrypting.

@achow101 What do you think?

When I have time I will do more tests.

So is it normal behavior for the wallet to create 8 new descriptors, leaving 16 in total after encrypting the wallet?

[achow101]

I'm not too aquatinted with technical knowledge but from a quick search I just did, such thing happens if you have created or imported an old wallet while the Bitcoin core is running and then you deleted it from the disk while it's still in memory and then you created another one using the same name, it proceeds to write both the deleted and new wallet descriptors to the wallet.dat [1]

This might be totally wrong because from the source I read it from it was specifically for ordinals issues.

[1] https://github.com/ordinals/ord/issues/2719#issuecomment-1866006258

I still can't prove whether the new wallet descriptors are the same as those excluded by the previous wallet.dat.

There's no guarantee that all previous descriptors would show up, and certainly not with their private keys. You'd have to do a pretty weird sequence of things for all of the previous descriptor to appear. If that happened, it probably wouldn't load without errors either.

So is it normal behavior for the wallet to create 8 new descriptors, leaving 16 in total after encrypting the wallet?

Yes,

[nc50lc]

When I have time I will do more tests.

So is it normal behavior for the wallet to create 8 new descriptors, leaving 16 in total after encrypting the wallet?

Even with a total of 16, only the newly generated 8 are the "active" descriptors.
Active ones are the descriptors to be used when requesting addresses in the GUI's receive tab, change address and getnewaddress command.
The inactive descriptors prior to encryption will not be used to generate new keys/addresses but will still be able to track and sign associated transactions.

In your test, you can check each descriptor's active status in listdescriptors command.