When bitcoin was first launched, the client only showed two decimal places, not 8. Many users at the time did not know it was further subdivisible.

Here's another post from Satoshi which might interest you: https://bitcointalk.org/index.php?topic=44.msg267#msg267

Clearly the idea of moving the decimal point never caught on, and I can't see it ever getting enough support to happen now. Working in sats works just fine.

Well, in that case you are not relying on your memory then. If you are one of the unlucky millions to experience memory loss each year, then you have multiple back ups of your TIN.

My only concern then is the custom obfuscation method you have come up with. If your brother (for example) can recover an encrypted back up and a decryption key, then he can fairly easily try multiple standard decryption algorithms until he can recover your funds. If you've done something weird and again not backed it up on paper, he might be unable to figure it out.

See this post from Ray Dillinger: https://bitcointalk.org/index.php?topic=819656.msg9170781#msg9170781

The difference between the highest valued (GBP) and lowest valued (INR) fiat currencies on your chart is over 100x, with 1 GBP = 105 INR. Given that you are implying a difference of over 100x is fine for fiat currencies, why isn't it fine to just use sats for bitcoin?

I mean, the paisa barely even exists in India anymore, with the 50 paise coin not minted in over 20 years and every smaller coin completely demonetized. The price of everything in India is denoted solely in rupees, where something like a laptop might cost between ₹30,000 and ₹200,000. What's wrong with just doing the same for sats?

If you wanted to go down this route, it would still be better to have all four keys different but just retain two of the keys in your own possession. This allows you to diversify your back ups and adds more security, since one of the other parties would need to compromise two different keys to steal your funds instead of just one.

Alternatively, use the script that Zaguru12 has linked to above. This is a 2-of-3 multi-sig which mandates one of the signatures must come from your keys, with the other signature coming from either of the other two keys.

Wrong again.

If a pool has 20% of the global hashrate, then they would expect to find 20% of the blocks. 20% of the blocks is 1.2 blocks an hour, meaning their average block interval would be 50 minutes.

Of course it does. If you take away 3 pools with a combined 60% of the hashrate, then the remaining 40% of the hashrate cannot continue to find blocks at a 10 minute average interval. You seem to have a fundamental misunderstanding about how mining and the difficulty/target work.

I never said they did. You simply don't understand what you are talking about.

Nope, never said that either.

In your example, if pools CDE turn malicious, then pools AB remain entirely honest and of course continue with their combined 40% of the hashrate. However, blocks will be found significantly slower since we've just lost 60% of the global hashrate.

And how exactly do you propose the the network continues with a 10 minute block average after losing 60% of its hashrate?

Re-orged blocks have a clear parent which they have been built upon, which you can trivially find by looking at their block headers (which will contain the block hash of the parent they are building on). They are not orphans. Orphan blocks have no known parent.

Yet another source to prove you are incorrect: https://en.bitcoin.it/wiki/Orphan_Block

Which is exactly my point. Scammers can make fake software, fake apps, fake websites, fake download pages, but they cannot make fake GPG signatures. Once you know how to do it, it takes less than 20 seconds to verify a download against a public key in your keystore. Do this simple thing with every new version you download and you will never fall victim to such scams.

Being on the official website, although smart, is insufficient to guarantee your safety. Scammers could either have hacked the official website, or hacked the download server that it points to. Once again, if you verify the signature of what you download, then you will be protected from such scams.

This is a completely flawed analogy. If you take 60% of the hashrate away to mine a malicious chain in secret, then why on earth would the remaining 40% still be able to find blocks at the same speed? That is absolutely not how bitcoin works, like, at all.

If you take 50/60/70% of the hashrate away to mine on a different chain, then the remaining hashrate will absolutely find blocks more slowly. You honestly think if 70% of the hashrate disappeared right now to mine a different chain in secret, that the average block time would still be 10 minutes with only 30% of the hashrate remaning?

Your terminology is also wrong: https://bitcoin.stackexchange.com/questions/5859/what-are-orphaned-and-stale-blocks

Then go out and use it! If enough people agree to use bits, then that's what will be used. As it stands, almost no one uses bits. I much prefer using either BTC or sats, and not complicating things with additional in between units. It's fine to use sats up to 100,000 sats, and then use BTC from 0.001 BTC.

So is bits. 1 bit is 3 cents. If you want an "everyday" unit, then the logical choice is mBTC, which is ~$30.

You've completely misunderstood my point (as usual) and just launched in to another rant where everyone except you is wrong about everything (as usual).

Only if the attacker is bringing entirely new hashrate to attack the network. And which attacker exactly has 400 EH/s of hashrate sitting idle waiting to attack the network? The far more likely scenario is that hashrate which already exists and is currently mining honestly would turn malicious, in which case my example above is completely accurate. The combination of the 60% malicious hashrate and the 40% honest hashrate would continue to mine on average 6 blocks an hour, meaning the attacker would mine 3.6 and the honest hashrate would mine 2.4, on their respective chains.

Again, this is only in the scenario an attacker with 400 EH/s comes out of nowhere to attack the network, and not in the event that honest hashrate turns malicious. These are two entirely separate scenarios.

You were the one which started talking about hashrate on mining pools realizing they were mining maliciously and swapping back to honest pools:

In this situation, my example is completely accurate. If you are now changing to the scenario where an attacker comes out of nowhere with new hashrate, then the calculations are obviously completely different, but you don't seem to realize that these are two entirely separate scenarios.

On the contrary - you are the one ignoring the time scales when you stated someone with 50% of the hashrate will "never catch up" to a 6 block deficit, and will "always be 6 blocks behind". This is simply not true.

If you want to start placing time restraints the then question changes dramatically. A 51% attack (or even a 60%, 70%, or 80% attack) will not be successful if you place a sufficient limits on how big the deficit is and how much time the attacker can sustain that hashrate.

As an example, let's say an attacker has 60% of the hashrate, and wants to overcome a 6 block deficit in an hour. With 60% of the hashrate, they would expect to mine 3.6 blocks per hour. They would therefore have only a 7.3% chance of mining 7 or more blocks within an hour. However, the honest miners would expect to find 2.4 blocks in an hour, and would have a 90.9% chance to find at least 1 block in that hour and therefore stay head of the attacker. Multiply these probabilities (which is fudging the numbers slightly, but the premise remains the same) and a 60% attacker still only has a 0.67% chance of overcoming a 6 block deficit if you limit the attack to an hour.

BIP39 seed phrases can indeed be used to derive multiple address types at multiple derivation paths, but this is not the case for Electrum seed phrases and so you do not need to back up a derivation path. Electrum seed phrases have a version number encoded within them (as the first 8 or 12 bits of a hash of the seed phrase), meaning Electrum will only ever recover one specific script type at one specific derivation path for each seed phrase.

We already have BTC and sats which most people use. The term you are proposing already exists as bits or μBTC. We also have mBTC and msats. And a bunch of other units like the finney which already no one uses: https://en.bitcoin.it/wiki/Units#Table_of_all_units

A new unit is unnecessary. A new name for a unit which already has two names is even more unnecessary. It's a NACK from me I'm afraid.

Blockchain.com does in fact give you a seed phrase you can import elsewhere to access your private keys. It is still a terrible choice of wallet, though, since we have no idea how that seed phrase was created or who else has access to it, never mind all the other points I mentioned above.

They can't clone GPG signatures. If you spend the few seconds it takes to actually verify your downloads (as everyone should be doing), then you will literally never fall victim to such a scam.

The correct term here is stale blocks. Orphaned blocks refer to blocks without a known parent (as the word "orphan" implies), which is something different.

Also, a transaction which is included in the losing chain will only go back to unconfirmed if it is in neither of the block at the same height or the block at height +1 in the winning chain. Otherwise it will remain confirmed despite the chain split.

No, it won't. Broadcasting an RBF replacement does not make the original transaction invalid whatsoever. The original transaction remains entirely valid and could still be included in a block if a miner chose to do so or did not learn about the higher fee paying replacement.

Your numbers are all wrong.

If you take the equations from section 11 of the whitepaper and plug in the numbers for an attacker with a probability of 0.5 of finding the next block (i.e. 50% of the hashrate), then the probability they will catch up from any deficit is 1.

You are assuming that both attacker and honest miners will mine blocks at a regular 10 minute interval. Given that there is random variance, and given an unlimited amount of time, then the attacker will in fact always catch up. With honest nodes simply following the chain with the most work, then honest miners have to stay ahead at all times, whereas the attacker only has to take the lead once for all honest nodes to then switch to their malicious chain.

Further, a 60% attack does not mean the attacker is 10% faster. If the attacker has 60% of the hashrate against an honest 40%, then the attacker is 50% faster than the rest of the network.
A 70% attack results in the attacker being 70/30 = 2.33 times faster, and an 80% attack results in the attacker being 80/20 = 4 times faster.

Again, not true. With 51% of the hashrate you are mathematically guaranteed to overtake any deficit. You certainly don't need 80%.

So, I very deliberately chose a password with 20 random characters drawn from uppercase, lowercase, numbers, and symbols, for my example.

There are 95 printable ASCII characters. 20 such characters gives 20⁹⁵ combinations, which is 3.58*10³⁹. This is the smallest number of characters needed to produce a password at least as strong as a 12 word seed phrase, which has 2¹²⁸ combinations, which is 3.40*10³⁸.

So even if you don't know if my password is using real words, or dates, or patterns, or numbers, or symbols, or upper or lower case, or whatever, and you have to brute force every possible combination, that password is still roughly as secure as a 12 word seed phrase, even when you know the full word list.

You should have an option for a "New identity" on the Tor notification in the notification panel, which will give you a new circuit without closing or restarting the app.

See the section on "Managing Identities": https://tb-manual.torproject.org/mobile-tor/

If you need a whole new identity, then close the app and reopen it.

Wrong, I'm afraid.

When you load an Electrum wallet, Electrum will query whichever server you are connected to for the transaction history of all the addresses in that wallet. Even if only one of them has transactions, Electrum doesn't know that until it asks. Even if you don't do anything except open your wallet and close it again, Electrum still has to ask for the history of all the addresses in that wallet. As soon as you connect to a malicious third party server, then the owner of that server can immediately link all your addresses together. The only way around this is to run your own node and your own Electrum server (this is easier than it sounds).

If you connect to a different Electrum server from a different Tor relay/VPN server/IP address for each wallet you open, then an attacker won't be able to link your wallets to each other (provided you never make a mistake, which is unlikely), but they can still link together addresses within the same wallet.

If you want to route traffic from your other apps via Tor, then yes. But not if you want to use a browser. If that's the case, as what OP is doing here, then you should use the Tor browser.

https://support.torproject.org/tormobile/tormobile-6/

No, it isn't. You'll get better security with Tor due to things like NoScript and limited permissions for websites you visit, and you'll get better privacy since by using DDG via Orbot you are providing a fairly unique fingerprint which could be used to deanonymize you.

Why not just use Tor browser?

If your computer is hacked, then your coins are at risk, as they would be with any hot wallet. If Electrum itself is hacked then nothing happens to your coins unless you download and install the malicious version, which you will never do provided you properly verify your downloads as you should.

If the Electrum website and GitHub are compromised, nothing changes with your wallet and it will continue to function normally.

Electrum is fully open source and reproducible, so we know there is no malicious code in it because we can read the code ourselves.

This is incorrect. Blockchain.com is completely centralized. It is also entirely closed source. Being a web wallet it is also the riskiest type of wallet available, as well as suffering from a number of critical vulnerabilities in the past. No one should ever use it.

If you want to avoid all the crazy regulations, privacy invasion, security risks, and so on which come with centralized exchanges, then choose a DEX which allows you to trade directly peer to peer with other users. Bisq is great and has already been mentioned. Other alternatives include AgoraDesk and Hodl Hodl. See here for more suggestions: https://kycnot.me/?type=exchange

Any good DEX will minimize the need for trust by using escrow, smart contracts, or similar. Bisq for example puts the bitcoin to be traded and security deposits in a 2-of-2 multi-sig prior to fiat changing hands.