Drives are cheap, yes. Not everyone can upgrade or have space for upgrades. Laptops are fairly limited in disk size and it can be a hassle to upgrade to a bigger drive and there are plenty of heavy users who just needs that disk space. Bandwidth isn't the main problem. The time it takes to propagate and validate the blocks will be the main problem. Having a long propagation time introduces the problem of forks and they would have a lower security when getting any confirmations.

As to how much block size should the increment be, I'm not too sure. Segwit is a block size increase, it's not right to say that the block size hasn't been increased before. Though with the current mempool, perhaps 4MB blocks wouldn't be enough.

Unfortunate. I find that a common issue as well.

Only if you are going to restore your wallet. Once generated, it functions like any other addresses. Yes, you will be able to use those receiving addresses like how you would use any other normal addresses.

Electrum not looking for them only applies if you are restoring your wallet. You have to manually generate those addresses or increase the gap limit. The way Electrum works when generating a wallet is to follow a gap limit of 20 (for normal receiving addresses), which means it will keep generating addresses for the hierarchical deterministic seeds until it reaches 20 unused addresses. If the address is generated after the gap limit, Electrum will not generate those addresses. It is not lost, however just not generated yet.

Yes. Just remember if you're restoring from your seed that those addresses are not generated with the default gap limit and you'll have to change the gaplimit settings or generate the addresses on your own. They're still generated from your seeds so you won't lose it.

You're not wrong, but the Ian Coleman's code is much more straight forward than reviewing the firmware.

If you don't trust the entropy generated by your devices, then no software implementations can help because the RNG sources are quite similar and would not be verifiable as well. You will want to roll a dice 100 times and record them down. Use SHA256 on the 100 dice rolls then convert it by comparing it to a BIP39 wordlist. ColdCard has a nice python script for you which is as simple as it gets[1].

Some randomness is also needed for the transaction signing as well, unless you're able to see if they use a deterministic value for it.

[1] https://coldcardwallet.com/docs/rolls.py

I'd say there's no such thing as the "Best" wallet, the use case of each user varies and resulting in various optimal choices by the user. Electrum is obviously not trash but still far from the best. It has a terrible privacy issue but if you're willing to overlook that then yeah.

Which given the current transaction volume, would result in a partial decrease in the fees/size right? It's a free market after all, an increase in block space will result in a decrease in the transaction fees.

---

Block size was increased in a backwards compatible manner with segwit. Increasing block space excessively is doable, just won't garner enough support and could pose some issues with the propagation and the blockchain size as well. A better solution would be a second layer solution to accommodate larger transaction volumes without those tradeoffs which is what Lightning network does. Current Bitcoin isn't suitable for smaller transactions but lightning network certainly is.

Electrum doesn't allow changing font size, unless you modify the code (font_size=X sp). Electrum follows the system's font DPI so you'll be able to change it by changing your Mac's font size in the system.

Won't work. No one should be able to recycle or outright steal the coins from anyone else. Recycling coins does nothing and is very unethical. Certain coins are also deliberately burned or sent to coins with the intention of keeping them for long term storage. By having users make transactions solely for the purpose of moving the coins, you'll actually be introducing way more UTXO or Blockchain bloat. There would be an additional transaction volume on top of the current already limited transaction space.

Then you're barking at the wrong tree. Removing UTXOs doesn't help with the blockchain size. By deleting blocks, you're creating checkpoints where people cannot validate themselves. Current implementations starts from the hash of genesis blocks and build onwards, removing it periodically would be arguably less secure and result in the loss of transaction information from the past.

Not necessary for individual nodes. It is necessary for at least some nodes to be able to keep the historical data of the blockchain for everyone to be able to see the transaction history. If you want to validate the entire blockchain from the genesis block and not just trust someone on a block hash at some arbitrary height, then you will need the entire blockchain as well.

To create a transaction, go to https://coinb.in/#newTransaction. Put the redeem script, address and amount into the appropriate fields. As for the transaction fees, you'll have to calculate it manually. The transaction fees is the remainder of the outputs - inputs, you can use a change address if you want.



To roughly calculate the size, go to this page: https://jlopp.github.io/bitcoin-transaction-size-calculator/. Choose P2WSH, 2 signatures and 3 public keys.

After which, go to https://coinb.in/#sign and sign your transaction with the first private key. After that, take the signed hex and sign the signed transaction with the second private key.

Go to https://coinb.in/#verify to see if it has been signed and go to https://coinb.in/#broadcast to broadcast.

You can adjust the fee slider when confirming the transaction. The main problem with that is the transaction could take quite a long time to confirm. That is unfortunately the normal fees if you want it to be confirmed within a reasonable period of time, I would advise you to just wait for the fees to drop soon. You can monitor it with this site as well: https://jochen-hoenicke.de/queue/#0,24h.

As for the additional 0.5mBTC fees, are you using the 2FA wallet by any chance?

There's an official Live CD creator directly from Windows and I would think that it poses pretty little risk. To be fair, same goes for Linux. You're trusting that the hashes for the ISOs are legit[1] and PGP isn't always foolproof either, a well established web of trust would be far more reliable than just importing the PGPs on the website.

IMO, for most people using an OS that they are familiar with is a good choice. It isn't always necessary to complicate the process too much.
[1] https://blog.linuxmint.com/?p=2994

It was enabled since v3.X. If you right click your transaction, you should see an option to Increase Fee.

It won't. It'll actually even synchronize even more slowly. The synchronization is usually either CPU or HDD bound and having a faster internet connection often makes no difference. Connecting to 10 peers simultaneously to download the blocks in parallel would be much more efficient.

If you still want to try to fix it, try running it and add -debug=net as the argument. It will log the more specific network messages and perhaps gives us an idea on why it gets disconnected after the initial connection.

Connecting solely to a single peer will not speed up your update and it could actually slow it down. If you're talking about synchronization, multiple peers can do it in parallel and if you're talking about normal block relays, then there will be an additional hop through that node before it reaches you. It will not result in any speed increment whatsoever.

For the node that you're attempting to connect to, does it allow incoming connections? You should only use connect=IP address in bitcoin.conf and that should work fine, not addnode. Is the configuration loaded if you check the debug.log?

I've just done a short test with my Bitcoin Core.

I synchronized the blockchain completely from the start and after it was done, pruned it. Unpruning it requires a reindex which we already know. I'm currently resynchronizing it and it appears that Bitcoin Core wipes the entire chainstate (reasonable since you have to run it with reindex flag) and retains the final X GB of blocks. This means that the validation will happen again and happens just as if you're synchronizing from the start, just that the final X GB is not redownloaded but still has to be built. AFAICT, it will actually take roughly the same time, no matter how much you prune.

Can you try installing this update?
https://www.microsoft.com/en-us/download/details.aspx?id=49071

It's for compatibility for the older versions of Windows when running Electrum.

** And install this: https://www.microsoft.com/en-US/download/details.aspx?id=48145

Probably not the issue but it's worth a try. It's not running when you check your task manager is it? Did you check your Toolbar if it's minimized by any chance?

It's a known fact but people seems to make a big deal out of it. The way POW works is to provide security through sacrificing some form of resources in return for it's security and a large part of it for Bitcoin is the electrical usage. How much does it cost to print the dollar bills around the world? Perhaps close to the amount Bitcoin uses? Bitcoin is responsible for billions of dollars of volume per day and it is totally reasonable for the cost to be prohibitively high such that people are unable to exploit it. The CO2 consumption probably assumes the worst case scenario; for the electrical sources to be non-renewable and a high production of greenhouse gases which is untrue. More and more Bitcoin mining functions on the surplus from renewable energy sources[1] and helping to fuel the renewable energy market as well. All the energy is not wasted, it is used to secure the network.

Now, to address the statement about Tesla. Tesla's goal is not primarily to preserve the environment. If that was their goal, their electric cars wouldn't have been affordable and they would be producing electric buses instead of mass producing cheap electric cars to exacerbate the current problems with traffic congestion. The environmental rebate is okay; their electric cars are indeed efficient. They have put in billions into R&D to tackle the EV markets. To say that they are solely focused on zero emission (or rather zero environmental degradation) is completely wrong.


[1] https://cbeci.org/cbeci/comparisons

I really cannot recommend anyone trying to dumpwallet and importing everything into Electrum. Sure, it could be faster but at the expense of privacy.

If the wallet.dat is from a pretty old backup, you'll probably be looking to import tons of keys if OP is a heavy user or more addresses were generated after that backup. If you want to be sure, synchronizing Bitcoin Core is the only way, not to mention that it is difficult to import a huge list of addresses. My older computer took a day to synchronize and my newer one with NVMe took 4 hours. It will certainly not take weeks and that is the only way to be sure that it is empty.

---

Nevermind missed out on this:

You seem to be assuming that there is only one use case for Bitcoin and that ends after you purchase your Bitcoins. Having a bunch of addresses linked to a single identity is a threat to privacy, that is the truth. It doesn't matter who you are, if someone links a group of addresses together, that is more than sufficient for someone to start linking transactions together and potentially expose your identity with any lapse with the subsequent transactions.

---

That is your biggest threat to privacy and again, I'm not sure about your trajectory of arguments when we come to this topic. You can't really be too paranoid when we're talking about privacy. But I respect your opinion, people view privacy differently.