Looks like you've copied the same address as your previous transaction about 1 hour before that transaction.
Luckily, it's easy to tell since crypto app has been reusing their address for batch withdrawals.

You must remember where you sent the 1st transaction then you'll have a clue on where the "lost transaction" was sent because they have the same address.

I second the post above but I think there's no issue on your side, the command is to load the specified wallet.
You got that error of Duplicate -wallet filename specified because that wallet was already loaded as you created it.

You should use loadwallet the second time you use Bitcoin core after your exit your current session.
And the quoted command is used when using RPC commands for a specific wallet after you've loaded it,
commands under "wallet RPC" wont work with a wallet that isn't loaded yet, you'll get an error instead:

Technically, an address is just a human-readable representation of a script (eg. scriptPubKey),
which can be 'spent from' by fulfilling the requirements of or solving that script.
Each transaction's output(s) creates a new UTXO (unspent transaction output) that's locked by that script and that's what's being spent, not some kind of balance for that address.

TL;DR: Let's say an address is a "padlock" (not the box that's being locked), its private key is the key for that padlock,
and the UTXO(s) that can be spent by your 'key' as the box which being locked by that padlock.
A padlock can be locked and unlocked as many times as you want. (not the best analogy since each UTXO requires different signatures)

I can't find any article that states "Bitcoin is Anonymous",
it's rather "Pseudoanonymous" which could mean it's anonymous in a way that you have the option to not link your identity to your addresses.

Aside from TryNinja's (correct) answer: that will only happen when you're using SegWit.
The reason why those explorers can't compute the same fee as Electrum does is because they're not taking the virtual size in consideration.
And SegWit transaction's "virtual size" is lower than its "size", so the fee per Byte will always be computed lower than fee per virtual Byte when it comes with SegWit.

But when it comes with prioritization, miners will take what you've set in Electrum because it's actually "sat/vByte" although it's displayed as "sat/byte".

I think I understand this, you're talking about what's being displayed in blockchain.com/some_blockexplorer when exploring an address, no?

To clear things up: Blockchain.com isn't associated with neither BTC and BCH Blockchains.
Two (or more) compatible coins will be displayed when you searched for an address if the address' format is/was supported by those particular coins.
In you case, you've pasted your bitcoin address which format is supported by both BTC and BCH chains, but Coinbase or most exchange doesn't work that way, they usually issue different deposit address(es) per coins.

So, it's what has been said by others.

Using the browser is unnecessary when it comes with getting the JSON object format.
He can use the console (Window->Console) and the command: decoderawtransaction "RAW_Transaction" but I doubt that he can make sense of those data or what to do next.

The best solution is to report this as a new issue and include the logs (minus the sensitive info) with the report.
You can enable it in: "Preferences->Write logs to file" (Restart Electrum).

After you reopened Electrum, reproduce the bug and then check the log file in: ~/.electrum/logs
There should be a hint at the last few lines.

Is your paper wallet encrypted like the posts in this topic?

If the private key (secret) starts with 'L', 'K' or '5', then you can straight-forward import it to Electrum using "Import bitcoin addresses or private keys" in create new wallet window; this will create an "Imported wallet". Or sweep it to your new wallet (must be opened) using the menu "Wallet->Private keys->Sweep", this will initialize a transaction that will transfer the paper wallet's balance to your new wallet.

There's a prefix for different address type, you can display it by clicking the "Info" box in the import/sweep keys window.

It could mean that your wallet.dat was corrupted or the parent transaction was suddenly became invalid.
But it's very improbable that previously confirmed transactions become invalid since they are safely stored in the Blockchain.

That could also happen if you're using a Bitcoin wallet.dat with a node/client for another cryptocurrency (or vice-versa).

What version of Bitcoin Core are you using?

It can be removed by right-clicking on it and selecting "Abandon transaction", that will remove it from your wallet.
But that's just a "band-aid solution" since the previous transactions are all invalid.

The RAW transaction from the oldest '?' transaction can shed a light to the issue.
You can get it by right-clicking it and selecting "Copy Raw Transaction", then paste the result here inside [code][/code] tags.
Note: Doing that will share your transaction's inputs and outputs, but that's basically the same as sharing a valid transaction ID that can be explored from a blockexplorer (not good for privacy).

Yes, I've already mentioned the example's redeem script in my first reply.
So it's:

• 21 = Size of the public key (Compressed)
• 03D144A172E24F499F9C59BDEED23FE625E814BBE815B1170A4EAFED7CBC970EAC = Compressed public key
• AC = (another 0xAC aside from the public key's last byte which happens to be 'ac') = OP_CHECKSIG

As NotATether said (minus the correction above), you can use Legacy ('1' address);
or native SegWit (bc1 address) that can easily be spent by importing the prvKey to a known wallet.
If safety is your concern, you can import it to an offline machine and spend using an online "watch-only" wallet.

Yup, it's based from the number of downloaded/verified blocks and the tip, not the size.

Is "first 80%" an approximate? Anyways, there are some reasons:

• Older blocks have less transactions in them, making the download size of each blocks low making it sync faster.
• Some blocks from genesis block to block height 453354 (refer to the edit) are being assumed as valid and won't require verifications that could speed-up the sync process.
• Etc.

.
Note: I checked the code and the latest indicates that the default is now: Block Height 654683 (link).
I don't know when (version) it was changed.
-Edit-
Found it, that was 28days ago (Pull Request link) and it was 623950 before that.

If you haven't touched the dbcache (database cache), you can increase it based from your available RAM (about half+).

First based from your info.
Then, I suspected that it's that type of address and constracted the p2sh-p2pk redeem script based from the compressed public key.
And it did derived the same address that concluded my initial guess.

You can use those commands with an offline Bitcoin core, just disconnect the internet and Core wont sync.
You just need to fetch the required info to create the transaction from other sources.
When the "RAW Transaction" is ready, you can broadcast it using any "push/broadcast txn service" online.

You can use the command getaddressinfo to get your address' scriptPubKey.
The example address in OP: scriptPubKey": "a914c470975e1d7b8311e554626cb7fab6076a50bd2287"
consist of:

• a9 = OP_HASH160
• 14 = Script Hash's size
• c470975e1d7b8311e554626cb7fab6076a50bd22 =  RIPEMD160[SHA256(Redeem Script)]
• 87 = OP_EQUAL

Here's an example usage of those command for P2SH scripts: /index.php?topic=5251740.msg54527358#msg54527358
As you can see, P2SH requires some extra args compared to other scripts when signing.

That's for P2SH-Multisig so in your case, you'll only need to sign once.

---

The Big Question is:
Is there a reason why you don't want to use others for your paper wallet?

There are some changes from 1.1 to 1.8 but the seed itself should be in the same format and Electrum has kept backward-compatibility when it comes with wallet file or seed phrase import.
Here's the release notes: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES (from v1.5.7 to the latest)

Before I posted my reply, I've already tested it with a newly created wallet by 1.8.1 and opened the "electrum.dat" using v4.0.5 and it opens without any error.
The addresses is the address tab are also the same.
But I can't launch electrum v1.1 from source for some reason.

When moving the wallet: Instead of importing the channel backup, just copy the wallet file itself to the other machine.
It's in Electrum's data directory (location)

But be warned that lightning transactions made by one copy will not reflect to the other that will cause the channel to be force-closed when launched by the outdated one.
So it's best to use an individual LN wallet in a single machine.
I think it's because the channel and the LN transactions are saved in the file itself and it must reflect the other party's copy (need clarification).

I'm not using bitcoin-bash-tools but I can tell that the address 3KbhF81wMizzyjJUKLMCBbscSj9puQyBbq is "P2SH-P2PK" which can only be spent
by providing its Redeem Script: 2103d144a172e24f499f9c59bdeed23fe625e814bbe815b1170a4eafed7cbc970eacac [PubKeySize PubKey OP_CHECKSIG]
(of course, along with the signature)

The only wallet that I know that uses such address is Armory but it'll only take uncompressed PrvKey and derive the P2PKH address for import.
So I think the only way to spend from it is to use Bitcoin core's RPC command createrawtransaction & signrawtransactionwithkey.
But there may be more options.

---

It's expected since the prefix used is p2wpkh-p2sh which isn't p2sh-p2pk, they are totally different.
Sadly Electrum doesn't support that address type.

It's safer if we say "1 virtual MB" or 1MvB max.
Because in 'MB', the size of a bitcoin block with witness data in disk can reach more than 1MB up to 4MB (can only fit up to 3+MB, in reality).

That's correct, you'll get an error message: Address not found in wallet (code -4) when using "getreceivedbyaddress" even with -txindex.
"listreceivedbyaddress" on the other hand, doesn't take an address argument.

---

The only alternative solution I can think of is to have your own expensive database like that of a blockexplorer.

Like I've said in my previous reply, it's the minimum and being "minimum" means that it's the lowest priority fee rate.

There are times that it's okay like if you do not want fast confirmations or the average mempool size is low,
but not right now if your transaction is a bit rush.

Refer to the post above for the alternative but I'd suggest to use the 3rd graph instead and look for the range that suits your transaction best.
Eg: Using that site, fee rate at range of <1MB has a good chance to get confirmed in the next block, >1mb for the next and so forth.
Note that the number of newly broadcast transactions and rate of mined blocks can increase/decrease that chance.

Without the latest blocks and some unconfirmed transactions in your mempool, the client can't estimate fee rate.
That's when your node isn't synced or you're not relaying unconfirmed transactions.

The only "60" that I can find is the "Confirmation time target" for your transaction to get a confirmation within 60minutes.
It'll be displayed when you click "Choose..." beside the transaction fee (it's already displayed in OP's case).
And that's part of the "fee estimation" and wont work unless it's initialized.

Alternatively, you can always use the other option "Custom". and set your desired fee rate.
The pre-loaded amount is the minimum 1sat/B or 1000sat/kB.