Any blockexplorers (blockchair.com or Blockstream.info) will show you the blocks as well as the transactions.

Looks like an error. The last block was mined over 10 minutes ago and there was never a gap that big. In fact, the chances of that happening is actually astronomically small barring any changes in hashrate.

I do think that the idea *could* be possible but the problem is with reaching the consensus for the variables that you've added. The network's time can deviate between node to node by quite a bit and it is difficult to synchronize all of them without a reference to a central server. Transactions aren't relayed instantaneously and there can be a delay between the nodes seeing it.

As for the benefits, I fail to see how this would increase the security at all. Given that you don't have to mine for 8 minutes, this makes it such that all of the work is done within the 2 minutes which would be much lower than the 10 minutes of continuous hashing that we have right now. It wouldn't bring older ASICs back into the game as the profitability would remain roughly constant; think of it as Bitcoin having to decrease the difficulty retarget to make 2 minute blocks. Standby power could still be fairly massive and would be much more inefficient than continuous hashing.

Coinbase outflows are not indicative of any trading activities as they're totally independent of that. If you're talking about trading Bitcoins, you should look at the trading volume

Outflows can only tell you the amount of Bitcoins that were transferred out of the exchange. Sounds like some people can't really read the text on the graph.

I doubt it would really be worth it for them. Financial sanctions can be unforgiving for certain countries but Bitcoin mining would hardly contribute anything to their GDP. It would be tough to mine Bitcoins when your country doesn't even have a stable supply of electricity and your focus is on developing nuclear weapons. Training people for cybercrime is far more lucrative like what some of their APTs are doing.

Probably not. You're ignoring the fact that most of the expendable wealth are concentrated in those with power and the normal citizen probably wouldn't even use Bitcoin. It is not an accurate way to estimate Bitcoin's usage in a specific country.

Yeah. In the earlier versions, the validation logic doesn't exclude the genesis block or at least that is my understanding of the code.

Do review the codes and let me know if I'm missing something.

A node doesn't find a block, miners do but miners can be using a node as a source for the information and to propagate their blocks.

Generally, mining involves double hashing the block headers to find a hash the satisfies the target. The block header contains a few elements (block version, previous block hash,  merkle root hash, nonce, timestamp, target, etc) and they are concatenated together to form a string which is then hashed twice, SHA256(SHA256(Blockheader)). The miners will determine the coinbase transaction as well as the transactions that they wish to include and create the merkle root. Afterwards, they'll hash it to form the hash of the block header and check if it satisfies the target. If it doesn't they will increment the nonce/extranonce and try again until they're able to generate a block header hash that meets the target.

---

Transactions that are included in a block are determined prior to the hashing, they cannot be added after the block is found.

The nonce is an arbitrary variable that is changed in order to be able to generate a different hash every time. It doesn't have to be determined as the user.

The miners are always mining, when a new block is found and propagated, they will reassemble a set of transactions (as some of the transactions may have already been included in the block) and change the previous block hash as well. Bitcoin mining is not a puzzle, despite what people make it out to be.

1) It'll defeat the purpose. If you're looking for an airgapped setup, then you should never connect it to the internet or expose yourself to unnecessary attack vectors. Just use PSBT feature on Electrum to transfer the transactions back and forth using either a QR code or USB drive.

2) Your seeds are already backed up by writing it on a physical medium. The backup version doesn't matter, unless you're modifying details (labels, transaction description, etc) in between the backups and you're looking to still access them in the future.

A valid block has to have at least a target above the minimum value as stated or a difficulty of 1. If it has zero difficulty, it is invalid.  

Probably nothing. I'm not sure whether Core skips the checks for a valid block when it comes to the genesis block. I'm not too familiar with the codes for Bitcoin Core but I'm pretty sure I've read somewhere that the genesis block still has to have sufficient PoW and was validated as per normal for at least in the first few release. Perhaps someone can add on to this.

The genesis block is still a valid block and thus still have a valid PoW. The difficulty has to be at a minimum of 1 or a target of 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff.

This script outlines the process it takes to check for the version and the keys used for decryption;  HW wallet's xpubs or the user's password[1].

[1] https://github.com/spesmilo/electrum/blob/d86138a1a5a144b5adc32ef8bd1ff7afd860927d/electrum/storage.py#L118

I can't tell what the problem is unless I take a look at your code. Did you modify the checkpoints as well as the minimum PoW?

Without any information about what went wrong when Bitcoin Core invalidated it, it'll be hard to pinpoint the problem especially if your hardware is doing fine.

However, I'll consider USB external drives far less reliable than SATA ones. The controllers that I've had for my drives were not exactly the best though they were fairly expensive and well known. Bitcoin Core tends to magnify the problems associated with them due to the nature of the program and how it interacts with the disk. Assuming that your data directory is on the external SSD.

Electrum encrypts the private keys and seeds differently from the wallet file. The seeds and private keys are encrypted with AES-256-CBC but the wallet file uses ECIES which allows it to be written and encrypted without the need for the passphrase to be entered again.

https://github.com/spesmilo/electrum/blob/1b763b4a3c6a456c6b944c7cd7493a7ec1a54a12/RELEASE-NOTES#L841

The game theory works economically where the actor cares about his financial profit. However, if you're going to factor in state actors, they're more likely to have non-economic related incentives which can't be measured in monetary terms.

The potential profits from 51% Bitcoin is not a factor for a state actors in furthering their agenda. Given how high their GDP is, the attack would probably be a pocket change. However, they're still bound to the limitation that I've mentioned.

Where did you download your Electrum? Did you verify it?

Go to Tools > Preferences and enable save log to file. Afterwards, try to send the funds again for the Electrum to crash. If it still crashes, go to %appdata%/Electrum and see the logs folder. Check the logs pertaining to the crash by opening them with a notepad. Check if there are any exceptions thrown by Electrum or any errors.

For this censorship to be effective, China government has to control at least 51% of the network's hash rate. Note that while a good percentage of the hash rate is located in China, it doesn't mean that the government has direct control of the hash rate. Something like this would take some time to plan and would probably be leaked out at some point.

The argument against this is the same as the one against 51% attacks. There is a lack of incentives and that the attack would be fairly shortlived. Once the attack becomes known, it would be a matter of time before people switches to another crypto or the community decides to go on another fork with a different PoW. As such, there is a limited effectiveness of the attack and China has just destroyed their fairly lucrative ASIC industry while not really achieving much. For the above scenario, I'm assuming that China has in fact 51% of the hash rate and is able to consolidate them in the first place which is fairly hypothetical.

Key derivation used is PBKDF2 and it is salted, IIRC so no rainbow tables. There isn't any real risks with moderately strong password. However, as with all backups, if someone gets his hands on it, then it'll definitely be less secure than it should be. Use a strong and unpredictable password and keep it safe. While backing up the seed will eliminate any electronic failure affecting the backup, it'll be better to have both if you also value your TX descriptions, labels and your LN channels.

Yup, the labels are only in the wallet file though. The backup wallet functions backs up your wallet file and exports it in .backup extension.

Either using that or just directly copying your wallet file from Electrum's data directory is fine.

The description is used to indicate the purpose of the transaction to provide better clarity for the user. It is not associated with any addresses and thus does not affect the labeling of your own addresses.

If you want, you have to label your addresses manually. Note that the labels are only visible to you and local to your wallet file. Unless you have your wallet files, labels or description won't be covered by seed backups.