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.

Shouldn't it be Electrum since it acts as the lightning node, not the server?

If that's the case, this might be the one you're looking for: https://electrum.readthedocs.io/en/latest/merchant.html#lightning-payments.

Okay, so that's the issue in the "Lightning Network Walktrough" thread is all about.

Unfortunately, I haven't found a way to open channels between two Electrum wallets either.
I have tried adding the "IP Address" but it always results with "Timeout" or "Cancelled Error".

You can try it: instead of using just the nodeid, follow it with an '@' sign then the PC/ISP's IP address like for example:
0369c4ddc6076646ddf30ad58c4beca8eee399557063f69a17xxxxxxxxxxxxxxxxx@17x.1xx.2x.4x
Both Electrum wallets should be active.

Because, you'll have to pay a fee that might take a portion of it to spend that balance because you'll end up with lots of very small inputs.
Transaction fee will be based from the fee rate (which you'll set in the wallet) and the transaction's virtual size which will get higher if it has a lot of inputs.
1sat/B is still good enough to consolidate them though.

Custodial wallets will just send from their hot wallet when you want to withdraw (minus their fee which can be cheaper for low-priority).
Personally, I'll use a custodial wallet for that amount.

LN is a very good choice however won't let you receive 'savings' from your 'clients' unless you have enough inbound capacity.
And you don't have enough funds to open a channel of 0.002 BTC then use submarine swap or spend some satoshi.
You need to find a way to increase your inbound capacity like mentioned in the previous sentence.

I don't get it.
But everything you can do with mainnet, you can do the same with testnet.

No, LN is only available for [standard] Native SegWit Electrum wallets.
Read the thread I linked above to learn more about the usage of Electrum's LN feature: Electrum Lightning Network walkthrough

Testnet funds have no value and in a separate blockchain than Bitcoin's and the testnet wallets will be saved in a different directory.
You can easily get funds using testnet faucets: List of Testnet BTC Faucet

0.002 plus the fees to open a channel.
Then use "reverse swap" to get some of the funds you don't need back to onchain, but that process comes with a fee of 0.0002+ BTC.

Or launch Electrum with -testnet argument to use testnet's chain for testing purposes.

0.002BTC being "good enough" is my personal opinion like I said above.
Other wallets however, will let you open a channel with lower amount IIRC maybe Electrum devs would reduce this in the future.
I can't recommend others though since I'm not using them.

BTW, long-term saving with that amount though LN is a no go, I suggest custodian wallets for amounts like 0.00069376 a year.
Reason is, you can't receive at all if you don't have inbound capacity, read this thread for more info: Electrum Lightning Network walkthrough: Receiving a payment

That error was due to your attempted open channel's fund is lower than 0.000547BTC.
You'll get a different error if it's lower than Electrum's minimum which is Exception('funding_sat too low: xxxx < 200000')

Unfortunately, there's no settings to override it.

I prefer it that way, because if the channel's funds is too low, users will end up opening channels more often if they need to send more funds.
If it's 0.002, they will only need that channel to transact LN funds given that the remote node has enough connections.

Plus, you can get your Bitcoins back to onchain funds and get inbound capacity though "submarine swap" feature which is very convenient to use in the GIU.

It looks like the same error as this:
electrum.lnutil.ConnStringFormatError: Don't know any addresses for node: ******
I got that when I tried to open a channel between two Electrum wallets.

That's probably because Electrum's channels are private.