Retrieve extended private key from child keys or sibling keys

Question

I've looked through the various questions and answers regarding this topic but I can't find the answers to mine.

I lost access to my wallet since calling encryptwallet which crashed the bitcoin software. I did many scans with all the tools available on github and also some that I wrote.

My wallet contains 4 masterkeys (m path) of which 2 can be decrypted with the password of the wallet and contains more than 1500 addresses. Only around 200 can be decrypted with the password.

I found the xpriv for these two decrypted masterkeys by importing them into bitcoin core with the sethdseed function.

I found in the hexadecimal chains of the portfolio 20 addresses which have not been encrypted and of which I therefore know the private key, the encrypted key, the pub key, the derivation.

I can't find any way to find the xpub of the other two mastrkeys which will have allowed me to find all the other private keys. The Chaincode is missing and can't find it in wallet.dat.

I tried to modify the Bitcoin code to convert according to the same logic as for the WIF key import but without success.

My questions are:

• Is there a way to convert the public key like I did for the private key?
• Can I find the sibling keys with the amount of private keys that I have recovered?
• Do you see another way to recover my funds?

I anticipate a generous reward. Thank You

Answer 1

From what you've stated, there is no way to recover those private keys.

Bitcoin Core's wallet does not store xpubs, or even xprvs. It derives the private keys as needed from the seed. Furthermore, for the type of wallet you are using, Bitcoin Core uses exclusively hardened derivation, so the vulnerability you are referring to does not apply.

Additionally, it sounds like your wallet is in a state that should not occur. The wallet encryption for Bitcoin Core was specifically written to avoid having both encrypted and unencrypted data in the wallet. If encryption fails, it's supposed to crash which should force the database to revert to its previous state with nothing encrypted. It may be that you are looking at only the database file and not also with the database journal which can contain additional data (although it's supposed to be that the journal contains the encrypted data and the db only what is committed, and if it crashed, then the data was not committed).

However if you are looking at the database with it's journal, then you might also be looking at it in the uncommitted state and unencrypted keys are not actually deleted, just hidden as they are marked for deletion, but not yet actually deleted.