Of course. It's quite widely known that Electrum is the absolute worst from the privacy aspect, and SPVs in general, with few exceptions. If you're relying on any server for any information, it is safe to assume that there can be some form of logging, be it through the IP or by collating the addresses.

Don't think it's wise to be using "Bitcointalk" as a branding (even if it's official or not); most of the servers are run by people that has been doing so for a long time. If you truly care about privacy and security, then run your own server. You cannot guarantee if someone is not logging your connections, even if it's accidental. 

Did you get an onion address in the debug.log? Did you configure Tor correctly? Can you add debug=Tor into the config file?

Try following the steps here: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md#3-automatically-listen-on-tor

It's confirmed right now. Your transactions are appearing on the blockexplorer as well.

Yes, I know.

Those two transactions spends the same inputs and thus 'conflicts' with the transaction that you just sent. That explains why blockexplorers are not displaying your transaction; the transaction conflicts with another transaction in their mempool and their node will not accept and display it.

Unconfirmed transactions: https://blockchair.com/bitcoin/transaction/95097866c8ad9c56247f93c86a1a9b813043a71874e17f23f5f173ba60dd001b
https://blockchair.com/bitcoin/transaction/af1b31ca7621b25f000dda3c36d56a8161ba2c2cb179d3632f8bd78fcd5904fd

It doesn't appear on blockexplorers as the transactions that you've created with Electrum conflicts with the two transactions above, for which neither signals opt-in RBF. The Electrum node that you were using most likely already dropped the transaction, given that the minimummempoolfee is currently bigger than 5 satoshis by default implementation. Blockexplorers might not be able to see it but it's fine as long as nodes are willing to relay it; not a big issue and nothing much that you can do at this point anyways, other than moving away from Blockchain.com.

If Electrum didn't throw an error during the creation or the broadcasting of the transaction, I can't see how Blockchain.com could've messed up an address like this. At the bottom right corner, is the bubble green or red? Try clicking on it, uncheck "Select Server automatically" and select another server but right clicking and selecting "Use as server".

If not, then go to the transaction details and go to Export>Copy to clipboard and go to https://blockchair.com/broadcast, paste and click Broadcast transaction. Be sure to select Bitcoin of course.

Electrum doesn't follow BIP39 standards. Go to console and type getmasterprivate.

It's from the server that you're connected to. They can display any arbitrary message. It was probably put there by the owner for revenue from any referrals. SSD is the available disk space of the Electrum server you're connected to.

I concur, in normal scenarios, they are both safe. Browsers are however another security risk as you won't know how it'll behave while the seed is being generated. Not that I really dislike it, just that using Electrum can probably achieve the same thing.

Iancoleman's script cannot control how your browser function; entirely possible that the browser caches parts of the webpage and accidentally reveals your seed phrase. Not that big of an issue if you choose to do it offline and wipe your drive again after using it.

Not really, nested segwit would be more than sufficient. The version bit (wrongly referred to as checksum by me, sorry) helps with normal users that aren't really that techsavvy, helping them to restore the wallet correctly years down the road. I don't think there's really any issue with separating the different address type as of now, would be confusing for some if suddenly different address types starts to spawn in the same wallet.

Anyways, it's not impossible to implement but they were fairly reluctant previously, or so when I was searching it up previously. There's an open github issue on this though: https://github.com/spesmilo/electrum/issues/6016.

Electrum doesn't require the entire blockchain to be downloaded to function. You aren't talking about old wallets and private keys has largely remained unchanged throughout.

You can indeed send the funds back to the origin address. If I were you, I would probably just transfer it by creating another wallet with a 12 word seed and send the remainder to one of the addresses within it. It'll help with your privacy immensely and also gives you the benefits of using a HD wallet. As long as both of your Electrum clients are recent (preferably 4.0.9), then it's perfectly fine.

Spending from, yes. Sending to, yes.
Not all. You can import addresses of different types on Electrum and Bitcoin Core as well. You can absolutely generate nested Segwit address from the same seeds but Electrum's checksum prevents this, probably to reduce the probability of newbies being confused when restoring their wallets.
No, why would you do that? You have to reference a UTXO that is valid, OP_return inputs are not stored within the UTXO.

Derived demand from mining does contribute to a larger electrical demand from those sources, for which if you're the government (and it becomes an issue), you would probably implement a tax directly on the miners to avoid the distortion within the energy market caused by it. While it isn't exactly a carbon tax, you're essentially making mining less profitable. I don't find it a huge problem, but it doesn't mean that Bitcoin will not indirectly result in pollution; increase in Bitcoin prices results in more miners and more ASICs -> E-waste and perhaps electrical usage.

Thanks for the warning as well. Thought that it was obvious that it shouldn't be done.

You can use less if you're choosing seed phrases shorter than 12 words.

Anyways, while it does indeed appear to be using the RNG correctly, provided that your browser correctly provides the entropy. I don't believe that open source codes means anything unless it is signed by someone you trust; for which the PGP is signed and available on github as well.

---

Formatting OS is safe enough, unless you're messing it up badly. Using a USB as a liveCD doesn't eliminate any BIOS rootkit or anything similar. While I personally wouldn't run Windows to do anything like generating a cold wallet, its still okay as long as it is offline.

Iancoleman's site uses the same entropy source as bitaddress, which is Crypto.getrandomvalues(). Not to be confused with math.random which isn't a CSPRNG. It should provide similar entropy levels as it does gather extra entropy from the OS. There really isn't a way to ensure entropy, just ensuring that iancoleman is getting the entropy from a secure source is sufficient.

Mining will never end; 2140 is simply the year for which the block rewards diminishes below 1 satoshi. I highly doubt that it is feasible to try to price the environmental impacts fairly or is it easy to impose the tax on the users themselves. It is perfectly feasible to be implementing it for miners but it would probably only affect the numbers of miners and their profit margin. Whether the price would drop would be an entirely different issues that isn't exactly affected by this; difficulty and the network hashrate could be affected if this ever happens.

Yes but the demands could've been caused by an external factor as well; take for example Dogecoin which rocketed after Elon Musk tweeted about it and Bitcoin when Tesla bought into it as well. These would influence the demand and probably cause more people to buy/sell it which would then result in a new equilibrium formed with the supply/demand curve.

Satoshi chose 1MB as the block size limit (before there wasn't any limits) but look, it is obviously not feasible if we need to scale up. If you only consider the original consensus rules to be the only version of Bitcoin, then you would probably not be using the Bitcoin that you have today. Satoshi did lay the groundwork but it is obvious that not all of the choices that he made has actually made any sense at all.
Would it have made sense to be following the original Bitcoin with no block limits, an overflow bug, no segwit, no p2sh, etc? It was obvious that Satoshi didn't mean to leave Bitcoin as it is, there is a set of rules which probably won't garner any support or would redefine Bitcoin but it doesn't mean you can't improve Bitcoin.

---

I don't think this is really up for discussion, I don't think Bitcoin would've survived if it didn't evolve.

Let's represent it with the number of permutations that a 12 words seed have.

2048^12 possible seeds, a little less than that if you want to adhere to the checksum (lowers from 132bits to 128 bits). 5.44 x 10^39 possible permutations. Let's say you can bruteforce 1 million seeds a second; giving you about 1.7264453e+32 years to exhaust the key space. It's roughly the security of a Bitcoin address. 24 word seeds has even more permutations.