That's the same link OP mentioned in the first post and it didn't worked, he said it returned with "invalid checksum".

Thanks but that's already covered by the previous posts (that I've merited) plus I'm talking about reducing the time-frame for a "replay attacker" to do his job.

Quite off-topic answer: As long as you're sending to your own wallet and it's non-custodial, you don't have to worry that much about 'replay attack'.
But that attack can still damage you if the "replayed" transaction's output isn't standardized by the other chain, making it hard to spend, non-spendable or anyone-can-spend depending on the script;
so try to use the address type that's supported by most of those forks.

Or course the faster you can send the 'forked coins' to a new address after the first transaction (from any chain), the lower the risk.
Send/Sweep them to their respective wallets as fast as you can.

He's currently offline, but I believe the command with that result is getmempoolinfo.

Let's try common terms:
The negative balance that you're seeing is just displayed beside your current balance because it's "pending".
Once it got "processed", it will be deducted from your current balance.

But it comes with a fee so, it may be higher than what you've input in the send tab, it depends on the 'fee rate' that you've selected in the slider and the size of the transaction (not amount).
To check the details, go to the history and double-click (under the date column) the unconfirmed transaction with "red" amount.

Try variations while following post number 2.
Because the "custom word(s)" can be the 13th, 14th, 15th to 16th words.

So in Electrum, you should only paste 12 in the "enter seed", tick both boxes in the "Options", and if it says "BIP39 (checksum: ok)", proceed and click "next".
If false it's not a 'BIP39 seed', uncheck BIP39 and see if "next" is clickable, if not, it's not an 'Electrum seed',
If 12 didn't work, try variations like different number of words (first 3,6,9,15) with 'BIP39' ticked.

In the next window, paste the 'rest' of the words, 'two' or 'last' of them; then finish creating the wallet and see if your address shows up in the address tab ("View->Show Addresses" to display), if you don't know an address from your wallet, wait for a few minutes to sync.

Based from an example in the pull request's comments (bitcoin/pull/15935), it should take some settings from the bitcoin.conf file but in json format.
I don't know if all or which settings will work though.

I've tried some,
example1 (disables wallet function):example2 (produces legacy addresses in the receive tab):

The problem is: despite the very high fee rate of those two transactions, their parent transactions are both unconfirmed with very low fee rate.
So miners are considering them as "bundle" parent and child transactions, and the fee rate will be based from their total size and fee.

Your transaction: 6cdb98f9c86ef7902ee991d44e013307662086322dc41ee392584daac8b12d11 with 100.1 sat/vB fee rate has two inputs which are both unconfirmed, namely:
1. 0ba52bed104cea1075754f783867d423ae9510bd4d6fb3f3905aaf7e1862fd9d @ 7.0 sat/vB.
2. fe682ab28ecdb3bc82498af0c7730e2fcb0cf8563c6fc88cc2367c16aa3624a0 @ 10.0 sat/vB.

Both the transaction's sizes are too large and the fee rate too low for the child transaction to accelerate them effectively.
let's say that there are no unconfirmed transaction in the parents' inputs (I didn't checked because there are hundreds of them),
the total size of the batch would be: 699 vB + 27904 vB + 16106 vB = 44,709 vB
then the total fee would be: 70,000 sat + 195,860 sat + 161,530 = 427,390 sat fee; that's a total of 9.56sat/vB fee rate[/b].
Currently, 9-10sat/B is @ 20vMB from tip of mempools.

The other transaction may be missing from time to time because the parent's input parent's fee rate range is beyond the default maximum size of mempools.

Philipma did a benchmark using a similar specs in a thread somewhere in Bitcoin Technical Support board and he thought that the bottleneck is his (200mbps) internet since he's using an SSD and latest hardware.

Here's the link: Re: Faster sync would be nice (i.e. soooo slow)
Summary: with the latest specs and fast internet speed, he's able to sync Bitcoin Core in just 6hours, garyf22's internet may be slower but his specs should be similar.
What he didn't accounted is the download speed will also be based from his peers.

Increase your "database cache" to a reasonable amount like half of your RAM as long as the capacity isn't used by other programs, default is too low.
The option is just below 'pruning', then restart Bitcoin core.

It will be slower when you reach 70-90%.

From the looks of it, OP is confused of lightning and he thought that mainnet and lightning funds can be sent though either network.

Let's say that you already have an open channel and you go to the send tab:
If you paste a Bitcoin address there, Electrum will send a normal transaction and spend your on-chain funds.
If you paste a lightning payment invoice there, Electrum will initialize a lightning payment.

It depends on what you've pasted; bitcoin addresses, on-chain payment invoice (eg. from payment processors) and lightning invoice (long string that should start with 'ln') are very very different from each other, you do not have to worry about losing funds.

And read Abdussamad's reply.

P.S.: it's "SegWit" not "WetSig" (sounds kinky)  

Are you sure about the year?
Bitcoin was just released that year and it's hard to imagine that a service that gives some sort of "verification code" existed.

You might need to search for a private key that your dad might have exported from Bitcoin core through a third-party program.
That should look like a string of HEX Characters (0-9, A-F) consisting of 64characters; if newer that you expected, 51 BASE58 characters that starts with '5'; or much recent, starts with 'L' or 'K'.
Also look for a file named "wallet.dat".

One the side note: with all those "lol", it's hard to take this seriously.

The "verification code" part is not promising, because if it's from 2009, then he must have used the official client which doesn't have a verification code.

Σ( ￣□￣||)

Note: Bitcoin Core won't download the "remainder", it will sync from start all over again.
Also, you need to close it and run again after unchecking the box to disable pruning.

That's it, so Electrum will automatically disable the feature when RBF is available, that's a well-thought feature.
Must be because it's not efficient to allow the sender to create another transaction to accelerate the one that can be RBF~ed.
I haven't tested that factor, thanks.

Anyways, the CPFP will only able to send to his own wallet, being able to use 'coin control' will allow him to use the coin for his next payments/transactions instead of sending back to himself.

In terms of dollars equivalent, yes for now.

For some reason, it wont appear in the "sender" Electrum even if one of the outputs belongs to that wallet, tested in testnet Electrum v4.0.9.
So if it doesn't appear at his end, he must use coin control.

Okay, since the two transaction after the stuck one were already confirmed, then it's change must have been left unspent by the wallet, those didn't affected the stuck transaction at all.
Because if its change was used, the transaction that spent it must be mined together in a single block (at the same time).

In the "coin control" step, you must select the change of the stuck transaction because if the wrong coin was spent, it won't be considered as CPFP.
To check the change, find the 'stuck' transaction in the history tab and take note of the details specially the txid and the address which will be displayed as "output point" and "address" in the 'Coins' tab.

I know it's solved without explanations but for safety purposes:
Next time, you must not directly open a backup of the file because Electrum will try to upgrade it and if corruption occurs, you'll lose your digital backup.
It's best to copy the file and use that copy instead.

Please reconsider this reply by hugeblack from your previous thread:

No, it's as explained by the first two replies.

It's best if you can at least try what's been suggested;
there's also a chance that it will get a confirmation during this weekend since there seems be a downtrend in the average mempool size, but please don't expect it.

Lastly, if you find it hard to understand the replies, you can post in your local language instead,
here in the local boards: Local Boards, if your language isn't in the list, select "Other languages/locations".

Do you have a way to contact the receiver?
Because the only way to accelerate this is for him to perform CPFP to the output;

If you can not contact the receiver and you want the nodes to drop it after approximately two week since last broadcast, just do not "re-broadcast" it using push or (fake) accelerator services so it won't linger longer than 14days in the network.
Also, some nodes must have already dropped your transaction due to limited mempool size but reacquired it from the nodes that kept it, that might've extended the days before it get fully dropped.

Lastly, depending on the wallet, creating a new transaction after it was dropped can be easy or hard (like requiring some commands, etc.)