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.)

It should return "true" even if the inputs aren't included in a block.
It's probably because the parent is currently "not in memory pool", using sendrawtransaction to the parent before attempting to use testmempoolaccept to the child should work.

Not too low but it's only 20satoshi short to reach exactly 10sat/B for Viabtc's free accelerator, that's unfortunate.

Doing a CPFP will do.
If one of the two outputs is your change, all you have to do is to spend it with a relatively higher fee than the recommended.
Problem is your client, blockchain.com doesn't have "coin control" to be able to select inputs.

If you don't have other unspent transaction outputs (inputs) in your blockchain wallet, any new outbound transaction will be considered as CPFP because it will guarantee that the change of the "stuck txn" will be spent.

Alternatively, if your have other inputs, you can import the wallet's "recovery phrase" to Electrum and spend that transaction's change using these tutorials:

• Restore the backup phrase: https://bitcoinelectrum.com/restoring-your-standard-wallet-from-seed (read note on step4)
• Use Coin control: https://bitcoinelectrum.com/how-to-spend-specific-utxos-in-electrum/

Please be careful with the recovery phrase, read the warnings. Compromising it will lead to loss of funds.

That's technically not possible but since Blue wallet's lightning is custodial, funding the channel is as easy as depositing the change to your "lightning external refill address".

Electrum however doesn't work that way, you'll have to fund your channel(s) through lightning transaction from a third-party that accepts on-chain funds.
It has the "swap" feature but it wont accept small amounts like the typical change and it comes with a (third-party) fee.

In comparison, sending to the same address also "mix" or rather "link" those addresses, blue wallet's lightning refill address doesn't change AFAIK.

Yes, it's made for Regtest because it doesn't retarget in regtest (source), but doesn't necessarily mean that it won't work in testnet or even mainnet.
Your test probably reached the maximum 1million tries since (yes) testnet's difficulty is still too much for a CPU to handle, you GPU won't be used by that command.
You can add "maxtries" to generatetoaddress to increase the number of tries before it give up but you need to be extremely lucky to mine a block in testnet using your MAC's CPU.

I'll leave #2 to anyone who mines in testnet and uses cgminer for CPU/GPU mining.

It's easy if you have the encrypted wallet file and its password. Just paste it in Armory's data directory, example location: https://btcarmory.com/docs/pathing#example
Then start Armory, it will "mirror" the wallet if it has no ".imdb" & .imdb-lock files.

To get the private keys, just proceed to "Export Key List" backup option, it'll work even if Armory is offline.
HCP has a detailed tutorial: Re: is it possible to import Armory wallet into any other wallet?

The way your account got hacked, it looks like a compromised backup phrase. Reason is, anyone who've got their hands on it can just restore it to any wallet that supports BIP39 seed, there's no need to login to their web wallet.

Why is that URL mentioned?
Have you pasted your 'backup phrase' to that site?

You must have heard about "Quantum Supremacy" which will make old unspent P2PK outputs vulnerable.
That includes both old and new reused addresses which have their public key exposed.

But the rumor is more of an FUD since it's still decades before Quantum computers can become a threat, don't sweat it.

Go to "receive" section, tick "Generate native segwit (Bech32) address", lastly hit "Create new receiving address".
It will generate bc1 address even if the wallet is from old version (tested wallet.dat from v0.11.1) or isn't HD.

Fascinating, based from the address' history, it tends to send small amounts from time to time but with change that sends the rest back to itself.
Someone must have messed up coin control or the manually generated txn

It's not about the typical ridiculous fee due to the "congestion" simply because it's impossible to reach that fee with "wrong estimation" for a '1in-1out txn'.
The transaction was obviously created without a change (by accident or with reason) so all of the excess amount were considered as "mining fee".

Okay, now some details connect with each other.

It might be a "local transaction" with low fee rate which was probably rejected by the current server you're connected to;
check if the logo (on the left of the txn) looks like a 'blue computer' instead of 'green check' or 'gears'.
It looks like this:

The one in the image is a "local transaction" which can be deleted using right-click menu, "Remove".
After being removed, you can spend the coins it's trying to spend (read 'till the end before deciding to remove it if yours is a local txn).

The risk here is your transaction could proceed even though it was previously dropped by most mempools, because if mempools' size suddenly became lower, they may re-acquire it from the nodes that kept your txn.
To counter that, you must use at least one input of that specific transaction to ensure that it wont proceed.

To check the transaction's input, double-click the local transaction in the history tab, take note of the input's details (screenshot or copy), then proceed to remove the local transaction,
Now open "Coins" tab (View->Show Coins), and "Right-click->Spend" to the coins that has the same detail as your removed local transaction (CTRL+left click to multi-select before using right-click),
then proceed to the send tab and create a new transaction. Send it to yourself (same as cancel transaction) or to a new payment.
What you want to achieve is to invalidate the previous unconfirmed transaction for the canceled CoinPayments transaction invoice.

May be a "pathing" issue and you're both using a non-default Bitcoin datadir, read this: btcarmory.com/docs/pathing#config-files and point satoshi-datadir to your Bitcoin core's data directory.
Example: satoshi-datadir="E:\AppData\Bitcoin"

If you click "max" after pasting an address in the send tab, is the amount getting auto-filled?
If "0" and you have positive balance, then it must be what ranochigo said, you must have frozen an address or coin.
To check that, open "Addresses" tab ('View->Show Addresses' to enable the tab) and "Coins" tab  (View->Show Coins), look for entries with blue highlight.
Frozen coins will have the highlight under "Output point", not the address.

To unfreeze them, use "right-click->Unfreeze Coin/Address".

That may be an issue if he changed the settings in both PC,
Electrum will default with "spend only confirmed coin" disabled, that will enable new users to spend unconfirmed UTXO.
@Jeffro64 if you've ticked that particular setting and the coin is unconfirmed, disable it to be able to send now.

One important note: Bitcoin transactions can't be cancelled by the recipient.
What they cancelled must be the invoice for the service that you're paying for, so if you haven't done anything and your transaction's fee is "good", then it will proceed if it's still unconfirmed.

Also, check the history tab for transactions related to that service if it's still unconfirmed (with gears icon), make sure that Electrum is online.
If it is unconfirmed, try to use "right-click->cancel transaction" to send it back to yourself, that's if you didn't disabled "use Replace-by-fee".

Might be an issue after the devfee session?
If increasing the page filed didn't worked, try to add --coin eth to your bat file after the algo.

You're also using memory tweak mode, so t-rex.exe should be set to launch as administrator.

You're not sure about that, since your wallet is standard, your wallet must have used "change address" and that won't be restored in a 'watch-only imported' wallet made using the receiving address.
One of your transactions' output must be your change.

Most likely, unless you have set a "passphrase" aka. "extension", "custom word" or "13th word", whatever they call it.

That looks like your previous transaction in your other thread because it was 1-3 days (depending on what's edited) since your last post: /index.php?topic=5311792.msg56374153
and the number of confirmations is just about right.

So if that transaction went through, then you must have already swept the bitcoins.

Note: Their tutorials all explained the "Advanced Preview", but normally and by default in v4.0.9 (or lower?),
it'll just show the standard send dialogue box after pasting the keys, so you must have used it instead and sent the transaction unknowingly.