The first address is generated from the uncompressed public key pair of that private key.
The next address is from the compressed public key.

More info here: learnmeabitcoin.com/technical/public-key

Probably because it's designed to bruteforce the "puzzle transaction" (link), and the puzzle's addresses aren't p2sh nor bech32.

Additional fees would just go straight to the miners, extra output for their hidden fee will stick out like a sore thumb as Charles-Tim mentioned.
Plus it wouldn't be practical since small amounts can be troublesome to consolidate.

You're probably thinking of "custodial wallets" which is similar to what OP already pointed out.

The quoted part is called "descriptor", the "db373be9" is just the master fingerprint and not too important.
It's probably because those wallets don't support descriptors and/or Taproot and somehow imported the xpub, but I don't have a Trezor to confirm it.

You can try Sparrow wallet which supports hardware wallets and descriptors. (from Bitcoin.org wallet list)
Things you can try:

• When creating the wallet, select "Legacy" script type but edit the Descriptor to match the xpub of your trezor's Taproot account.
• Or create another wallet, select Taproot but leave the descriptor intact.

Blockchain.com will ask for "email authorization" for new devices/IP even if he didn't set-up 2fa.

But that comes after the wallet ID and password; and before the 2fa code (if 2fa is enabled).
Don't know why he's having trouble with the authorization email while not being able to remember his password.

I've tried it and it worked without an error at my end.

Command used (RegTest):

The only way that error would show is if you set the "locktime" to 4294967294 (which is about 100 years in the future) instead of the sequence.
Compare your command with mine to see the possible issue.

I can't comment on the sequence's inconsistency in createrawtransaction command and GUI. (you may consider opening a new issue for that)

Bitcoin Core doesn't support HD MultiSig wallet so it'll be tricky to backup multiple MultiSig addresses.
No GUI option or menu for MultiSig as well, you'll have to operate using commands.

Yes, Electrum can restore from BIP39 seed phrase and BIP39 passphrase, just enable the options "BIP39 seed" and "Extend this seed with custom words" when importing the seed phrases(s).
Next to that, type the BIP39 passphrase when prompted for the "seed extension".
After that, you'll have to select the correct script type and then edit the derivation path if it's different from the default for P2SH-SegWit MultiSig - m/48'/0'/0'/1'.
But yours is probably more than just m/49 since it's usually the extended master key at BIP38 derivation path's 'script type' level (check your wallet for the correct path).

Wait, you were able to receive BTC through your just-created channel in Electrum?

That will only be an issue if your channel isn't trampoline; you'll see a blue highlight under "can send" row, means that it's frozen.
But as seen in the screenshot, it's connected to a trampoline node (indicated by the kangaroo icon) so there shouldn't be any issue when sending funds.

The only inconsistency I found is the part that I've mentioned (you probably remembered it wrong)

I had a similar (answered) question in this thread where we discussed a similar setup: https://bitcointalk.org/index.php?topic=5414023.msg61052365#msg61052365
You can also read my reply next to it for additional info.

...
Since each node has their own mempool, the replacement transaction for a transaction (without rbf flag) will be broadcasted to the nodes that enabled full rbf and wont be broadcasted to those who don't.
So if all nodes support it, it definitely can reach a pool or solo miner that supports full-rbf, then "Use Replace-By-Fee" setting wont be necessary.

But from the current stand-point, it may take years to reach a consensus.

It mainly depends on the setting: "Tools->Preferences->Transactions->Use Replace-By-Fee".
If it's disabled, the option "cancel (double-spend)" wont show up in the unconfirmed transaction's right-click menu.

On a side note, that behavior might change depending on the Electrum servers and bitcoin node users' decision on "Full RBF" which is already available in the latest version of Bitcoin Core.
If most Bitcoin Core nodes enable the option mempoolfullrbf=1 (which is disable by default), the Electrum setting above wont be necessary.

He's aiming for the "Multiple server" option in the tutorial that removes the "-1" arg which will enable Electrum to connect to other nodes (servers).
Manual selection in the GUI is basically the same as that since there's no checkbox or menu that will enable "oneserver".
Notice that in the 'Network' settings, there are "Connected nodes" below, that's what the 'multiple servers' is about.

But as mentioned, even if connecting exclusively to onion servers is implemented, it'll not improve his privacy even further.

Additionally, using oneserver while connecting to other people's server is not as secure as using the multiple servers option.

There was a PR attempt in GitHub that wasn't merged: https://github.com/spesmilo/electrum/pull/2191
Click the link to the issue (#2160) to see the discussion.

Some Devs argued that connecting exclusively to onion servers wont provide you extra privacy, the selected main onion server is good enough.
There's no explanation but maybe it's because your Electrum client will only sync with the server that you've selected, the "Connected nodes" are only for verification purposes.

Take note that addresses in his "Sending addresses" list will also be included in the command's results.
Don't know why they implemented it like that though.

Just load it to a fresh Bitcoin Core install and let it sync, it will check for the balance even if the wallet is password protected.
I'd recommend v24.0 (github.com/bitcoin/bitcoin/releases/tag/v24.0) for this since loading the wallet is as easy as using the menu "File->Restore Wallet...".

I think it's because it's stated in the proposal.
BIP-0173 strongly suggests to encode Bech32 address as uppercase in QR Codes: github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32

A command line option to generate lowercase would be great.

Setting it to uppercase will further increase the incompatibility of the QR Code.
There's a discussion about that in Bitcoin Core's GUI repo GitHub: https://github.com/bitcoin-core/gui/issues/145

I managed to make gpg4win work with openpgp keyserver by reading this article: www.stephenwagner.com/2021/09/30/sophos-dst-root-ca-x3-expiration-problems-fix/
And this tutorial on how to install certificates to Windows10/7: techglimpse.com/dst-root-ca-x3-expired-certificate-error

Apparently, it is because openpgp's certificate also relies on the expired (on Sept 2021) "DST Root CA X3" certificate which older versions of Windows 10/8/7 still use.
(I downloaded the der certificates from letsencrypt instead of the provided links, also needed a restart)

But since using other servers should work, just use that "easy method" instead.

There should be something more to this than just a pdf file wiping out your Electrum.
There is no reported vulnerability in Electrum that's directly linked with pdf files.

If you need advice, please provide more info on what happened.

But in the end, that confirmed bitcoin transaction cannot be reversed by anyone.

If that's the case, then "26 phrase" is better, or better yet 27 words~  :P

Anyways,
Linking the seed phrase's number of words or wallet's security to scam is unreasonable, people get scammed even if they are using hardware wallets.
Scammers are fooling victims into sending them funds willingly, so the issue isn't the wallet's security.

He didn't answer Little Mouse's question as well:
Nor reply to Husna QA's mention of the uncensored part of the image:

My guess is: The QR Code is censored so that user wont accidentally scan it, and the URI part of the invoice is censored so users wont be able to click it (but it's an image :P).

First, make sure that the private key that you've imported is the key of the address that you're trying to import:
In Mycelium, click on the "Accounts" tab and select your "Bitcoin SA" account that was created when you imported the prvKey.
Then go to "Balance" tab to see the address (click the QR Code to switch to the other address types).

- If one of the address is the same as the one with balance, then it's a simple server issue in Mycelium.
To rescan: go back to the "Accounts" tab and select your "Bitcoin SA" account, then click the menu (three dots) and select "Reload Account".
Wait for a few minutes until the loading animation stops.

- If none of the addresses is correct, then you might have a different private key.

You can still use the archived version of Electrum Dash (link),
import the private keys(s) to a new wallet using the option "Import Dash Addresses or Private Keys" instead of 'standard wallet'.

There are still online servers to connect to but I can't guarantee their legitimacy so if you ever got an error message when attempting to send funds, just do not follow it.
If ever, "export" the signed raw transaction instead and broadcast it using a push/broadcast service like (blockchair.com/broadcast?chain=dash)