Since it run for hours, look for hardware or software issues specially the GPU and its driver.
You're basically straining the GPU's processes for hours so hardware issues that's not occurring at idle may show symptoms.
If it's Vanitysearch, you should get errors right off the bat.

Is there any additional command line options that you've added?

Do you have any successful login authorization in the past and the related "Authorize log In" email?

Because you can try to ask your ISP to set the specified IP address in the email in order to skip Blockchain's login authorization process.
Of course, use the same browser that you've used in that session.

Electrum doesn't have a central server for wallets, the server that you see in the network menu is for finding transactions and verification purposes,
the wallet files are saved in your PC's disk, usually in: electrum.readthedocs.io/en/latest/faq.html#where-is-my-wallet-file-located
That said, there's no way for others to set a password in your wallet remotely unless your PC itself can be controlled remotely/physically.

It's not the first time I've heard from newbies of Electrum wallet suddenly asking for a password but there's never been a bug in Electrum that does that.
Most of the time, it's a user who got confused, failed to remember what really happened, not telling the whole truth.

Please provide as much info as described in this sticky topic: [READ BEFORE POSTING] Tech Support Help Request Format

For now, try to look for other possible wallet files.
There's a chance that your old Electrum wallet is a "Portable Version" which uses a different data directory which saves the wallet files in its own wallets dir.
It's usually the "wallets" folder inside "electrum_data" folder inside the same directory where electrum-portable executable is located.

If that's the case, TX2's input (TX1's change) is not enough to fill both transaction's total fee plus 1sat/vB rate of the replacement txn.

Electrum's default rbf behavior is: "decrease change, or add new inputs, or decrease any outputs" in particular order.
Replacing TX1 will invalidate TX2 anyways so it'll use TX2's input for additional fee.

Most of those who have advanced understanding of Bitcoin or blockchain must have said it because of the famous phrase: "there're no addresses in the blockchain".
In the background, sending to the same address is just the same as other transactions.

I think the confusion is brought by treating Bitcoin like a bank account,
that's the reason why I've linked a beginners guide in my previous reply for OP to understand that it doesn't work that way.

Follow this guide to circumvent that bug (or smf forum limitation?): /index.php?topic=5395275.msg59916092#msg59916092
There are a couple of workaround but I believe this method has cleaner result.

There shouldn't be any issue by doing that.
In the background, you're spending an "Unspent Transaction Output" (UTXO) which will be used as an input of the transaction
and with it, create new UTXO(s) which will be the output(s) of the transaction.

Basically, the input is a script the you've unlocked to spend coins and the output is a script that locks coins from that input;
it's only shown as address in your wallet, so...

TL;DR: When sending bitcoins, you're not actually sending to addresses.

---

There's more info about Bitcoin txns here:

• learnmeabitcoin.com/beginners/transactions
• https://learnmeabitcoin.com/technical/input
• https://learnmeabitcoin.com/technical/output

If you're using Desktop, the child will suddenly vanish from your history and nodes will remove it from their mempool since its input(s) are now missing.
If the recipient of TX2 is also Electrum, it will appear as a "local transaction" instead of "unconfirmed parent", broadcasting it will just return with "input missing or spent error".

I haven't tested it in Mobile Electrum but based from the info in the OP, it seems like it's the same as Bitcoin Core where you wont be able to replace the txn if it has a child txn.
Interesting, I though both Android and Desktop versions work the same way.

[A2] It depends on the client, for example in Bitcoin Core: you wont be able to replace the parent if it already has a child saved in your mempool or wallet.
In other clients, like Electrum: it's possible to replace the parent but by doing so, it will invalidate the children txns.

[A1] Yes

There can't be a reliable tracker since each node can experience a specific reorg while others don't.
The nodes that didn't receive the orphaned block(s) don't have to reorg since they have the valid block(s).

In other words, a "tracker" may say that there's a reorg in xx date while others say there's none.

If you have a Bitcoin Core node, you can use getchaintips command to see if you've reorgs.
"active" height is the current tip, "valid-fork" is when it performed a reorg, while others are likely reorgs.

If you're willing to enable UPnP in your router and in Bitcoin Core's setting or bitcoin.conf file, it should do the trick.
(What are the security implications of enabling UPnP in my home router?)

Different router models have different settings so you'll have to find it yourself, try Google search: UPnP <router model>.
You can enable UPnP in Bitcoin Core's GUI in "Settings->Options->Network->Map port using UPnP" or add a line upnp=1 in your bitcoin.conf file.

I bet that there'll be lot of pause and resume that'll happen...
Please remember when shutting-down your computer, make sure that Bitcoin Core is fully closed before doing so.
Means that it should finish displaying the small "Bitcoin Core is shutting down" screen; also do not force-close it if your PC found-out that it's still running in the background.

Also, Bitcoin Core's GUI may appear frozen during the initial block download but don't worry since it's still running in the background.
If you need to shutdown the PC while it's not responding, do not force-close it; wait for it to respond (which it will after a few minutes) to do the normal closing process.

That's because just one abrupt shutdown could halt your progress that require a time-consuming "repair" process.

This thread is essentially "solved" after a few replies starting Page10 (here's the link | then OP's reply)
The paper wallet he found is nothing but a scam and it's one of the hundreds of thousands paper wallets scattered near OP's vicinity.

Yes, but that size difference is too low to even consider "save on fees" in regards to the selection of deposit option in Binance.
Unlike using SegWit as an input.

You can refer to this topic if you're going to include all address types to your deposit options since native SegWit address (bc1) is not documented in the library or their dev guide page (dev guide):

• bitcointalk.org/index.php?topic=5431352.msg61498631#msg61498631
  
  

Reading it will save you time later.

Take note that by using "BTC(SegWit)" Deposit option in Binance, you wont save any transaction fee on your deposit.
It's them (Binance) who'll save on fees when consolidating those deposits. (you'll save fee if you're using SegWit input [sender], not the output [receiver])

---

The only use of those two options "BEP20" & "BEP2" is if you're depositing from another exchange using those "Networks".
In the background, they'll send "non-Bitcoin Tokens" on the selected network (Binance Smart Chain or BNB Beacon Chain) which has same value as Bitcoin when deposited.
It only has value inside of those Exhange when credited to your Bitcoin balance
so do not keep them outside of the Exhange as much as possible if you somehow decided to select those when you withdraw (seriously, don't)

The initial reason those are added is to save fees and time, but given that Bitcoin's optimal fee is small most of the time, those are quite obsolete.

This must be a typo, yes?
Because FinderOuter will just fail the search after exhausting all the permutations.

The fan port is the 2pins at the side, not the USB port labeled with "D", that's the "power-only" Port D.
For reference:

(image from Amazon)

It has non-solid capacitors, the top will appear bloated if it's busted.
You might also need to get your PSU checked since it could be the issue why the ports are getting broken one by one.

Unfortunately, that has nothing to do with the private key's invalidity.
It's all about the script type of the transaction of which the P2PK may have incompatibility with some wallets like Electrum.
The private key should work, still valid today, the issue would be failing to sync (find) the transactions if the outputs are P2PK. (Bitcoin Core will work just fine)

P2PKH on the other hand are the common "legacy" transactions that we see today, there shouldn't be any issue syncing those.

Is the "some node" your node or other's node?
Because if the latter, it's no different than checking using a blockexplorer since you'll still have to trust the owner of that node.
If privacy is the concern, you'll have to setup your own node and use it as the server if you'll not use Bitcoin Core's wallet.