It has an entry on Scamadviser: scamadviser.com/check-website/bitwemix.com
Read the user reviews, one of them reported that he can't withdraw his funds without depositing some amount for "insurance" and "premium" (classic scam)
If it's asking you to deposit, just don't; legit exchange wont ask for more funds or expenses just to withdraw.

Also reported as "phishing" on by Kapersky AV via VirusTotal: virustotal - results

BTW, this should be in Service Discussion.

If that's a pattern, P63's last 8bits should also be twice of the first few bytes of P64... and P62's to P63's.. and so on.
But don't take my word on it since I haven't checked all of the puzzle's private keys, just the last few  ;D

Check them all and see if there's a matching pattern.

That's quite an old miner, AFAIK ethminer 0.19.0 is from 2019.
That said, most of these Ethereum miners can only work up to a certain epoch, there's a high chance that that specific version can only work up to the 515th.

For example (can be related), the old Claymore ETH miner has this in the official thread:

That said, you may need to switch to an updated miner.

Salvage will likely return with the same error message since the wallet file's header may be corrupted.

Anyways, to correctly use the command, you should use these commands with your Command Prompt or Powershell (prepend with ./ for powershell),
Change directory to bitcoin/daemon (change the dir if Bitcoin Core is installed to another dir):
Provide the path to the wallet.dat file and the salvage command (without the "-"):

---

Since you already set-up pywallet, using -recover is worth the try.
It should be able to find if there are recoverable keys from your wallet.dat file.
Follow this guide for the commands:
In your case, just move the corrupted wallet.dat to the root of your other drive, then use its drive letter as the --recov_device,
then fill out the --recov_size which is the drive's size and --recov_outputdir where you want to put the recovered wallet.

It can also be an issue with your Bitcoin Core's "address manager".

Try to add addrman to the debug log by starting Bitcoin Core with -debug=addrman command line argument.
And see if it outputs a related error.

It's different from a wallet's "master public key" (xpub).
The exposed public key from a transaction input is just a child of the xpub key (if it's from an HD wallet)
A child key can't be used to retrieve its parent key, because deriving the child from the parent involves a cryptographic hash function which is irreversible.

It's has many zeroes because the creator of the puzzle deliberately selected private keys of small range so that users can have a chance to solve most of the outputs through brute-force.
Even if it's just small portion, it's still a valid private key and within the valid range which is:
from 0000000000000000000000000000000000000000000000000000000000000001
to     FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

I don't get the motive of asking why it starts with "F";
but anyways, since it's in Hexadecimal, it could start with any characters from 0~9,A~F. It just happened to be the one picked or randomly selected the the creator of the puzzle.

I've tested it an it seem to work as advertised, at least in CPU mode.

My test includes searching for a prefix similar to the puzzle transaction's 2nd address: 1CUNEB from full prvKey range.

The result is: it's consistently finding the key 0x03 in mere split second since it searched from 01 onward, not random.
If it is random, it could take a while to find another key for an address starting with 1CUNEB since it could gone for the the middle or end part of the search space.
But since it's consistently finding 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb, I'd say that it's linear.

Also tried 19EEC5 multiple times and it's also consistent at finding 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT (prvKey 0x47B069).

Lastly, I tried specifying the range and it properly used the indicated --keyspace.
Test command used:

./vanbitcrackens1.1 -t 3 --keyspace 1300000000000000:13FFFFFFFFFFFFFF -o 1vanbitcreacken-output.txt -stop 1AVJKw

Result: Found 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB which is within that range.

Basically, running Bitcoin Core through the app is the issue?
If so, you should find a way to start "bitcoind" which is in the "daemon" folder where bitcoin-qt is located.
Then you can now use RPC.

Based from the link in the post above:
Looks like they forgot to monitor if the transaction and its parents are RBF flagged.
Because that's one of the major factor to consider to be able to tell if the seller has a capability to easily double-spend the transaction.

@Fivestar4everMVP you can take that in consideration when deciding if the transaction is "good".
In blockexplorers, it's usually displayed as "replaceable", "rbf enabled" or similar.

Have you copied it to the correct directory that I've pointed-out in my reply?
Namely: .bitcoin/wallets ; either paste 'backup.dat' inside or create a 'backup' folder there, paste 'backup.dat' file inside it and rename it into 'wallet.dat'.

Because if you did, there shouldn't be any error when you used the said commands.

Either put 'backup.dat' inside .bitcoin/wallets dir or
Create a 'backup' folder inside .bitcoin/wallets dir, paste your 'backup.dat' file there and rename it into 'wallet.dat'.

Then load it using loadwallet backup.dat for the former or loadwallet backup for the latter.

Probably not since they're with Wasabi, they might impose the same regulation that censors some UTXO.

For more info about that topic, refer to these threads:

• The default Wasabi Wallet coordinator will start censoring "illegal" UTXOs
• Wasabi blacklisting update - open letter / 24 questions discussion thread

This thread is going to be political later on so I'll just leave this link here to answer that specific question.
These are the people behind "bitcoin" organization account in GitHub: https://github.com/orgs/bitcoin/people

In Bitcoin, the data that can spend your coins isn't the address but its "private key" which usually in the care of the user.

An Exchange and Electrum work differently.
In Exchanges, the private keys of the users addresses are in the Exchange's custody.
In Electrum, the private keys are stored locally in the wallet so the data that you need to spend is exclusively in that wallet even if it's offline.
By creating a watching-only Electrum wallet, you're basically only copying the addresses to the online PC; it can't spend, only "watch".

Take note that the above is an oversimplification for you to understand,
technically, there's a "master key" stored in each of those wallets which can reproduce all of those two wallet's addresses.
A "master private key" in the cold-storage and "master public key" in the watching-only wallet.

Send a few satoshi to the watching-only wallet and successfully spend it by following the tutorial in the first reply, that's the assurance that you need.
If you want, you can click 'save' right after signing the transaction in the cold-storage to update the displayed balance but that wont improve anything.

Last time I tried, it can recover private keys from a deleted wallet.dat file, it can recover the keys regardless of the wallet.dat's name.
but in my recent tests (just yesterday after my previous post) it failed to do so; IDK, maybe because the wallet.dat was just saved in my test drive's cache.

Anyways, you should try another tool, specially the one suggested by others above.

I cannot find any reference on the code pointing to that specific error aside from the full message in my previous post which is benign.

Did it asked for the to-be-created "recovered-walelt.dat"?
Did it asked for possible passphrases after that?
if so, pywallet did its job and didn't found anything from the --recov_device.

For reference, it'll output something like this if it found nothing:

Otherwise, it'll output something like this is it found possible wallets and/or keys but with '0' result:

Does it look like the former?
or the latter where it shows possible wallets/keys but output's nothing to the recovered wallet.dat?

Because for the former, it means that there's no wallet.dat found in the disk.
For the latter, it's either the passphrase is incorrect or you've provided a passphrase for unencrypted keys.

Do you have Bitcoin Core installed?
Because it's required by Armory.

If so, is it fully synced and not set to prune the blockchain?
Because the full blockchain is required by Armory to build its database. And also, Bitcoin Core's latest version has prune settings enabled by default.

For better solutions, it's best if you can provide the full/related logs from 'armorylog.txt' in Armory's data directory.

The complete message should be "WARNING:root:pycrypto or libssl not found, decryption may be slow".
It should still work but slower, did it end with another error?

But I see that you're recovering from C: drive which is the system drive and also set a folder in that drive as the output folder of pywallet.
That not recommended since the data that you want to recover may get overwritten by pywallet's output itself or your OS's page files, not to mention the files that you've downloaded/written to the disk.

There's a quite old but extensive tutorial about signing messages, here: How to sign a message?!
If your wallet isn't covered by the guide, try to find a button/menu that resembles the "sign message" features shown in the tutorial. Most non-custodial wallets have it.