I'll be honest, it's getting kind of boring debunking the same nonsense every few months whenever a different news network or blog site picks it up and runs a story without really understanding the facts.

Firstly, electricity consumption is irrelevant - source of electricity production is what we should be interested in. It doesn't matter if bitcoin uses 5 gazillion terawatt hours if all 5 gazillion of them come from 100% renewable sources.

Secondly, the website that that article is based on assumes that all bitcoin mining is using the average global electricity. This is not the case, and we know that bitcoin mining actually uses almost 80% renewable sources. Therefore the CO₂ production will be significantly lower than this article makes out.

Thirdly, the CO₂ that bitcoin mining produces is literally inconsequential. Streaming online pornography accounts for 30x more CO₂ production than bitcoin does. This is just porn. No mention of Netflix, or Disney Plus, or Amazon Video, or Hulu, or any of the major steaming services that use magnitudes more electricity. I've never once seen a news article about how we could all save the planet if we just stopped watching so much porn.

What about other massive contributions to global CO₂? Console gaming? PC gaming? Leaving devices on standby? Printing, moving around, and destroying trillions of notes of fiat currency? Electricity to power every bank branch and ATM in the world? Hell, even just the annual beef consumption of 5% of the US population produces more CO₂ than bitcoin does.
 
But sure, it is bitcoin that is the problem.

Then don't use the main chain for micro payments. Use Lightning for these payments, and keep the main chain for larger payments where you want the added security.

And completely negate all the benefits of using bitcoin by switching to a coin which is not decentralized, not censorship resistant, not immutable, and not immune to being frozen or seized. If you want to use a system with all these disadvantages for the sake of transferring the cost of the fees from yourself back to the merchant, then you might as well just go back to using a completely centralized fiat system.

I would say both email and SMS are terrible for 2FA.

As TryNinja has explained, SMS based 2FA is terrible because it is almost trivially easy in some cases to perform a SIM swap attack. As in, "one phone call to the mobile operator and 5 minutes and its done" easy. Don't use it wherever possible. Email however, is equally terrible, for the main reason that almost everyone uses the same email address for their exchange account as they do to receive their 2FA code. If someone hacks your email, then they can reset your exchange account password and receive your 2FA code all in one. Therefore, since both your factors (password and 2FA code) can be compromised at once, then it isn't really two factors at all.

You should use, at a minimum, an authenticator app on a device you do not use to log in to said exchange or store your exchange account's password on. Even better is to use a physical 2FA hardware key.

The risks to both Binance and Electrum are significant. Clipboard malware could make you send your coins to an attack if you are not careful from either exchange or wallet. Malware could steal your exchange log in details, and malware could also steal your private keys. This is one of the main reasons people recommend either hardware wallets or cold storage, to mitigate the risks of infected devices.

Not in the case of a watch only wallet.

Let's say I keep my full wallet permanently airgapped. Whenever I receive a transaction to a new address, then I copy that address across to my internet connected computer and add it, along with 9 other decoy addresses which have also just received their first deposit, to my watch-only wallet. I keep all my empty gap limit addresses offline and therefore never queried.

If you are planning to withdraw the coins from Binance, hold them for a while, and then send them back to Binance to trade, then I don't see the point in using a mixer or coinjoin in this situation. The only thing that mixing or coinjoin does here is stop Binance from seeing exactly which address(es) you are holding your coins in. They will still have complete knowledge of how much you have withdrawn and how much you are depositing.

At the end of the day, you can never say with 100% certainty that your coins won't be frozen for using either of these technologies. If you are just planning on using these coins to go back and forth to Binance then you are probably safer not using them at all, and only using them when you are moving your coins to a different exchange/service/merchant/etc and you don't want Binance tracking those movements.

You seem to be a little confused about how wallets work.

Writing down a private key on a piece of paper is a perfectly reasonable way of creating a cold wallet for long term storage. However, you can't then use Electrum to generate "many addresses" from that wallet. A private key only creates a single address. It is a seed phrase which is used to create many addresses. If you want to back up an entire Electrum wallet or turn an entire Electrum wallet in to a paper wallet, then write down the seed phrase, not individual private keys. If you just want to back up a single address or create a paper wallet of a single address, then write down the associated private key.

Although "classic" paper wallets are a single private key backing up a single address, I would argue that writing down a seed phrase is better for a number of reasons - less prone to errors, don't need to sweep the entire wallet when you spend, no concerns regarding lost change.

Exactly. A brand new account suggesting a mixer that no one has ever heard of before? This screams of a scam to me.

I suspect anyone who tries to get greedy and use this "doubler" will find whatever funds they send immediately included in a CPFP with a very high fee.

The only part of that which is accurate is the bolded part.

An RBF transaction must include at least one of the same inputs as the transaction it is replacing. It does not need to send the same amount, it does not need to marked as RBF (only the transaction being replaced needs to marked as RBF, not the transaction doing the replacing (unless you also want to be able to replace your replacement transaction)), and it does not need to send coins to the same destination.

If I have a transaction marked as RBF with inputs A, B, and C, sending a total of 5 BTC to addresses D, E, and F, I can replace that by sending any one of my inputs to address G, for example input B sending 2 BTC to address G. As long as my second transaction pays a higher fee, then it is highly likely to confirm first and therefore make the first transaction invalid.

The two options here are your wallet is not syncing properly, you are not in the correct wallet. The easiest way to determine which of these is happening, is to enter your passphrase protected wallet and look for the address you sent all your coins to. If it is there, but shows no balance, then it is a sync issue, and I would try using your hardware wallet with a different piece of software, such as Electrum as Charles-Tim has suggested above. If the address is not there, then you are not in the correct wallet and so have most likely entered the wrong passphrase, although it could also be a problem with the derivation path.

What hardware wallet are you using? What piece of software are you using to interact with your hardware wallet?

Who's to say Foxpup isn't buying services from me?  

The percentages are the number of bitcoin owned by that group, not the number of people in that group.

If we say Shrimp own 900,000 bitcoin between them, and each own <1 BTC, then there must be at least 900,000 Shrimp, but potentially up to several million.
If we say Humpbacks own 2,470,000 bitcoin between them, and each own >5000 BTC, then there must be at most 494 Humpbacks, but potentially even fewer.

OP said the thief was using Jaxx wallet:

You say Jaxx doesn't show up unconfirmed transaction, but my (admittedly several years ago) experience with Jaxx is that it does. Certainly, their support pages suggest that unconfirmed transactions are displayed as "pending transactions": https://support.decentral.ca/hc/en-us/articles/360048583473-Pending-Transaction

The default_mempool_expiry is 336 hours, which is exactly 14 days. This is the default length of time which a node will keep an unconfirmed transaction in its mempool before dropping it, but there is nothing stopping it from then receiving the transaction again from another node.

The default_max_mempool_size is 300 MB. This is the default maximum size of a node's mempool before it starts to drop the lowest fee transactions in its mempool. The shortest period is therefore "immediately", as a node might not even accept a transaction to its mempool if its mempool is currently full and the transaction pays a lower fee than all current unconfirmed transactions.

Not at all. No confirmations were needed and only a couple of seconds were needed to confirm the test transaction. Also, no block explorers were required.

If the thief opens his wallet and gives OP an address, and OP sends 10,000 sats to that address, the thief's wallet will show the incoming transaction within two or three seconds. You can test this yourself when you pay for something using a payment processor, which detects your transaction seconds after you hit send. You can even test this yourself by opening two Electrum wallets and sending coins between them. As soon as the transaction is broadcast, it is relayed across the network within a few seconds. Seeing the transaction show up in the thief's wallet, even with zero confirmations, is enough to confirm the address is correct. OP can simply click on the same address, click "max" or "send all", and click broadcast. The whole thing could be done in 10 seconds.

Yeah, the language can be quite confusing sometimes. Although people talk about "the mempool", they are usually either referring to the mempool of a specific node, or they are talking about the complete set of all unconfirmed transactions. When the mempool is close to empty, then more or less every node will have the same set of unconfirmed transactions in its mempool, but when the mempool is very full as it has been recently, then often low fee transactions will be dropped by some nodes but not others.

Yes, absolutely. There is no requirement with an RBF transaction to pay the same addresses that the first transaction pays. This is why services which accept zero confirmation transactions won't accept them if they have RBF enabled, because it is incredibly easy to redirect the coins to a different address.

As far as I am aware, blockcypher have never made public which nodes or how many nodes they use to broadcast transactions or use for their blockexplorer. It is entirely possible they broadcast your transaction to one node and looked it up from a different one.

It could be that it was initially added to that node's mempool, but as the mempool continued to fill up over the course of the day, it was later displaced from the bottom by other higher paying transactions.

This is not accurate. Each node has its own mempool, which is why transactions need to be relayed across the network from node to node and added to each mempool as they go. Some nodes may set different size limits for their mempools, or different minimum fees that they will accept before adding a transaction to their mempool. A transaction can be present in some mempools but not others.

You have this the wrong way round. A RBF transaction must use at least of the same inputs as the original transaction it is replacing, but can redirect the bitcoin to any address(es), including not paying the address(es) in the original transaction at all.

That means that whichever nodes blockchain.com and blockcypher.com are using to gather information for their block explorer have either not seen the transaction at all, or have seen it but not added it to their mempool since the fee is not high enough to displace another transaction out of the bottom of their mempool. The node that blockchair.com is using potentially has a higher maxmempool size, and so is not yet at its size limit and has space for your transaction.

I'll just say thanks from us both until his kids settle down.

This is the wrong way to talk about fees, especially when talking to someone who doesn't understand how fees work. First, we should obviously be talking about fees in terms of sats or BTC, since dollars is a constantly changing metric. Secondly, we need to talk about the fee rate, rather than the absolute fee. Given that 3 USD is currently around 8,000 sats, then for a 1-input-1-output transaction this could equal a fee of over 40 sats/vbyte. Conversely, for a big consolidation transaction with dozens of inputs, this fee might not even by high enough to meet the 1 sat/vbyte minimum for the transaction to be relayed. Talking about absolute fee is meaningless unless we are talking about a specific transaction of known size.