The pre-generated keys are all invalidated upon the generation of a new master private. The updated wallet.dat with the new password will then generate another 1000 addresses using the renewed seed.
The point of changing the password is to ensure that people would not be able to steal any coin if they get ahold of your possibly compromised or otherwise insecure backup. It doesn't make sense if you're trying to secure your wallet, yet someone else is still able to steal your future coins. You are not supposed to use the previous backup for any of your transactions. That is your responsibility.

Bitcoin Core does not support a mnemoric seed. The purpose of the wallet is to enable greater convenience to its users while it still functions on previous logic, where the keypool should be refreshed with a password change.

The master key might not be able to generate all the addresses in the wallet precisely due to the reason above. Bitcoin Core is meant to use with its wallet.dat and the extraction is better suited for advanced users. A wallet.dat backup after each password change would suffice.

Wait what? The edited quote is correct. The original statement is slightly wrong there. You can't do anything with master public and a child public key since that is basically freely accessible and it would be a serious vulnerability.

With hardened keys, there isn't master public keys to begin with. It can't be an issue if the cause of the issue doesn't exist.

The transaction ID doesn't show anything on the blockexplorers. Your Bitcoin Core client did not broadcast the transaction to the peer. Try to look at the transaction information and check if its seen by any peers. Either the fees are too low or the transaction has not been propagated.

Using your Bitcoin Core wallet, can you post the transaction ID on here? Or you can just check blockexplorer.com to see if your transaction is there.

On your Electrum wallet, can you go to the Console and type the command:

Replace the address accordingly.

If it returns true, you're fine.

Likely not. Other than the need for perfect information, an implementation like this would require each node to allocate more resources and validate more blocks that are relayed to them and has a valid POW. By changing the block intervals, you would have to consider the supply limit of the coin. The block halving rate could potentially occur much sooner.

It's more of a hassle to implement a mechanism like this than to just determine the equilibrium of the orphan rate and the block interval and to put a fixed interval to it. 1 second blocks would not be viable for now.

Bitcoin Core supports Bech32 since 0.16.0. 0.16.3 is also the version that users are supposed to update to.

Most exchange/services don't support bech32 because of the problem with backward compatibility since certain wallets don't recognise bech32 addresses. Blockchain.info is the biggest blockexplorer out there and they don't support indexing of bc1 outputs yet (they do display), while others do display and index bc1 outputs.

It has the same difficulty of generating an address that has transactions in it.

When you generate an address, there is an equal probability of you generating any address (used or not). The whole process basically involves you starting out with an ECDSA key and ending up with an address. To generate a specific address, you need a very specific ECDSA keypair. Without that, the ending address will be different.

Much more orphans. If you're using POW, the delay in the block relays would be much more significant than the block interval.

If the number of required confirmations remains the same, the security of the merchant accepting the transactions would decreases significantly. As compared to before, less resources is required to attack the chain and double spend your own transaction. I can't think of any significant advantage to lowering the block time to that amount.

Possibly more than half of the hashrate would be gone. Anyhow, I honestly doubt the others would have enough resources to outpace the remaining network. There are only that many ASIC machines and I doubt any other entity would possess that much machines without using it at all, the sheer cost of it would be astounding. The block interval is likely to be twice as long without any further attacks. It would surely drive people off of Bitcoin.

But the more important question is; Why would you care about Bitcoin when literally everything that is electronic has been taken out? Bitcoin should be least of your worries when the infrastructure of your country is wiped clean

Personally, running a full node is pretty hassle free. I do update it occasionally and leave it to run by itself for majority of the time. I've never had any downtime and the set up was fairly quick. For Windows, Bitcoin Core is literally just a simple program install and Unix systems do have a script to use.

It's not exactly pointless to run your node for only a few hours at a time. When you run a full node that allows inbound connections, you are still allowing others to use your node to synchronize or as a node for their SPV client. It could potentially still help to strengthen the network and help others to sync. Doesn't seem like it has downsides to it. When you turn it off, nodes will simply find another peer to connect to.

To be fair, while its definitely very beneficial for the network to have more hashpower to secure it, the centralisation of the mining power isn't all that great. Not all of the pools listen to their users and they are free to choose whichever transaction to mine, amongst other things. The mining industry is extremely stagnated right now and it seems impossible for anyone new to join.

I don't disagree with your point on people running SPV wallets for their convenience but I do fail to see how non-mining full nodes can be a liability. It's not too expensive to be running a full node; old harddisk, spare computer/even raspberry pi would be enough. If you care about Bitcoin, running a full node should be something on your mind. It gives you security advantages over SPV clients and helps the network by validating blocks and transactions.

SPV client relies on full nodes, mining or not. An abundance of full nodes does, at the very least, help to alleviate the risk of a sybil attack on SPV clients and that is beneficial for all.

No. The blockchain relies on the fact that at any point in the chain, the blocks in the chain must be connected to each other. This ensures that each and every transaction can only be included once only. If there are two blocks at the same height, its likely that both of them could contain different transactions which spends the same UTXO. Hence, allowing for double spending.

You can actually obtain the funds back since the address format is literally the same, at least for some addresses. The problem is that the retrieving of the funds requires the private key of the address and there is no way the payment processor will give that to you. If they are unwilling to recover it for you, your funds are gone.

Bump!

It's not wrong to say that there could be more than 100k full nodes in the network. Full nodes validate all of the blocks in the blockchain but they can either be a "listening" node, or not. Bitnodes measure the number by attempting to find IPs with the port open and send a message to validate their client version. They can't do this to listening nodes unless the listening nodes willingly connect to them. Its totally possible that there could be many many more nodes which doesn't have port 8333 open.

Go to canyouseeme.org and check if your port is open.

Are you behind any proxy/VPN for your browser and your Bitcoin Core? Bitnodes tests the connection using your IP that they get when you visit the page. If you're behind a proxy or VPN, they would end up testing the wrong IP.

Selfish mining basically describes a miner withholding the blocks and delay the broadcast of the blocks. Its an attack that harms the other miners as they tend to waste time on block that would never be on the longest chain. The concept itself assumes specific conditions which might not hold in the real world and that attack is not the biggest problem. It seems to be different from what you are describing.

The network cannot know what the hashrate is at any point of time. The network approximates this based on the last 2016 blocks for the difficulty adjustment. It would be incredibly inaccurate if the sample size decreases as blocks could be found within seconds of each other. I doubt miners would collude to hash at a slower rate too; they are all after their individual profits and having a smaller difficulty means that it would be more profitable for someone else to mine. I can't see how they would coordinate in such a way that everyone benefits and those who are not participating won't interfere.

You'd have to email TrustedCoin directly. Electrum does not hold any keys nor 2FA OTP for its users, they're just the developers. TrustedCoin could provide you with the key to your 2FA or help you sign your transaction but the chances of it aren't guaranteed.

If it ships to your location, then yes.