Renewable energy is not perfectly carbon netural. Renewable energy is better than traditional fossil fuel because it incurs less carbon footprint than those but it doesn't mean that it doesn't incur any at all. Building resources specifically to cater to those operations will inevitably result in even more pollution than not having it at all. This is a rather weak argument because the entire profits of Bitcoin mining cannot possibly impact the development of renewable energy to a noticeable extent.

Besides, miners gravitate to cheaper energy. If coal is cheaper than renewable energy, they will use coal or vice versa. All of the power plants have limited capacity and it would actually make far more sense to give those to the locals rather than for Bitcoin mining operations.

That is fine. Shamir Secret Sharing allows full recovery with only a partial number of shares, and that is why it is acceptable for the secret to be split.

Generally, you want to create Shamir Shares in a secure environment and that would automatically rule out doing so remotely because that is an entire path for the attacker to exploit. You would first need to ensure that your remote environment is sanitized and your connection is secured.

Afterwards, you would probably want to stick to a known standard, SLIP39 is one that I would recommend. Here's a Python tool that Trezor uses: https://github.com/trezor/python-shamir-mnemonic/. You should try your best to find one that is more refined rather than this but I can't find any other reputable code myself.

That is a feature of the seed. It is about as secure as your private key, because the number of permutations is similar with both.

Nope. Unfortunately the most optimized code ever cannot bruteforce at millions, much less billions of times per second.

[1] https://btcrecover.readthedocs.io/en/latest/GPU_Acceleration/
Nothing. However, you have correctly demonstrated why we have a 12 word seed instead of a 3 word seed.

A simple demonstration would be using the word list to randomly generate a 12 word seed and iterate through the permutations and determine the number of iterations it takes to find that exact set of 12 words. The problem is there are 2048^12 (5.4445179e+39) possible permutations of it. You need to iterate at a rate of (10^30) to be able to find a seed in 5 centuries. That would be a factor of 21 over a billion, which is impractical, especially given that we established that the overheads makes this a very inefficient process.

Nope. Python is notoriously slow for loops and there are faster implementations out there. Depending on your type of loops or iterations, the actual rate will probably be far less than a couple of million per seconds.

There are actually tons of bottlenecks to be considered when you are bruteforcing seed phrases. First of all, you have to consider that various key stretching functions are used in the various steps of the process which slows it down significantly, because they are far more intensive than just generating random 12 word phrases. You are unlikely to really achieve speeds anywhere near feasible.

The other notable bottleneck is trying to find the addresses with any transaction history or funds. You have to get a set of all of the used addresses on the blockchain and search through it which involve both storage and computational complexity when you are searching thousands or billions of seeds per second.

No. Because legacy addresses are always encoded in base58, so there is no way for you to encode in base32 and expect it to be valid.

Bech32 uses a special encoding and you don't have to use base58 to get a valid address.

Each of your addresses consists of checksums. When you generate that specific address, the last few byte corresponds to the checksum. Removing or otherwise changing any characters in the address will result in a checksum mismatch.

If you deliberately remove z from addresses without doing anything else, then your checksum will most likely be mismatching because your wallets always uses base58 to check for the address.

Not possible. You can remove and change more characters for the checksum to be valid but that would be too much work and you won't be able to see the private key.

You cannot modify or remove any of the address to any degree and expect it to be valid. Due to the avalanche effect, any modification to the private key will result in the address being completely different. You have to specifically search for an address that does not include your desired character from the onstart.

1) Yes. But certain addresses will be invalid because they will fail the checksum for the address generated.

2) Base58 goes from 0 to 57. Base57 goes from 0 to 56. Hypothetically, if there is a value with 57, then it would be considered 5 and 7 instead of 57 because it doesn't exist.

3) Not sure what you mean but you can easily create addresses without certain characters if you intentionally search for it.

There is no point of explaining and teaching them beyond what is necessary. If they are technologically illiterate to the point which they can't even use Paypal, Venmo then you would have to teach them those first.

Having to use or adopt Bitcoin does not necessarily mean that you have to understand all the nitty gritty details and it definitely doesn't mean that they would have to engage in any conversations about Bitcoin within the forum either. So long as there is an application that allows them to use Bitcoin like Paypal or basically any other payment processor, then they would be fine. There is little interest in the general population beyond how to use it.

It should not become a watch-only wallet without the user doing something to it.

How did you create the wallet? Do you remember having to type in your address into Electrum or were you given a 12 word phrase?

Not very.

The protocol that Electrum uses isn't designed to enhance privacy but quite the opposite instead. It doesn't use any methods to try to obfuscate your data whatsoever. It is totally possible for the server to jump from one to another with each address but that is ridiculously inefficient and gets more inefficient as the number of addresses increases. It does nothing against topological leaks given the limited number of servers and the possibility that a malicious agent runs multiple servers.

An example of a wallet that does this would be Wasabi but it is done with a combination of BIP 158 but Electrum just sends the Scripthash straight up.

There is a substantial difference between the ease of access to Bitcoin or Crypto and the willingless of adoption by the general population.

Fiat is a far better alternative as opposed to crypto mainly for a few reasons. Namely: Volatility, Ease of use and general reluctance to change the status quo. If El Salvador is of any indication, Bitcoin is not a sustainable currency where volatility is of any concern. It can be worse than the major currency in those countries because of its volatility. You can still argue that their currency may be subjected to hyperinflation but USD or major market currencies are far more stable. In countries with low literacy rates, you have very few of the people who are willing and able to use technology to their advantage. They are far more likely to be willing to maintain the status quo due to the lack of understanding of alternative currencies.

The problem is not with the ease of access but it is an entire myriad of problem that plagues the lack of adoption.

Multisig transactions has multiple signatures, or one with an aggregated key in the case of Taproot. It is an easy implementation but it doesn't solve or address the root of the problem. You will always run into problems and continually try to catch up with the newer format by trying to validate with the keys instead of the spending script. We can better handle this by eliminating a ECDSA based validation (ie. validating individual keys and signatures) because that would introduce too many limitations.

Current solutions only provide a way to sign and validate with the ECDSA keypair, but it doesn't validate the address per se.

That is actually what Electrum is doing when signing with Segwit because Bitcoin doesn't allow it (No associated private key). However, that is not what we're getting at and treating addresses as entities with a single public key doesn't allow script based addresses, or multikey implementations to sign messages. You do need the address to cross check and that is usually provided by the user.

BIP322 is an implementation that attempts to solve this but it is at a draft stage.

You should be able to. Txhash doesn't provide sufficient information for you to broadcast anything. You need the raw transaction, not just the txhash to broadcast the transaction.

If you can somehow rebroadcast using the Txid, then chances are your transaction is already propagated.

Doesn't sendrawtransaction suffice for the purpose? Just pass a signed raw transaction in hex to the RPC.

This is subjective. Even if you don't click on any links, run any suspicious software, there are still ways to compromise your computer without and zero day exploits are not uncommon as well.

You shouldn't use online wallets. You will be given the seed at the initialization of the hardware wallet. That can be imported into many of the compatible desktop wallets to restore all of the addresses.
Same as above. If you'd like, certain hardware wallet provides a limited warranty to cover for damages.
Not really. Hardware wallets are operated in a sanitized environment and it is difficult to compromise that environment. This is why they are secure, because they are designed for specific tasks and are intentionally secured to execute and accept certain commands.

Disconnecting your internet periodically actually does nothing to improve your security. Malware would just wait for an internet connection to relay any data back to their C&C. Your best case would be to ensure that the wallet never gets online and use another device to send the transaction data, aka. Airgapped wallet.

The parameters are designed to prevent unnecessary resource usage by having to receive and relay these free transactions. While your mempool will still kick the transactions from the lowest fee once it hits the size limit, the mempool fee rate will still increase and overwrite your parameters.

If not, then your mempool will contain unnecessary transactions that wouldn't be mined regardless.

Very marginally. Most of the transactions shouldn't require RBF especially with periods of low fee rates and low fee volatility. Miners are known to be fairly slow at signalling support for various different protocol upgrades so that by itself already means that there is low incentives when there isn't a lot of tangible impact to their own earnings. It does come with some testing and manpower which can be insufficient for them to really change it.

I'm not saying that they won't do it, but then there will definitely be time lag.