Why is it strange? How do you even know that the "half of the password" is actually correct? Are you assuming that because the "half of the password" worked on some of your other wallets (for ltc/doge etc), that it must also be "half of the password" to your btc wallet?

Unfortunately, you have not way of knowing this is true until you actually find the correct passphrase for the wallet.dat.

It is entirely possible that the "half of the password" that you believe to be correct, is in fact completely wrong... which would explain why btcrecover is not able to recover the complete passphrase, as if you've given it an incorrect starting point, then btcrecover will never be able to find the passphrase.

That is to say... if the passphrase is: password123
and you believe that the passphrase starts: "abc", then there is literally 0% chance that btcrecover would be able to get end up finding "password123"

Then the only logical explanation is that you haven't changed the correct file...

So, either you're editing the wrong file in your local git repo... or some process is overwriting/reverting your change during the build process... I would be inclined to think that it's the former.

How did you get the source? Did you download a .tar.gz or did you clone the repo using git?

Did you create your own genesis block? or are you still using the Bitcoin Core one? If you're still using the 2009 block from Bitcoin Core, then perhaps having effectively 12 years between blocks is not be helping...

are you using the latest version of PyWallet? (that has been updated recently by jackjack) or are you using the old version?

Also, where is your wallet.dat actually located? The --datadir value you are using is where Python should be installed to... not where your wallet.dat is likely to be located unless you manually copied it there.

Be aware that the mempool min fee is currently at like 2.5 sats/vbyte... https://statoshi.info/d/000000020/memory-pool?orgId=1

Any transactions with a fee lower than this is likely to be purged by most nodes. This will make it difficult for your transactions to remain in the mempool of the miners to actually be picked up and included in a block as they are both below this limit.

You should be able to search drives in a USB enclosure... as long as it is visible as a "device" to the operating system, you can specify it using the -recov_device option.

Nice to see the implementation of the BIPs...


I can't believe I missed this! <facepalm> 

I'll have to check that out later today when I have a bit more time.


Awesome... that is excellent news! As I said, I'll have a bit of an experiment and report back (hopefully later today).

That transaction fee looks like it should have been OK... that was effectively 103 sats/vByte... and for the past week, transaction fees have been at or below that level for the vast majority of the time... there is no reason that a valid transaction with that fee should not have confirmed.

Did you actually check the transaction on a block explorer like blockchain.com, blockcypher.com, btc.com, blockstream.com etc?

Given that your Bitcoin Core is not synced, you would not be able to see whether or not the transaction was confirmed anyway... so it would show as unconfirmed until your node finished syncing.


If you do not have any time constraints on your transaction (ie. you're not trying to pay a vendor), then I would recommend you simply set the node to "pruned" mode (See below)... and then let it sync fully... once syncing is complete, try and resend your transaction.


It is generally better to make sure your node is fully synced before attempting to send transactions. This ensures that the wallet is properly updated and the funds that you are attempting to spend are actually available.


For "Pruned" mode... "Settings -> Options -> Main"... the 2nd tickbox will allow you to turn pruning mode on and specify the max size to prune to.

It certainly looks like Base64 with the +'s and /'s... but it's possible that it is encrypted text/data that has been Base64 encoded... And, obviously, without knowing the details of the encryption method used, if you Base64 decode it, you're just going to get the encrypted data which will look like gibberish

It sounds like make is not detecting the changes you have made and is simply re-using the cached components... you might need to try doing something like a make clean etc to get it to clear everything out.

Unfortunately, that is likely to result in a very long compilation time as it will have to recompile the entire project again... and not just the changes.


Note: I'm not overly familiar with the structure of the Bitcoin Core make setup... so it's possible there are other make targets that you could use

So you added the VPS IP address to your home node using addnode? If so, have you also tried using addnode on the VPS to add your home node IP?

I concur... theoretically, it *should* be possible with the "descriptor" wallet functionality... but because Bitcoin Core uses hardened key derivation all the way down to the address level, you can't simply use the master private key that you can extract from the wallet.

Additionally, while trying to use importmulti on an "empty" descriptor wallet using an xpub (to create a watching only wallet that automatically generates addresses so you don't have to manually import them), I kept getting "command not supported by this wallet type" errors

I'm sure I was probably doing something wrong... but setting up online/offline airgap with Bitcoin Core is a very manual and labour intensive task... I would not recommend it.

Do the 3 blocks all start with the characters "U2F"?

If not, do the 3 blocks all start with the same couple of characters... and if so, what are those characters?

Given you're using an "older" version of Bitcoin QT/Core... it's possible that you would need to do the old "abandontransaction" + rescan method to get the funds to show... otherwise, the unconfirmed transaction is likely to just remain in your wallet forever, even though it has effectively disappeared from the rest of the network.


Correct.


As ranochigo and LoyceV have both mentioned... the upgrade process should be relatively easy... Bitcoin "Core" is essentially just the new name for what you know as Bitcoin QT... the .exe is still actually called "bitcoin-qt.exe"

So, the newer version will simply use the existing data directory with the blocks and wallet.dat etc. It should be as simple as downloading and installing the new version and starting it up and it should just work.


Again, just make sure to make a backup (or two) of your wallet.dat and you'll be fine.

Is from one of the "recovered" wallets using the PyWallet "recover" functionality?

In any case, that wallet file is essentially an empty wallet with no private keys (empty as in it doesn't have any keys, not empty as in "zero balance")... the "mkey" record that you can see, is the "random" master key used to encrypt the wallet data.

This master key is generated at random and encrypted using the chosen wallet passphrase. Usually, when you "unlock" your wallet, what you're actually doing is unlocking this master key and then that is used to decrypt your actual private keys.

Unfortunately, you can see that the "keys" array is actually empty... meaning that PyWallet has not been able to find any private key data in your wallet.dat


It would seem that PyWallet has not actually been able to locate any private key data during the scan/recovery... and has simply created an empty wallet.dat, encrypted with your chosen passphrase (hence the "mkey" record)

That would depend on what you mean by "weird word docx"? Is it just a collection of private keys or something?

Sounds like you might have downloaded one of the "fake" Electrum versions that steals your coins... The likely reason for it crashing when the "correct" password was entered would be that the wallet file have become corrupted or the "fake" version was trying to prevent you from seeing that your coins had been stolen...

Given that it works with a fresh install, I'd suspect that it's more than likely that the "fake" version was the source of your issues

All of this is rather moot at this point... given that the evidence found by hosseiminr93 would indicate that your coins were indeed "stolen". At this point, there really isn't anything you can do to recover those coins

Did you try my proposed solution above on 20.04?

Granted, I haven't fully set it up with a fully synced node etc, but Armory was running on 20.04 after manually installing the dependencies and it was scanning the limited number of blocks that had been downloaded etc...

You can't have two dobet() functions... you can only have one.

You'll have to adjust your script so that the 2 "strategies" are implemented in one dobet() function... something like this:

the "currentstrat" flag tracks whether we're currently on strategy 1, or strategy 2... so that we know whether or not we need to resetseed() and resetstats() when we switch from one strat to the other...

NOTE: I have not tested this code... not even a basic syntax check! - I take no responsibility if you choose to try and run this script

Is that laptop running Ubuntu 20.04 or did you downgrade back to Ubuntu 18.04?