Not discarded. By BIP39, the seed must have an entropy in multiples of 32 so there is no limit to how many you have to use. After all, the mnemonic is passed through a KDF for the actual seed to be used so the length actually isn't limited. Your addresses only has 128 bits of security so people would probably look to compromise the individual addresses instead of seeds, they're much faster to generate.
Nothing happens. You won't generate any invalid addresses.

As said, it passes through the KDF so the checksum only serves to provide a check for typo.

There really isn't any reason.

Unfortunately, Electrum never supported nested Segwit addresses. A workaround would be to generate a BIP39 seed and import it into Electrum. That introduces too many points of failure and I generally recommend against it. If you want compatibility and also Segwit benefits (to a smaller extent), then you should use another wallet instead of using the workaround.

It is. I would argue that it becomes an altcoin. The foundation of Bitcoin has mostly been left unchanged and it probably should be, barring any vulnerabilities of some sort. The game theoretic model of PoW is basically as good as it gets; giving up resources for the security of the network.

If you're finding another scheme that can secure the network in the same way, then the miners that we have today will be out of the equation. That is not going to sit well with them in the first place. Perhaps we should change PoW, if such a great scheme comes about but the fact that you're never going to get any significant consensus with so much conflict of interest makes it hard for us to agree to a change. I wouldn't bother, PoW is fine as it is. People needs to start attacking actual climate change contributors for it or just go and penalize miners with carbon tax. That's all.

Yes. On your account, it might be $500, as you didn't wiithdraw the $500 in Ether. However, the funds in that deposit address can be 0 still.

The deposit address doesn't belong to you; it is just an address that is associated with your account and any deposits would be credited to your ByBit account. Any exchanges within the site is reflected on the backend and in your account. The funds in that address does not matter to you as it is under their control and they can do whatever they want with it; consolidating it or sending it to another address. What is important is that your deposits are all credited correctly, the balance of your deposit address does not necessary matter as the balance on that is often different from your own account on that site.

Check your transaction history on the site. Has everything been credited correctly?

The thing with most services is that anything done to the account may not necessarily reflect a transaction to or from your address. For example, if I choose to sell Bitcoins on an exchange, the funds in that address may not be moved immediately but it is regarded as sold on the exchange and that my account balance is now in fiat instead of Bitcoins. The balance on the address is not reflective of your current balance in your account.

Thanks. I overlooked this.

Generally forgetfulness, amnesia or just any other thing that can affect your memory, the list goes on.

I definitely wouldn't take the risk and blame myself later on for forgetting a seed phrase. Just having a physical copy of it and keeping it safe would be fine for most.

Side channel attacks shouldn't be your main concern, secp256k1 libraries has mitigations against most of that so you'll be mostly safe. Problem would be with malware or some $5 wrench attack.

Privacy concern would be that it would be obvious which testnet addresses and mainnet addresses belongs to each other, public keys would be the same. I wouldn't do so though, leads to unnecessary confusion as well and perhaps leads to unnecessary risks depending on what you're doing with your testnet. It's really not difficult to use two separate seeds and it's quite dangerous for people to be memorizing seeds.

Rescan, not reindex.

EPS is okay for most uses as it just serves as a data source for Electrum clients, so there really isn't anything to criticize there. If you need your personal server which is easier to setup and has lower resource requirements, then this is it.
ElectrumX is the most common implementation used by Electrum servers.

Voluntarily locking your own coins with time as a parameter doesn't affect security in the slightest. It depends on how you generate and handle the keys for that.

If you want something to lock your coins for a long time, don't use nLockTime or any mechanism like that and pre-generate a transaction. It is not ideal for that as you cannot change anything in the transaction. Instead, use OP_CLTV and include it in a scripthash address. You'll be able to "unlock" and spend the funds after a specified period of time provided that you have the required key to unlock it.

Bitcoin is not a get rich quick scheme. You're treating it as a speculative asset and with that, most of them tends to experience loads of volatility, Bitcoin included. Elon Musk isn't the only reason why Bitcoin is crashing, China is as well.

Not saying that it's great that Bitcoin crashes but at least you're just eliminating those who don't see Bitcoin's utility in the long term. It is stupid to invest in something this risky if you can't afford to lose it.

Hash160 is secure by itself. P2SH is susceptible to collision (with birthday paradox) as the complexity is 2^80. This means that in the far future, it could be feasible for someone to be able to obtain a collision for a given script hash address.

It is not that big of a deal. P2WSH is far more efficient and Taproot is coming out as well. I'm not sure whether there would be any plans to phase out P2SH but that is likely not the case.
Nope.

You mean P2WPKH?

The rationale behind using SHA256 for P2WSH instead of HASH160 is stated here:

Nested Segwit (Multisig or not) is P2SH, not P2WSH. The standard is defined before we've decided on this and is different, there is no need to change that. There is no need for us to introduce a longer Segwit address for P2WPKH as well.

You need to do so in the exact order. As you've said, the script is hashed and changing the order also changes the hash. That is why we rely on the redeem script.

In your terminal, type in this:

After that, copy the string and type in this:

Replacing each of them accordingly of course.
The tool basically just pushes the TX to the peers that it sees, usage is included in the readme. Just using walletbroadcast=1 should be fine. I don't think there is any privacy repercussions.

Please avoid creating so many threads for the same issue. You can just continue from your first.

Yeah. 0.21.0

EPS was modified to broadcast the transaction directly to the peers within Tor and I remember that this was implemented quite a long time ago. I'm not sure what are the justifications, if any that would still hold water. If the user is running Core on Tor, then using the EPS would achieve the same privacy with running Core on Tor alone. Since its dependent on Core anyways.

I'm sure mining farms cannot afford to leave any working ASICs undeployed. CBECI's estimation is as good as an educated guess and that is all we can work with.

There are far too many factors that can (and will) affect the electrical usage of Bitcoin. Any noticeable decrease in energy consumption of Bitcoin is NOT enough; environmentalist are not happy with high perceived electrical usage in the first place. There is no reason why they would be content with say 30% decrease in electrical usage. When it gets to something that they're content with, Bitcoin isn't secure any more. Arguably, constantly phasing out and replacing ASICs will have significant environmental impact as well. It is not a one-dimension issue as media perceives it to be.

Economic-wise, the electrical consumption will probably not change and remain at a certain equilibrium.

Bitcoin Core offers a way for users to interact with it using their hardware wallets: https://github.com/bitcoin-core/HWI.

You need to rescan if you're querying any addresses unless you specify otherwise. Blockexplorers and other sites allows you to do so instantaneously as they parse the blockchain for the addresses and index them. Bitcoin Core does not index by addresses.

I think the rationale behind that is to improve on the privacy of the node. The initial consideration appears to be preventing the wallet from automatically rebroadcast transactions. Since the privacy and the rebroadcast logic has been worked on and improved in the recent versions, would this still be necessary?

When it becomes feasible and an attractive substitute for fiat or any other payment methods. Unfortunately, Bitcoin as its current form doesn't justify the replacement or even a substitute for most brick and mortar stores (perhaps LN can be but most merchants actually prefer on-chain TXes). The adoption for digital services is there, mostly due to the fact that Bitcoin TXes are harder to reverse than MasterCard, Visa, PayPal, etc. The waiting time for a confirmation is also not much of a concern.

Unfortunately, the nature of cryptos makes the value quite volatile. If it somehow stabilizes some time in the future, then more people would consider exploring it as a currency rather than a speculative investment.

Or an increase.

Miners always attempts to maximize their profits and introducing a more efficient ASIC would result in the sustained electrical consumption for that difficulty epoch (and steady increasing as the newer ASICs are deployed). ASICs are usually never retired until the revenue = cost, among other factors but a more efficient ASIC would likely not result in any significant decrease in energy usage.