That's 5.49GB worth of cached data, I'd say 12 minutes to write it all in a 5400rpms disk is normal.

Looks like your dbcache is getting filled by the new UTXOs that your client is discovering, and when you close Core, it dumps it in the disk.

That was a lot of UTXO by the way.

Could be your Bank's routing number, it differs per bank. FAQ says that it should be editable in your 'Banking' tab.

BTW, this should be in the "Service Discussion" Board.

It doesn't look like an "approval" to me, I'll stand by what I've said: it's "bumping the news".

It's up to you to stick to a single server.
Me, I'm using any server as long as it's functional and leave it to Electrum's random server selection unless there's a vulnerability in the client's version.

Is there any reference where ThomasV endorsed Blockstream's server?

If it's the link to "Retweet" in the OP, then there's no direct endorsement happened,
it's much more of a bump or news of a new server using a new server implementation though (Esplora?).

Your English is fine, it's not as bad as mine  
The problem is you hadn't stated it clearly and didn't actually replied to the previous posts (but did after answering a question),
What I get is: you've mentioned about a BTC balance in a mining pool then proceeded to mention the wallet.
Then you didn't tell if you have the passphrase for the wallet (in the OP) but given a clue that you didn't in the previous reply.

BTW, it's what I've said in my previous reply.
You need to at least know a couple of possible passphrases or parts to bruteforce it.

Where did you found the address? In a txt file? You shouldn't rely on that.

Have you properly loaded your wallet.dat?
You need to paste it in the data directory\wallets while Bitcoin Core isn't running then it will issue a rescan at start.

I got a feeling that he's one of those "free-electricity guys" in the Altcoin mining section that I've seen before (About 8 of them).
I remember someone who said they are mining in the basement of something and controlling their rigs from home.

1750 kWh sounds enough for a 6-10 GPU Rig. Still, not enough to be called "mining farm".

Hmm, I'm confused with your last reply, is the issue now solved or not?

If it's still in the mining pool's internal wallet, they are the only one that can help you with this.
If it is in that wallet.dat and you have no idea of the possible passphrase, then a mining rig won't be able to bruteforce it unless it's short or common.
If you decided to build a mining rig, make sure that the GPUs are all 8GB so you can mine Ethereum with it at least.

Yeah, dropping Skyrim was a really bad choice  

If it's an 'imported' wallet created using "Import Bitcoin addresses or Private keys",
Electrum will always allow you to add more private keys to that wallet.

If it's another type of wallet, please verify your Electrum's signature to make sure that it's not a fake.

Honestly, you lost me at the last paragraph.

But if the issue is the history and the transactions and balance are somehow fetched correctly;
Check if you've set a "filter" before, a drop-down menu should be displayed above the history, select "All";
if there's none, then it's disabled. Use "Wallet->History->Filter" to re-enable it.

By the way, Coinjoin will be available in the next release  
Although it's not as intuitive as Wasabi's, in Electrum it will be a painstaking manual merging of transactions and distribution of partially signed merged transaction to the other parties.

Here's one testnet coinjoin transaction that I've tried: fe3dde593d428606aab307bc11a179fbfacb416176865d1f7d14276fc25ce597
(merged inputs and outputs from three different wallet types)

The problem with Virustotal is you need to download the file first and upload it to the site before it can scan the actual file; in which case, you can be infected by downloading the file.
Scanning the URL of the direct download link will only trigger a scan to that URL's source/connections, not the file to be downloaded.

Example: If you scan https://download.electrum.org/3.3.8/electrum-3.3.8.exe you'll 1 "Malicious" result by SophosAV.
But if download the actual file and upload it, you'll get six totally different results - for Electrum, bunch of false positives.

OP is talking about the actual P2PK transactions here, not the "donations" to the derived address, so am I.
Of course the owner of the private key can spend those donations using P2PKH script but not the UTXO from the P2PK transaction though that "address".

Additionally for naufragus:
Most clients (like Bitcoin Core) can still spend P2PK if the you have the private key since it is still standard,
but it's not a P2PKH script that can be represented as an address which is the point of the earlier replies.

The Windows version is quite old, but I doubt that it has something to do with the 'age' of your OS...

Ledger live only works with 64-Bit version of Windows10, 2004 version must have a 32-bit version.
Check your PC if it's 32 or 64 Bit in "Search->System Information".

If not, consider upgrading by enabling "Windows Update", Ledger Live 2.5.0 works in my not-so-updated Window10 PC (2015).
Or pair it with Electrum (electrum.org) instead.

What he meant is P2PK scripts are Pay-to-Public-Key (read it literally to understand  ).
You shouldn't derive the address based from that Public Key because the owner wont be able to spend it using the "P2PKH" script even if he has the private key.
Those are only common in the old blocks

New widely used scripts are P2PKH short for Pay-to-Public-Key-Hash which is RIPEMD160[SHA256(Public Key)],
that's where addresses work.

I have tried the script and edited what you mentioned BIP44 to BIP49 and it printed the same yrpv as the one generated by Electrum GUI.
Sample BIP39 seed: random arctic maze lazy chase cattle need rural census beauty green series
Result: yprvAJZLm5mo51QHF3SjP4LsmojahZfJ421Q11BvRVJ4mTdUb7eszhDkDexaq9QpZnzkvQMGd2exPBo f4NWQ9H6hfn35KdR9q71w66443XnuPuW

It also generated the same set of "3" addresses when used per his example:
Command: BIP39-BIP49.py random arctic maze lazy chase cattle need rural census beauty green series| python electrum-3.3.8/run_electrum -w wallet_test_delete_cli restore -
Console command - getmasterprivate(): same yprv as the above.

So Electrum should generate the same addresses if it's based from that master private key.

Here's what I've edited:
Just the 'comment' and the 'derivation path' and it worked.

The 'wallet file' will be created in the same folder as the script, perhaps you've opened a different wallet with a similar name.

Their homepage seems to be updated with the latest unconfirmed transactions and my address is showing just fine.
Do the URL when you type blockcypher comes with "/?before=620731" at the end? (= block height)
Because it will only show the transactions and balance before that height if it's added.

The only (not an) issue that I have with blockcypher is some of their nodes are accepting non-standard transactions.

Solving this will be a lot faster if you can tell the name of the shop where you sent your coins to.
There are a lot of scam accusation here and that shop might fall in the list.

Also, you might have been a victim of a clipboard hijacking virus/malware.
Try to copy an address again and see if it'll paste exactly the same (not just the few first and last characters).

Must be because chainstate folder was deleted not the corrupted block;
Once Bitcoin core reached that height, it exhibits the issue again.

BTW, I would like to rephrase this:
If the blk file is older, you also need to delete the blk files with higher number together with it.

@MrFreeDragon
What HCP explained should be the default behavior if the pool/miner uses Bitcoin Core v1.3.0 and above (source).

There must be something else that happened in your previous transactions like 'cleared mempool' due to faster blocks
or the "<1mb from tip" range is actually 3sat/B at that time.

If you're lucky, this might be the only block that's corrupted by the improper shutdown (height 633,921).
And that's not that old.

If -reindex didn't worked, you can delete the last 'blkxxxxx.dat' and 'revxxxxx.dat' files (highest number) in the "blocks" folder.
Start Core with -reindex again and it should rebuild the database and sync starting from the last block in your disk.

You might want to include some of the log containing the actual corrupted block file, something like: "blk02113.dat checksum mismatch"
so you can be sure what block file(s) to delete (if it's older, you need to delete the block files with higher number).

Tried with with 3.3.8 and it looks like this:
It'll only show if the user clicked "Send" directly, not when he used "Preview->Sign->Broadcast".


Sadly, I can't test it with 4.0 (unreleased version) because it won't let me change the fee to 1000sat/B manually without using "advanced" which will bring up the preview window.