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.

Just for the record, a paper wallet rarely has a QRCode of a URL on it
since it's basically a 'cold-storage' wallet, linking a website for "whatever the reason is" doesn't makes sense.
Even the print-format of paper wallets from online paper wallet generators do not contain URLs (do not use them online though).

Usually, it's just the private key, and then the public key or the address.

Ah, so it's all about the (accessible) price.
Well, I kinda expected that since I too can't decode any message from "00101010", still worth to ask though.

Questions:

• How is that value chosen?
• Is there a hidden message related to "Saving NVIDIA" behind the binary 00101010? If so what is it?

BTW, you failed to mention the coming POS transition of Ethereum (not that I'm agreeing to most of the given reasons).
You might want to add that 

Interesting, but it looks pretty random to me.
Perhaps it's the nature of hexadecimal that made you think that it's patterned.

What I mean is it's limited to only 16 characters, thus, you're constantly seeing the same characters thinking that it's some sort of a pattern.

pycoin's ku P: command's passphrase isn't used to generate a single private key but a BIP32 root key.
It's indicated in their "command-line tools article": COMMAND-LINE-TOOLS.md
But the detailed method isn't disclosed.

While (as another user has said), 1LEH8BEZgC4onZ4GLm8UpZ3vXGAr6LYKST is just a "brainwallet" which is the address generated from SHA256(foo) when used as prvKey.

Aside from individual private keys (above), can also import the "master private key" to import the whole wallet while keeping the HD feature.
For that, you'll need to create a blank "descriptor wallet" and import a descriptor made from your backup phrase's master private key.

Here are the steps:

• Follow Husna QA's instructions up to the point when you paste your backup phrase to iancoleman's BIP39 tool.
• But instead of going through the private keys, copy the "BIP32 Root Key" instead, should start with "xprv".
• Generate a Parent Descriptor using that master key by following this format:

  For your wallet with legacy Bitcoin Addresses: "pkh(xprv...........nFG3cCzejXfUUzMWehii19K/44'/0'/0'/0/*)"

  For your wallet with SegWit Bitcoin Addresses: "wpkh(xprv...........nFG3cCzejXfUUzMWehii19K/84'/0'/0'/0/*)"

• Open Bitcoin Core and create a new wallet and tick the options "Descriptor Wallet" and "Blank Wallet", the other option should be unchecked.
• Open the console (Window->Console) and use the command "getdescriptorinfo" followed by the descriptor that you created, take note of the "checksum" among the results.
• Now select the correct wallet in the drop-down menu above the console and import the descriptor using this format (example):

  importdescriptors "[{\"desc\": \"pkh(xprv8ZgxM...your descriptor..Wehii19K/44'/0'/0'/0/*)#checksum\",\"timestamp\": \"0\",\"active\": true,\"internal\": false,\"range\": [0,999]}]"

  (your descriptor starts from pkh and ends before the checksum)
  (replace the "#checksum" with the checksum from the result of getdescriptorwallet)
  
  
• Wait for it to finish the rescan and your funds should appear.
  
  

Note: Since this will only import a descriptor for receiving addresses, your wallet won't be able to create transactions if it needs a change.
To fix that, you should import a descriptor for change addresses or manually indicate a change address when sending bitcoins.
It's also recommended to use a blank wallet since this will deactivate the current active parent descriptor (but will not delete/replace) if imported to an existing descriptor wallet.

Lastly: Just like what's been suggested by others, it's still best to just send the funds to your Bitcoin Core wallet .

Changing the username will still link the previous posts to the new name since the "User ID" (u=0000000) wont change.

Probably a deleted account and the user's posts were turned into guest posts.
This is probably the explanation on the Anonymous "edited by davidonpda" post: https://bitcointalk.org/index.php?topic=67541.msg789906#msg789906
The user in the quote's link requested to change his posts to appear to be posted by an 'Anonymous' guest. (the OP of that thread didn't, just 'delete account')