That's an excessive generalization. There is a reason why most people who are truly concerned about their privacy don't use VPNs. There are tons of ways for people to compromise their privacy when they're using VPN. It really doesn't matter what your government thinks about your habits, you have the rights to maintain and protect your own privacy and they shouldn't have any problems with that. So long as your Tor connection is secure enough such that nothing is leaked.

VPNs on the contrary, doesn't provide sufficient privacy. Your VPN client can leak information if not configured properly, the addition of an additional eavedropper in your connection, the possibility of the data being analyzed, so on and so forth. ISPs will absolutely track and collect your metadata no matter what you do, like what NSA has always been doing.

Nope, it is generally used to signal readiness. The fact that Bitcoin Core warns of the activation of unknown rules isn't always accurate; miners can use version field as extranonce for ASICBoost, though this has changed through the years.
That is not correct. Soft forks are activated with evaluating a range of blocks, for which N of the last M blocks are signalling a higher version bit. Bitcoin Core which are upgraded are designed to enforce the new rules with the miner's participation while maintaining backward compatibility at the same time. Upgraded clients will not reject any blocks unless the threshold is met, and for which there is still a grace period for the rest to upgrade.

It has happened before, and that was when SPV mining was prevalent. Use of versionbit did not prevent these forks: https://bitcoin.org/en/alert/2015-07-04-spv-mining. The prevention is contingent on the miners mining the blocks with the appropriate rules and the user to update their clients and hence versioning system does not explicitly prevent any sort of issues with it.

In Electrum, go to Wallet > Contacts.

You can have it as a tab that you can click on. Generally, I recommend just finding and verifying the address each time that you're sending. Its safer this way as any malicious party with access to your computer can modify your contacts.

Don't run VPS. People are really bad at keeping their VPS safe and secure and are bound to make mistakes that opens up the attack surface. Other than the possibilities of misconfiguration, it gets worse by the fact that only one entity is likely to route their traffic to it. Hypervisors also provide little to no privacy to that.

VPN and Tor is pretty doable, Nord has it built in where certain servers are optimized for Tor. It just provides a false sense of security however, and adds little to privacy if any. Try not to use both at the same time.

Nope, but you can use some simple math. BitBox has a nice lookup table here: https://bitbox.swiss/bitbox02/BitBox_Diceware_LookupTable.pdf.

ColdCard has a python script for you: https://coldcard.com/docs/rolls.py. ColdCard converts your input to SHA256 hashes before continuing with the word assignment.

Generally, if you have two different methods of generating randomness, and in your case two different bingo machines with different number of balls, you're bound to have certain values occurring more frequently than others.

It's certainly a complicated topic. Rest assured that it is a topic that is heavily studied and there shouldn't be any concerns about using it so long as it is securely implemented.

There was an extensive discussion on this: https://bitcointalk.org/index.php?topic=5460240.0.
Yeah, they are probably not random. The QC on these aren't as stringent as you think. Any difference in the size of the balls would result in certain results being more common as others. It really doesn't matter how unpredictable it is, any degree of randomness below that of your computer already means a weaker seed. I wouldn't trust a toy for my security. Besides, you have to consider the checksum for the final word, and BIP39 also only allows for 24 words at the maximum, anything beyond that is not within specs (even if it is in multiples of 3s).

The best practice isn't to use a bingo machine, but using an unbiased 6 sided casino dice, generating at least 50 rolls.

If you treat Bitcoin as an investment vehicle, it won't grow as a currency. People would buy to store them rather than to see the utility behind it. If you make people adopt and actively use Bitcoin, that is how Bitcoin could get  popular and achieve mainstream adoption. People are always purchasing Bitcoin when there's a hype and the potential to be rich. Truth to be told, most of them don't care about the future of Bitcoin and wants to get rich quick.

The more people that adopt this mindset, the more stagnant Bitcoin becomes. I don't think Bitcoin has much left to prove, and if they don't see it as a viable currency, then there is no reason to force them. The time is only ripe for some when they see the potential to become rich.

That's also true. Electrum used to use python-ecdsa with some monkey patching done to it while they were using it. It was slower though, as compared to libsecp256k1 library, that, Qt and cryptography are not pure python. The migration was done to enforce and improve performance; it used to be optional before the introduction of lightning which necessitated the speedup.

It doesn't get lost. The new RBFed transaction replaces the old transaction. Hence, when you're sending the new RBF transaction, you're spending the same inputs (additional, if you didn't have enough BTC) but just paying more fees this time.

When your transaction gets RBFed successfully, it just gets dropped. It is as if that transaction has never happened.

Miners influence and create forks, nodes are generally less susceptible to this sort of things. Most changes that we have so far are soft forks and there isn't any compatibility issues with the older un-upgraded nodes. The whole point about block versions is to ensure that the miners signal readiness to accept the changes to the network. This by no means prevents any sort of forks, just that if the miners have upgraded their nodes, they should have no problems with any newer rules or TX formats. They can still fork the network regardless.

The whole thing about increase in hashrate doesn't happen with Bitcoin, but it happens with altcoin due to MultiPool switching and that is only due to profitability.

Bitcoin is a speculative asset, not a good store of value. Generally, you consider stable assets as a good store of value, where there is little risk of fluctuation and loss of value even for a long term. Things like gold, platinum and basically most precious metals are good store of value. They neither decrease nor increase very much in the long term. Part of it is due to the wide acceptance of them as a stable commodity and their application in crucial consumer components.

Bitcoin, on the other hand is regularly subjected to scrutiny and regulations. It does not fit the criteria to be a good store of value.

I presume he is talking about Conclave, Mike Hearn did finish the project and published it subsequently. Albeit years after his passing, but I presume that he continued and worked on the project afterwards. Here's the link to his Medium: https://r3mike.medium.com/a-deep-dive-into-conclave-1-0-415ad13ba465.

Conclave was integrated into r3 at some point in time (not sure the extent of its integration currently) and it would be something for enterprise users instead of normal consumers: https://developer.r3.com/wp-content/uploads/2021/09/confidential-computing-with-conclave-web.pdf.

I would advocate for 2-of-2 as well. 2-of-3 introduces redundancies, but that model is more suitable for situations where you're facing the problem with uncooperative signers and doesn't necessarily improve your security. It just seems like an overkill. It might just provide the same security if you're using on a device than something less secure than the two current devices that you have.

Backing up your seeds multiple times in secured locations would be a given, no matter how redundant your Multisig system is.

No.

Electrum has a gap limit, which means that once X (IIRC, its 20) addresses are empty, it stops querying for addresses with balance. Only the address that are used + 20 empty addresses will be leaked. Electrum does not leak xpubs.

The issue arises when Electrum queries your addresses. If you're using Electrum to serve as a watch-only wallet, you'll have the addresses linked to each other. Electrum queries all the required address using the same IP address. Any adversary running the node would be able to make the assumption that they're owned by the same person and thereby linking them to each other.

Running it behind a proxy or Tor won't help in this case.

That's correct. It is installed when building Electrum and I forgot that it is required as part of the list of non-pip dependencies.

Regardless, Electrum still doesn't contain as many non-python dependencies as most wallets. Most of the wallets uses libsecp256k1, and seems to follow what Bitcoin Core does as well.

There is a pure python secp256k1 library out there but I guess there are reasons for not adopting those but using more mainstream ones instead. ** Possibility due to adoption and how thoroughly tested those are.

Depends. Those CSPRNG generally will still seed their randomness pool with the entropy from OS's CSPRNG and under normal circumstances, this wouldn't be compromised. From what I can tell, they are calling the correct functions. CPU is just one of the many inputs for the entropy pool and there are various other sources for entropy, hardware interrupts, noise, keyboard inputs, etc. The randomness falls on the OS's ability to gather these, not the CPU.

What benefit does it serve? Recirculating presumably lost coins goes against the intentions of the owners, and that is totally out of the scope of Bitcoin. The entire point about Bitcoin is not to have the decision of any important consensus changes to fall on the shoulders of the Core devs. The majority of the community would likely be against anything like this and true decentralization can be proven if the developers would stand by what they preach, and for those against this decision to start a fork.

Electrum is written in Python and does not use any C++ dependencies. There is no reason for Electrum to use a third-party C++ module and besides, their seed generation is vastly different from how libbitcoin generates theirs.

Electrum uses os.urandom which is a CSPRNG. It does not suffer from this vulnerability.

Possibly unrelated. Bitcore uses crypto.getrandomvalues which should request the browser to seed from urandom. There should be some checks on the bias of the data as well. JS is not great for CSPRNG but I wouldn't expect it to be that much of a security risk. Besides, OP seems to mention that Bitcoin Core generated those addresses.