Download and install the latest version 0.96.5 and try again.

You can download the binaries from the link in the sticky thread: Armory 0.96.5
or from goatpig's signature (below that linked thread's page).

Have you already tried to send it to your other wallets in the list like "My Bitcoin Wallet"?
If you didn't, then use the "Send" window and select "BTC Trading Wallet" in the drop down menu under "From";
Select "My Bitcoin Wallet" under "To", fill the other details and click "Continue", then finish the last few steps/clicks.

That will enable you to send to external Bitcoin addresses.

Sure there is!
Even wallet files from very old versions like v1.8.1 will open with the latest version 4.0.2.
The problem is when you want to do vice versa, eg.: 1.8.1 can't open upgraded (opened by later versions) wallet files.

Make sure to follow bob's suggestion to create a standard wallet to replace your current wallet.

Yes, the parent and child must be included is the same block if the child has higher fee than the parent.
Since the child has a high fee but can't be mined without the parent, miners will take the parent in consideration when prioritizing the transaction(s).

Miners will compute the total fee-rate based from the total paid fee and size of the parent & children.
Worth reading: Wiki: Miner fees - CPFP

Yes, it will show when your wallet is watch-only or for 2FA wallets when you click 'cancel' in the 2FA code window instead of 'ok'.
It's pretty easy to reproduce it since it'll only take a minute to create test wallets.

Maybe because they want to make it as simple as possible for non-advanced users.

Run it using a different command, like vanitysearch -o output.txt 1a.
If it consumes all of your CPU resource, then it's not "that issue".

I think the problem is the way you want to use vanitysearch, it's not meant for creating bulk random addresses IMO.
I'm pretty sure that there are other tools that can do that bulk address generation better (I don't have one however).

You have the same issue as this guy: Issue #70
And one of v1.18's release note was "Updated to CUDAv11", maybe it has something to do with your drivers.

There's a thread here that contains most of the info you need to setup Lightning in Electrum:
Electrum Lightning Network walkthrough by BitCryptex. Read it carefully before trying to open a channel.
If anything, you can also read the previous post and see if a problem that you'll likely encounter was already solved.

The UI of mobile and desktop are totally different but you just need to find the right buttons, they are named in a similar way.

The Disclaimer when choosing "wallet with 2-factor authentication" may be a little bit vague about the fee (not to mention the small font):

But as you can see, it's disclosed there.
There's also an info about preferences (underlined) about how'd you want to pay for the 2FA service, but it didn't specified where to find it (lower-right 'blue shield' icon).

That will only show if "Advanced preview" in the preferences is on or he clicked "advanced" in the 'simple preview' after clicking "send".
And it's disabled by default.

The simple preview only consist of fee rate slider, 'send', 'cancel' & 'advance' button; after that, the 2FA code text box and an 'Ok' & 'Cancel' button.

Okay, I've ran some tests and noticed that:
My antivirus is acting up whenever I'm using vanitysearch, it's not detecting anything but consuming a lot of resources.
Much higher than what Vanitysearch is using; so I've included it to my AV's "exceptions list".
And it worked!

Somehow, vanitysearch isn't using all of the cores or even processing power when using that command, there should be something wrong.

Whatever the reason is, I've tried to use 1 thread and it resulted with a slightly slower rate (just about -10%).
So, try to run 3-4 instances of Vanitysearch running with the same command but pointing to different output files.

Creating batch files is a good shortcut to do this, eg.:
instance1.bat
instance2.bat
instance3.bat
...And so forth

Each instance will be slower than a solo instance but overall number of generated addresses and keys could be higher.

Don't know but your previous speed doesn't sound right for an old i3 CPU from 2012 (third-gen maybe) when searching for '1*'.
You'll likely get 1000-2000 per update of "Found" at best (based from my PC w/ i3-4130 procie).

Other than the additional -c which is unnecessary for a wildcard prefix, I can't find any issues with the command you're using.
If you previously used an older version with faster result, then downgrade to that.

The weird thing is, your processor can search for Million keys per second, while it can only "no-prefix-search" random address & key pair @ thousands per second.
Perhaps it's not meant for that use-case.

Mine has no problem with synchronization.

Seems like you've been being disconnected from your selected server again and again, try to connect to other servers.
If you're using your own and it's outdated, upgrade to the latest version (probably related: Electrum 4.0.2 keeps Synchronizing)

BTW, that was off-topic... and the number below that's being updated is the total number of addresses in your wallet + new UTXOs.

The extra output is indeed looks like TrustedCoin's fee.
To confirm that it was, double-click on the transaction in the history (on the date) and check the outputs.
Some should be highlighted with color, the green/yellow ones are yours, blue is the 2FA fee.

That payment is for that tx your next 19 txs.
Trusted coin - Electrum help page: https://api.trustedcoin.com/#/electrum-help

If it's not a hardware issue, my guess is: Vanityseach might be struggling to write on that output file due to its current size.

Have you been using the same 'output.txt' file since the start?
If yes, try to use a new text file like "-o output2.txt" and see if it will speed-up.

Is your node running?
If no, you need to run it together with the mining software.

What are you using, the GUI or CLI?
If it's the GUI, you might need to add server=1 to your config file to enable RPC outside of the GUI's console.
(that's based from Bitcoin Core's behavior)

If the node is in the same machine as the miner and the sample above doesn't work, try to use localhost and the port (your blockchain's), as the 'mining server'.

I don't know if it will work in the first place since I haven't successfully opened a channel between two Electrum wallets yet and AFAIK there's no related article/documentation to point you at.
So I can't walk you through that particular issue, sry.

For now, try to use the remapped address instead of your ISP's.

The "Key List" export should have the address together with its private key... but if you didn't saved them, just get them individually from Armory.
View HCP's post's 2nd image, the "Wallet Properties", from there expand where the address belongs and double-click the address;
Click "View Address Keys" to get its private key.

To import it to Electrum, use p2wpkh-p2sh: as written in the 'info'.

Electrum will import the legacy address (P2PKH) derived from the private key by default.
If some of those addresses aren't legacy, you'll have to add a prefix when importing the keys to Electrum.

Using this format (will show when you click 'info'):


Probably because Armory is seeing the other output as change because it belongs to the wallet.
Electrum doesn't because the change address wasn't imported in that imported wallet.

If there's an option to increase the "auto-withdrawal amount" in that pool, tweak it to at least 0.0001-0.001BTC (or higher) per withdrawal.
AFAIK most pool have that option.

That way, each UTXO will have enough balance for a "normal transaction".

The issue was reported by someone months ago but the devs never replied: Issue: 6370
For CoinGecko's API's response to history rates, it seems to be working when I test it, other sources won't work for Electrum either.
So, the "source" might not be the culprit.

There's nothing else you can do but to wait for the developers to respond to the issue.