I'm having some slight troubles understanding what you're implying.

So first of all, if you've generated the wallet by selecting Standard Wallet > Create a New Seed, then there is no need to mess with any derivation path. The derivation path for Electrum standard seeds are always correct and has never changed.

The only reason why you would check "BIP39 Seed" is if you've used that previously *AND* sent your funds to it. If not, there is no need to check "BIP 39 seeds". Unless the user specifically asks for their seed to be imported as BIP39, then Electrum won't use BIP39 and you shouldn't restore your wallet using that.

Edit:

Slightly offtopic. FFS. There's really no point being frustrated with people trying to seek clarifications to your question.

You literally said:

then I get different addresses which I have used after I have updated the wallet.

And

If I don't check the BIP box then it generates the wallet I had after the update.

Those two statements would probably be confusing for most.
Also, there's obviously a bunch of misconceptions in your post and answering them individually would've helped us to narrow down and eliminate all the possibilities. I believe my question was completely reasonable given how your response was phrased. Well... Good luck if you're going to be pissed at people trying to help you.

Electrum has never changed the derivation path for legacy wallets, AFAIK and it has always maintained backwards compatibility. Each of the seeds has a specific version to recover specific wallets and the fact that the checksum is valid for Electrum probably means that the seed is an Electrum seed.

Are the addresses in your recovered wallet bech32 (bc1) addresses? It is quite unlikely for that to happen.

Electrum doesn't store the phrases for BIP39 recovery. If the checksum is mismatching for BIP39, then you shouldn't be recovering using it. Any working wallet will not generate a seed that has a wrong checksum, because there'll be no use for a checksum.

Try this. Electrum logs communication with the servers which should give some clues as to what is happening.

It is not. Think about it.

Mining is an entire industry by now and the barrier of entry has been raised again and again. China explicitly banning certain Bitcoin farms might have some impact on the difficulty in the future but it has certainly affected the prices right now. Those miners have access to the lowest electrical rates and ASICs, as they're doing it in bulk. Do you really think an average person can mine at a lower cost at them? Most likely not.

Any difficulty drop is almost always shortlived and the subsequent difficulty change will result in a significant change in difficulty as well. It is possible for people to be mining for a profit (probably 1-2%), if difficulty drops further and price increases. Reaching ROI can take months and most revenue are not sustainable. I can guarantee you that it is faster (and safer) for people to put $4K in Bitcoin than to purchase an ASIC, wait 7 months for ROI, if that is even happening and potentially risking having to stash it away somewhere after the difficulty starts increasing again.

There are a ton of things that can and will go wrong in the process. Investing in mining equipment without taking into account further fluctuation in profitability is just stupid.

---

Also, difficulty hasn't changed. It is less profitable to mine today than 6 days ago.

I think there is actually certain criteria and it changes according to the kind of transactions that is being created. If I remember correctly, signalling RBF actually defaults to an economical estimation instead of conservative. I can't check this right now so perhaps someone can chime in if I'm wrong.

If the transaction is signalling opt-in Replace by Fee.
Both of the arguments are for Core's fees estimation. Core collects data and builds a set for which it would provide a certain degree of confidence whether it will be confirmed within the conf_target. This is dependent on your estimate_mode, conservative results in a higher fee while economical is vice versa. Unset allows Bitcoin Core to automatically choose either of them.

It is possible. Don't bother running Raspbian if you don't need to. There's nothing wrong with running Windows, it is worse to be using OSes which you have zero idea about.

Are you planning to install any Linux distributions? If so, install it and follow this guide: https://bitcoin.org/en/full-node#linux-instructions. It doesn't get simpler and more concise than that.

Difficulty hasn't changed for the current epoch. Any profitability change will occur in the next epoch. I highly doubt that it is very profitable for anyone right now. Difficulty remains unchanged and the price has dropped quite significantly.

The only time casual miners are able to get any significant profit is that if the difficulty drops drastically while the price rises at the same time. Else, difficulty tracks the profitability and you're better off just buying your coins.

Bitcoin is a currency and the value has to be determined against other currency. Bitcoin can survive without fiat as Bitcoin is not dependent on it. If fiat were to collapse overnight, people would simply start to establish the exchange rate against other mediums, like precious metals.

The only reason why this issue matters now is due to how much Bitcoin fluctuates against fiat. Bitcoin is sufficient to fulfill the various economic functions of a currency. Payments can be settled using Bitcoins in absolute amount or the approximated amount when compared against other forms of currencies, this is dependent on if they care about that. But as far as I'm concerned, 1BTC = 1BTC.

I can but there are better ways around it. It is unlike the $5 wrench attack, the complexity of such an operation is fairly high, given that users should verify the integrity of their ISO files and that dev/urandom is often mixed with other unpredictable variables. There are tons of other theoretical ways to compromise airgapped setups as well, some can be far more practical.

But you're not trusting your kernel in the first place. What stops the kernel or the OS from using these tactic to introduce covert vulnerabilities? Most wallet uses deterministic signatures nowadays so that is actually addressed. Well, unless it somehow works in an unintended manner due to external influence.

That is not the point though. You're assuming a compromised kernel and possibly other parts of the OS. Then what stops the OS from destroying the security using other methods? There simply isn't anyway for the average person to not be reliant on certain degree of trust on their hardware and their software. If you can't trust the OS, don't bother generating your own entropy because that won't help in making your keys more secure.

Tl;dr if you cannot trust your OS's integrity, you're better off using a pen and paper.

Is there anything insecure about the implementation (together with the hardening)? Compromising the CSPRNG isn't very common or at least I've never heard of it before.

The problem with generating entropy by yourself is not that it is outright insecure. If done right, there is nothing wrong. But the problem is that people seems to always assume that there is some problem with a certain implementation that has been peer reviewed over and over throughout the years and implemented in various systems. If you want to save the hassle of making your own entropy, generating your own keys and having no knowledge of how to do it securely, then there is absolutely nothing wrong with current implementation. In fact, I believe iancoleman had a slight issue with modulo bias previously in one of their revision, not security critical but just shows that it isn't as easy to do something like this perfectly.

After all, what stops your own wallet/OS from making your signatures use a predictable nonce? Again, entirely theoretical and possibly a fantasy threat but that is about the same level as breaking through the CSPRNG and the implemented safeguards.

You're probably going to have to roll quite a few times to ensure that you're eliminating the possible bias to ensure sufficient entropy. I would say 50 for minimum of 128 bits and 100 for 256 bits assuming base 6. At least 100 rolls should be okay, if you're not specifically trying to introduce bias. Just roll more and try to even it out.

I've had coldcard for quite a while now and they allow for verifiable entropy generation. I don't consider myself paranoid enough to warrant that and cross validation also requires an airgapped clean computer and if that is the case, I would've foregone Coldcard and just continued with my airgap setup and save a hundred bucks. Relying on multiple computers increases your exposure surface and is just troublesome in general.

No, you can't. The states on both chains are not consistent and you cannot transact across different forks. Transaction can only be done within the chain, while the transaction may be valid on both (which raises the possibility of replay attacks), you cannot transfer coins from one to the other. Take the fork as two different coins completely, or Bitcoin and Bitcoin Cash.

Classic social engineering. In this case, it is highly specific and tailored to a specific group of users: Ledger Customers involved in the leak.

This is also the reason why people shouldn't be plugging in random USBs that they find anywhere. They are cheap to manufacture and leveraging on customer's complacency is an accident bound to happen. If you did not order something, then you should assume it as malicious. If Ledger sent me something like this, it would be a giant red flag, partially for me assuming that they did not scrub my details from their own database. Always verify the authenticity of devices that you receive and ensure that it isn't tampered with or otherwise counterfeit.

Also introducing various theoretical factors which can reduce the entropy, Bitaddress still collects entropy from multiple sources (including urandom indirectly) to form the final entropy, so does iancoleman, AFAIK to try to harden the entropy. None of those are meant to replace the CSPRNG that is used primarily. Personally, recommending the user to use an alternative (and single) unproven source of entropy isn't very ideal. I'd rather have myself include a known CSPRNG in calculation of the entropy. Addition of various variables and/or making the user decide the sequence of the dice number has potentially undesirable consequences. This subject has been discussed quite a few times in the forum and quite thoroughly, so nothing much for me to add on here.

You cannot verify how random your results are. You can only verify that you generated the results and that you are trusting that the way you've executed it is free of any critical mistakes that could influence the entropy.

Yes, as for my dice rolling is the faith that my dice is not biased (perfect CG) and that I'm not throwing them in a way that makes it biased. As I've said, most Bitcoin wallets collects data from multiple sources to try to prevent a single source from ruining the randomness of your keys. Core in particular uses urandom, rdrand, CPU cycles, OpenSSL, etc. Compromising every source of entropy constitutes a complete compromise of either your OS or wallet as well. To which, at this point you shouldn't be using them.

You can of course, XOR your own entropy in addition to those given by your OS. The way the wallets do this is by including multiple sources of data.

If you cannot trust the integrity of your offline system, then you actually might have more things to worry about; the signature for the transaction it generates, whether it is generating the correct keys, etc. No one AFAIK has been attacked by someone compromising their RNG so far, because it is usually hardened. If you don't trust the OS, then the best way is to try to obtain the best source of entropy (radioactive decay, etc) and calculate everything by hand.

You cannot verify entropy. The 100 rolls, or however many rolls is usually insufficient to build a model to show that it has zero bias (or with the numbers evenly distributed). Most wallets includes various other variables to try to reduce their dependency on a single source within the OS. There is a very good reason why most known wallets don't allow their users to provide their own entropy out of the box. It usually doesn't end very well.

I would probably trust the group of people that made Bitcoin Core and the Linux Kernel than myself. Might just be me though.

Of course, as I've said. If you've got any idea of what you're dealing with and accept the possible accompanying risks, then there's no problem.

If there is a malware infection, using your own entropy won't matter. They just wouldn't attack your entropy.

Your computer's randomness is crucial for many of its function and the kernel provides for and gathers sufficient entropy through several environmental sources. Generating your own entropy through your own methods can introduce potential weakness through inherent weaknesses that are associated with various actions or objects; imperfect dice, throwing techniques, etc. These can make for entropy that are perceived to be enough but infact would provide lesser entropy than that generated with your computer's randomness. Certain wallets also include additional entropy sources as a fallback.

I would only do this provided that the user actually understands how this works and to ensure unpredictability in the results. If not, then using a well-known and tested programs would be far better for most purposes. If you're paranoid and understand what you're doing, then yeah it is doable.

A sudden segregation of WWW will result in the blockchains being split with the connections to external addresses being restricted and the chain being able to continue within its own bubble only. If a state is willing to do this, they can easily either ban Bitcoin completely or basically negate any benefits Bitcoin provide, due to the effective sybil being done on the citizens.

Whether they will piggyback on Bitcoin or make their own remains to be seen. Without completely removing encryption, Bitcoin can still function within the bubble itself but it won't be able to transmit any information outside of it, provided that there isn't any efficient system to maintain consensus with the other systems.

Some servers disables their ICMP ping and can result in a false negative.

Here's a list that can be pinged:

---

OP, if you're able to access the website, then the update checking should not fail as it is hosted on the same domain. There might be something specifically blocking your Electrum from accessing the internet instead of a filter on your network.

Go to Tools>Preference and check "Write Logs to File", restart Electrum and try connecting to a server again. Next, go to the data directory (%appdata%/Electrum) or whichever directory you're storing your files. You will see a folder called Logs, open it and open the latest file with a text editor. You can scroll to the bottom and look for any anomalies related to the connection attempt.

Alternatively, you can try using Wasabi wallet. It isn't as easy to use as Electrum IMO but it is definitely better in terms of privacy in the first place.

Yes. Creating a payment requests will result in Electrum tracking transactions specifically for that address. It is done locally and does not have any effect on the actual Blockchain or your funds.

The addresses tab might be hidden for some, go to View > Show Addresses and your list of addresses will be shown in the address tab.