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.

Yup. Great that it is working for you!

Nonetheless, if you have the time, you can try some utility to test your memory, CPU and your disk and see if there are any defects in them. Blocks shouldn't be invalidated without the user specifically marking it or if there is a block corruption. It has worked once previously but it didn't for another and I didn't manage to get that user to run any tests.

If you're connecting from your computer to that VPS, then it is an outgoing connection and hence the stats would be correct. For you to have an incoming connection, you need to connect from that VPS to the node that you're using. There is no connection that would be both incoming and outgoing as it would serve practically zero purpose.

How many blocks have you created? The thing is that Bitcoin Core expects more than 2 blocks, as seen in the 1.47% from synchronizing block headers. It won't do any IBD without having all of the headers first.

Go to Window>Console and type this:


If it doesn't solve the problem, then your database is corrupted and you need to reindex. It can happen due to hardware failures; would be good if you could test your RAM for any inconsistencies.

Connections are bidirectional so its polarity shouldn't play a factor if no information is being transmitted to and from a node. Can you add debug=net into the Bitcoin.conf and see the network messages?

It should provide a picture of the interaction between the nodes and if any messages are being communicated.

Yes. That is the bech32 standard (bc1). It'll be wrong to generalize them as xPub as there are many variations of the master public key.

Depends on the type of modifications I guess. Most of the components (AFAICT) are covered with epoxy and there is a testing for any malicious data during start up.

Hmm? The attacks bypasses the PIN and would just reveal everything. I don't think Coldcard uses passphrase as an encryption, or else it would have more than a keypad, or perhaps I haven't used it enough . Exploiting the SE is probably the most crucial part of the attack and if it succeeds, then I don't see much deterrence against physical attacks.

---

FWIW: https://twitter.com/nvk/status/1377710160450293763.

Tons of other stuff on that Twitter but yeah, this is probably the only important one.

Bitcoin-qt was rebranded as Bitcoin Core, if you had any doubts.
Core should still be pointing at that directory even with an upgrade, it's the default directory anyways. In the case that it doesn't get directed at the correct directory, you can just change it manually with a command. Bitcoin Core will always load the wallet.dat that is in the data directory.
 
You shouldn't have to resynchronize.

You can get a redeem script of the multisig address if you're able to get a transaction for which the inputs are from the multisig address. This gives you all of the possible public keys that are in the redeem script. Master public keys are not located in the redeem script or at least I've never seen any redeem scripts like that. For wallets that uses xpubs to generate multiple multisigs in a HD manner, each of the redeem script contains the public keys of the addresses that are generated deterministically from the xpub and at the specific indexes for example the first address contains the public keys from the first address generated by the 3 xpubs, and so on.

Let me know if you need an example of a redeem script from a transaction.

No you can't. If you're using xpubs to generate those multisigs, the wallet actually uses the public keys from each of the individual xpubs and the xpubs are never defined.

---

Redeem scripts are not revealed to others unless in a transaction. Your addresses are hash of the redeem script.

Basically the whole point of a hardware wallet; if the physical security fails, there should be features to prevent this types of things from happening and also why many hardware wallet manufacturers includes a secure element with their devices to minimize the risk of any physical attacks. Saying that a hardware wallet shouldn't be in someone else's hands is the premise of any security and that is not how people should solve this kind of issues.

ColdCard does put epoxy over their components but apparently it isn't enough.

How long is the delay? If it isn't more than a few minutes, then it should be fine. Blocks are mined (avg) every 10 minutes anyways and the fees wouldn't dip that much just after a single block is mined.

The reason I don't usually recommend people to use jochen's fees is that it is much less obvious for the not-so experienced and would probably cause some confusion as there will be small dips in between blocks and give user a somewhat misleading idea that the fees has suddenly dropped. Mempool.space is much clearer by comparison as it has far clearer details.