Aside from Blackhatcoiner's reply, it's also useful in case you imported a fake key and successfully verified a fake electrum with a signature of it.
If you've certified only the real keys, the real Electrum will show that it has "valid signatures" instead of what you've seen "the data could not be verified".

I haven't mentioned but, before certifying a certificate, it's very important to look for some legitimate source where you can verify the fingerprint.
For example: ThomasV's certificate that I've imported has a fingerprint 6694 D8DE 7BE8 EE56 31BE D950 2BD5 824B 7F94 70E6 which is
the same as the one in the official documentary: https://electrum.readthedocs.io/en/latest/gpg-check.html and from various users' replies.
But better if you can verify it from the person himself: https://github.com/ecdsa

It's successfully verified; However, you haven't certified neither of the three keys.

To certify the keys: Open Kleopatra, right-click on Thomas Voegtlin's key, select "certify", tick all three checkboxes and the one below "I have verified the fingerprint".
Then click next and finish the rest of the steps. Do this to the other two keys.

Adding quotation marks to "change address" yields related results, specially these:

• https://www.reddit.com/r/ledgerwallet/comments/ho5spn/update_missing_funds_after_sending_btc_funds_sent/ (solved)
• https://github.com/LedgerHQ/ledger-live-mobile/issues/993

However, it's more of a client issue (Ledger Live) than the hardware wallet itself, fund is safe all along.

The Windows binaries don't rely on an installed python in the Operating System, it should work without installing python; instead, they bundled python dll files in the binaries themselves.

However as stated in the Release Notes, it's now incompatible with Windows7.

I think because descriptor wallets store descriptors instead of private keys, so it has a keypool of 1000 descriptors for each address type,
while with private keys, all three address types can be derived from it.

You can test it by using the config: keypool=100n (some value higher than the default);
then you'll see that the result of getwalletinfo for a descriptor wallet has three time the keypoolsize of what you've set.

For the size, it's partly because the database used for descriptor wallet "SQLite" is lighter than legacy wallets' "Berkeley DB".
But mostly because the newly created wallet only stores the "parent descriptors" for each script type which are very small is size compared to storing individual private keys.

No, they aren't the same.

Come to think of it: If (2), the "block reward" is only the sum of (1) the transactions' "fees",
then there will be no new coins produced in mining and (2) will be a false statement.

To support hosseinimr93's reply:
This is the original transaction that had the 0.007BTC output the sender spent on your "not-received" transaction: 2781fa06820f9307291602e409a9276342d48a0dea6d7bbe344ba0b779f7316c
It's replaced by 824fc21240b279e6638b1fc6a7c8090dd201180efcd535cf9752dd7a716e3ade so, your transaction (its child transaction) is invalidated as well.

There's no reason to increase the fee at that time because 1.35sat/B is good enough to be mined in the next block so it must be a scam.
But it wouldn't hurt to ask him if he used "increase fee" or "RBF" to bump the fee because that invalidated the txn he sent to you.

Important note: you must not finish a deal until the transaction has at least 1confirmation.

Tip: a solid indication that the wallet file's version will be upgraded is if the new version of Electrum wont launch your wallet right after you open it.
Instead, first, it will show you the "Install Wizard" - Choose wallet window:

Pressing "Next" will upgrade the wallet file.

Sometimes, this happens when you tried to install the updated version while the older version is still running that'll make the next session use the outdated version.
If that's the case, then just reinstall 4.2 and this time, close every running Electrum instance.

Otherwise, you may still be using the shortcut to the older version as mentioned by others.

Pretty much yes.

But in most cases, it wont even save you fees.
Since it's generally an "RBF transaction", the replacement (combined transaction) requires an additional fee equivalent to the fee of the to-be-replaced transaction(s), it also needs to pay for its own fee.

Example (testnet - SegWit):

• 1st transaction (rbf: true)
  Size: 144 vBytes | fee: 144 satoshi (@1sat/vB)
  
• Combined transaction (if you send while the setting is enabled and the 1st txn is still unconfirmed)
  Size: 178 vBytes | fee: 322 satoshi = 178 satoshi (@1sat/vB) + 144 satoshi equal to the absolute fee of the replaced transaction
  
• Based form the example, it's actually a bit cheaper if the two transactions are sent separately: each will pay 144 satoshi @1sat/vB.

This setting is good for the network though since the overall transaction size is lower than two separate transactions.
Means that you can help the network to save some block space.

It will work as long as the command prompt is still open until the timeout runs out.

Also, the command should be using bitcoin-cli since bitcoind doesn't support wallet RPC commands.

Yes, you're correct, there's no way to reverse it aside from bruteforce.

But there's only about 600million song titles out there,
just make a database of all the songs titles, create a simple code to perform SHA1 to each of the titles (and probably variations of them) and a typical computer can bruteforce it within a few minutes/hours.
Then you can get 1 merit 

If unsure, just keep the default settings as it's set to maximize privacy while keeping the best features enabled;
With that "Batch RBF transactions" is disabled by default.

You don't have to delete your post once it got answered, users in the web who are looking for support may be able to use it for reference.

It's to flag your transactions as "replaceable" but only until it's mined, useful in cases where you need to increase the fee by replacing it with a higher fee transaction or if you've sent it to the wrong address.
If it's enabled, "increase fee" and "cancel transaction" right-click options in the history tab will be available for txns created after it's enabled.

The downsides that I can think of are: some services that doesn't support RBF may not credit your deposits if you've used RBF to increase the fee;
and some exchange/casino with zero-confirmation deposits wont grant that feature to transactions with RBF flag.

One satoshi is equal to 0.00000001 BTC; so "at most" 100sat is currently about 4 cents (USD).

Is Bitcoin Core installed in a non-standard directory?
If so, you should specify where it is installed in "File->Settings...->Bitcoin Install Dir" and make sure the checkbox above it is ticked.

You may have to move armory's dbdir as well because the database will use more than that available disk space.

Refer to the "pathing" link above for the guide on how to set the dbdir.
I'd recommend the config files because the setting in the GUI is quite buggy when setting Armory's dbdir.

Posting the logs may speed things-up, it's in your Armory data directory named armorylog.txt.
There's no information in your post that can tell the actual issue.

If you want to move out those funds from Armory, you can just export the private key of the funded address and import it to another wallet.
If you're interested, you can check this post: https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691

But please be careful with the private key(s) because anyone who got their hands on it will be able to spend your funds.

Since you've said that the "descramble example" worked which is using a command with that arg.
Then it's okay because it wont look for the "common derivation path" if bip39-path arg is specified.

Have you tried "System File Checker tool" already?
It's a built-in tool in Windows that uses 'Windows Update' to fix/replace corrupted system files, you don't have to download anything with your browser.

Specifically, this command: Enter it in your elevated cmd: right-click "Start" and select "Command Prompt (Admin)".
Or refer to the link in my previous post for the usage and other info.

@littleinsect2018
This link is worth mentioning here since we're doing Bitcoin Core Cold-storage set-up wrong (or at least outdated)
I confirmed that it works without exporting the blockchain to the offline machine: /index.php?topic=5390009.msg59557548#

No problem,
Thanks for the link too, I missed the \"watchonly\": true, argument that can make a proper watching-only wallet.
What I've been using in my test is the console and various commands to manually make a PSBT that'll be imported to the offline machine.

---

Anyways, since we're at it, I'd like to add a step to that tutorial to include the change (internal) addresses so you wont have to manually add a change address in every transaction that needs change.

To get the "parent descriptor" for the change addresses, use the command listdescriptors.
The one for the change addresses has "internal": true," result | also pick the script type of your choice.
Then import it the same way you've imported the receiving addresses' parent descriptor.