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.

Electrum (and Bitcoin) addresses do not expire. The payment requests that are made specifically only uses each receiving address once only for better record keeping and privacy. It is perfectly fine to use it for multiple transactions, it'll stay valid.

They aren't. Shamir Secret Sharing has entirely different properties from the split mnemonic by iancoleman, with far more complicated logic.

The system implemented basically just splits the seeds up into different cards, which still allows the person to bruteforce (albeit less effectively) given a few of the shares.

That would only lower the complexity by a little. It is still more timeconsuming to bruteforce seeds via its entropy as compared to the addresses itself. While if you succeed in bruteforcing the seeds, you'll access more than a singular address, you're far more likely to succeed in bruteforcing addresses as most of the addresses out there are generated before HD wallet became a thing and that you need additional steps to go from a seed to an address. Hence, it wouldn't make a difference to how many addresses you can access with a successful attempt.

It is quite futile to target specific groups of people, unless you know for a fact that their generation if is flawed or if majority of the users are using the same parameters for their seeds.

Yes. Same holds true for addresses and infact, people should be more likely to succeed at bruteforcing an address as compared to seeds.

Trying to bruteforce HD seeds would require far more effort than trying to bruteforce addresses. Reason being that there are far more possible child keys derivations (which is stretched with HMAC-SHA512), due to the seed size and the possible derivation paths. All of these adds up to significantly more effort than trying to bruteforce addresses, given that most people will ensure that their seeds are generated with sufficient entropy. You're far more likely to gain from finding addresses instead of HD seeds.

Attacking through the entropy (128bits) will require going through HMAC-SHA512 to get the master keys.

What version of Electrum are you using?

Are you sure you installed Electrum from electrum.org and not a phishing site? Did you validate the installation using PGP?

Hmm, okay that I didn't know. I always thought bitaddress was using a browser CSPRNG (not math.random()) for the entropy. Mouse movement and the other variables should serve as a complement to the original entropy and shouldn't be overly-reliant on that.

Anyhow, I think this proves my point that generating addresses in browser is inherently insecure.

It is. The implementation also requires certain degree of technical expertise. That I agree.

Yup correct. Actually Trezor and Armory both implements it as well. Of course, it isn't most suited for Bitcoin due to the aforementioned limitations by you and I. But it should offer a better theoretical security advantage even with using only 12 seeds, that is if it is done properly.

What about Shamir's secret sharing? I've seen quite a few implementation of it but have yet to check the threshold for the number of compromised shares before it comes trivial to get the entire secret.

For the record, I'm not aware of any standardized implementation and some of it has been plagued with certain vulnerabilities. Probably not as convenient as the system that you've mentioned.

Do you have any slight idea of what your password might be?

If you have the general idea of it, eg. list of passwords, patterns of your passwords, positions of the alphabets and numbers, you can probably try out BTCrecover[1]. It can take sometime and would probably work only if you have a general sensing of what the password is.

[1] https://github.com/3rdIteration/btcrecover

Incorrect. Anonymity can never be guaranteed through using Bitcoin and I'd go as far as to say that it is almost never achieved with the activities that the average Joe would engage it. There are various points of failure present when one is trying to cover their track by disassociating various transactions from each other and that can be exploitable. The "degree" of anonymity that you can achieve is dependent on the various precautions and/or measures that you take to try to ensure your anonymity. With sufficient resources and if you're a person of interest, you'd have to go through even more loops to which I'll say that you're better off trying to use a crypto that is focused on your privacy.