Alternatively, you can use importdescriptors to a descriptor wallet.
If the address is from Bitcoin Core, use getaddressinfo to get the address' descriptor and import it to your watching only wallet.
If from other wallets, construct a descriptor based from the address' pubKey and script type.

e.g. (RegTest):
getaddressinfo bcrt1q45ylq9spcg0q5aqzjcfu9ndxqawj28trxylq85
Import to MyWatchWallet (prvKey disabled):

Mostly just to view your address, not your private key or seed phrase.
It's as simple as giving the site permission to view your address for them to be able to see your balance, txn history and use that as your receiving address.

But it may have different permissions per site, for example Pancake Swap has this permission when connected to Metamask:
(the most common permission)

Use "Detect Existing Account" instead of selecting a script type when importing the seed phrase (12-words) to Electrum.
If it shows two or more results, you'll have to restore each as separate wallets to restore all of your blockchain(dot)com bitcoins.
(repeat the process for the next wallet)

That's because Electrum only supports one derivation path per wallet (but includes the change path).

Also, bitcoins in your "Trading Account" isn't covered by your backup phrase.
You can't restore it to Electrum.

If you still want to use the Pi, at least try to redownload/clone then recompile/reinstall Bitcoin Core to rule-out (slight) corruption issue since such specific file error can be caused by faulty code.
But of course, moving to the laptop is a good choice.

Also, 2000MiB of database cache is too much for an RPi3 model B which might have caused additional strain to your HDD though 'swap files'.
In your next setup, set it in consideration of your free RAM and OS; do not use 100% of your RAM.

That must be Window's notification when you receive/sent a transaction in Electrum (or similar if you're on other OS).

The malicious notification is actually just an additional error message that's sent by a malicious server after deliberately failing to send a transaction.
But in the "fixed versions" including v3.3.8, that was replaced by hard-coded messages which can't be altered by the selected server.

The other issue is: The whole scriptSig is used to compute the hash in the scriptPubKey: OP_HASH160 OP_PUSHBYTES_20 dccb70880a6a3667464f1de5e106d7ec1cf75e17 OP_EQUAL
While it should only be the RedeemScript which is the one you've labeled as scriptPubKey above; that made the output unlockable with your unlocking script.
You also forgot to include the redeemscript's size to the unlocking script, that's why verification failed.

By following the correct procedure, you'll get these values instead:

• scriptSig (include the Redeem Script): OP_PUSHDATA1 0100000000000000000000000000000000000000000000000000000000000000000000002ba3edf d7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b 7c
• Redeem Scipt: OP_HASH256 d751d5b58a9d143185a943cf85753ec3c0738bd4a1f27af94bac591033428036 OP_EQUAL
• scriptPubKey: OP_HASH160 21bc25ba80f04ab78a0c59711bb21fd399451901 OP_EQUAL = 2MvKbgKhpPS4ho3hF3zBVdcqoVS8y2Yrq28

Which can be unlocked using this unlocking script (from the values above plus the data's 'sizes'):

Raw transaction (transaction: e3b5eb2c7a687f94ab64e6f2b04c6c2eecd9a1db71bda5550ea34e127226fd3e):

---

-edit-
The issue is -> The other issue is

Not offline, just "local"; the encrypted private keys have to be decrypted for a few seconds to make an outgoing transaction (to sign it).
But since those are non-custodial, the keys aren't stored in their server, just your device (plus your backup)

Both wallets are closed-source so no one can be certain how they manage the private keys.
(the source code isn't public so no one can audit it if their claims are true)

But I think rat03gopoh's point is if you're considering to store your funds to Binance's exchange,
then at least use their non-custodial wallet so that you're the one who have access to your funds, not Binance.

The wallet file is the least of your concern as long as it's password protected (with a strong password).
What you might have stored/shared to a vulnerable environment are the seed phrase (12-words) or a backup - any of your private key, etc.

That said, are any of those stored online, cloud storage, on a device or paper that can easily be accessed?
If so, you should keep the seed phrase in a safe offline environment the next time you create an Electrum wallet. [e.g.: exclusively written on paper/steel plate in your vault(s)]

Since your initial setup is v3.3.8, you can rule-out the malicious server message to upgrade to a malware version.
The update notification that you received was most likely the in-app "update-check" notification, it'll open right after you launch Electrum, not after a transaction.

But you still can't rule out the possibility that you've downloaded the update from a fake source.
To mitigate that, you always have to verify Electrum before using/installing it to your PC.

Is that test wallet.dat file created by Bitcoin Core v23.0 while "descriptor wallet" is ticked?
Because if it's a descriptor wallet, there may be an incompatibility with the way how pywallet or other prvKey recovery tools search for deleted keys.

It's just a test anyway so, it's not a big issue,
but if you still want to try if pywallet --recover is working, create a non-descriptor wallet instead by unchecking all checkbox when creating a test wallet.dat file.

I doubt that their backend server is having issue after the merge since my ETH in Mycelium is showing just fine.
Have you updated the app to the latest version? Because the latest is released 2 days ago.

It's not a bad idea but usually not the best option in some cases.
Aside from SA accounts, your main BTC and ETH account are backed-up by the 12-word seed backup so it'll properly restore your accounts at least.
For the balance, it still depends on the underlying issue.

I don't think you get my point, I didn't even said that they should ignore it.

Question 2 is about the possibility of the exchange "duping" money, while the funds are most likely refunded back to her bank instead to the exchange.
Because I don't think sending millions to undisclosed affiliated persons' bank accounts which can be easily tracked by the authorities is a good idea to launder money.

Question 3 will not make sense if the refund was sent to her bank account since it's already out of the exchange.

Question 4, I don't get what's being asked in Question 4.

BTW, the reference should be in the OP since without it, your post may be considered as plagiarism.

Unlike in your other posts, you forgot to add the source this time.

The original article (google search) stated that it's for a refund and most likely talking about refunded fiat funds to her bank account so Q2~4 are implausible.
For Q1, it could be since refunds are usually done by hand so a typo can occur.

BTW, those google search results are the same article fetched from "IANS", they most likely have republishing rights (do you have?)

Like someone mentioned in your other thread, there's a permission issue.
Try to add -datadir=<full path to a folder> to your command to create Regtest's data directory somewhere else where you have the permission to write.

Take note that the specified directory should be existing prior on using the command,
also, the specified datadir= is the "bitcoin" datadir so instead there, a "regtest" folder will automatically be created inside it where the regtest files will be created.

Forget the seed phrase, all they need is your "master private key" which is derived from the "seed", and seed derived from the seed phrase.
From 'seed phrase->seed->master private key', there're already two irreversible hash functions to overcome.

Having all extended public keys from Bitcoin/Altcoin derivation paths isn't going to help since you essentially only have the public keys.
The extended public key is just a public key followed by a chain code, it's the pair of the private key part (1st 32bytes) of the extended private key with the same chain code.
As you know it, you cannot derive a private key from a public key.

Additionally, since it's brought up that it's possible if at least one child private key is exposed,
If you somehow exposed one example_coin extended public key and one example_coin child private key, then a hacker got his hands on your example_coin extended private key (xprv),
he still wont be able to derive the master private key from it since it passed through multiple child extended key derivations with different indexes per coin and derivation paths.

Given that someone has access to your extended private key at m/xx'/x'/x'/0
For the "hardened" child extended key (the numbers with ' ), it's impossible to get the parent.
For the normal child extended key (without ' ), to get the parent extended privKey, he needs the parent's extended pubKey but it's usually isn't available to the user.

Basically each of your extended key has gone through: master private key/purpose'/coin'/account'/internal or external e.g.:m/44'/0'/0'/0
Each / corresponds to a child extended key derivation which is irreversible.

How can you tell?
Was the height indicated in the latest "UpdateTip" lower than the other nodes/BlockExplorers?

it's a bug in clBitCrack: github.com/brichard19/BitCrack/issues/337

Someone shared a fix but you'll have to edit it yourself and compile the code.
Here's the post: github.com/brichard19/BitCrack/issues/223

Whoa, that's quite an old misconception. (I used to see/hear info related to it about 5 years ago)
Autorun.inf isn't a virus, some virus are just utilizing that file to automatically launch itself once the flash drive is plugged in.
But even if your device isn't infected, you'll likely see an autorun.inf file there as long as the owner plugged to a Windows PC and set Windows' autorun feature once.

My old flash drives (with installer files) have one and it was set to launch an installer (which I set to automatically launch):


More info in wikipedia: en.wikipedia.org/wiki/Autorun.inf

WanderingPhilospher already made a Vanitysearch/Bitcrack fork that can do exactly that: https://github.com/WanderingPhilosopher/VanBitCrakcenS/releases
The source code is only available in the 'releases' page.

It also has a command line argument --continue that'll save the position where you left off.

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.