--user flag installs Electrum for the user that ran the command. Were you using a privileged command line or did you run it with sudo?

Installing it with sudo (and without --user) will install Electrum for all of the users within the system. There isn't really any privacy or security risks, other than the other users will have Electrum installed as well.

Current bandwidth is more than sufficient to download the entire blockchain within a few hours at max. Problem is that there exist a ton of bottlenecks which can't be eliminated that easily. I don't think there is a particularly huge issue with an increase in the rate of transactions in the future; assuming transactions can take place off-chain and we can sustain an increase in the efficiency of the various components. I think Moore's law isn't that relevant anymore. We're already reaching 7nm nodes.

There are more concerns within the system other than your bandwidth and your HDD.
Reducing block size is counterintuitive. We need bigger block size to support LN, even if we were to scale to our closest payment system competitor. It's quite evident that on-chain capacity isn't ideal right now, outright blocksize increase cannot be the only solution.

Are you by any chance having any Electrum instances open while you're editing and saving the file? Electrum writes to the config when the user closes the client. Ensure that your Electrum is not running while editing the config.

Scrutinize the settings and don't blindly follow whatever they're telling you. For eg. disabling RBF.

There isn't any threshold, or any figures which I know could affect Bitcoin's operations given the failure of the nodes. Full nodes mostly operate independently without trust on each other.
Actually, he did state that the network would eventually be sustained by specialized server farms with the average users not running a full node to mine at all. Pools helps to eliminate the sporadic payouts that the miners are otherwise subjected to when solomining.

The discussion is quite public, specifically any major changes. For certain exploits, they are done in a way to plug the exploit but doesn't otherwise influence the network in any way.
The problem with BIP9, as we've experienced before is that the activation is largely dependent on the miners. That isn't the intended effect and which is what resulted in the stalemate for a long time after Segwit begun it's signalling. Afterwhich, there were proposals to enforce UASF, and which wasn't required after all.

We're using BIP9 for Taproot, because there isn't any resistance from the miners. If needed, the community can run a client with LOT=True to force activation.


Miners aren't the ones who decide which changes to the network gets activated or not. The users ultimately decide which rules they should follow. Miners are a crucial part of the ecosystem and having their support with any schemes will benefit the network as a whole. The community doesn't seem to be very supportive of forced activation from the onstart, which is why I believe TR used LOT=False?

No relation whatsoever.

They're all relatively secluded or isolated and infections won't really take place there. If the local authorities don't actively test for it, then they probably wouldn't discover any cases. It can be asymptomatic for all you know.

It isn't. Crypto isn't like the early internet.

Crypto doesn't provide any revolutionary way of payment that we already have. Sure, censorship and decentralization are incredibly useful for certain cases but for most people, they appear to be just purely buzzwords which they don't care about. There is no reason, as of now why people wouldn't choose other payment gateways over Bitcoin. It doesn't mean that there wouldn't be a change in the modus operandi in the future as we refine Bitcoin even more or if the geopolitical landscape changes. The way crypto is getting so actively suppressed and goes against the ideas of the government really differentiates it from the internet.

Your internet connection can be censored, cryptos can't.

IPC increases.
Bitcoin at its current form cannot handle transactions on-chain that is sufficient to support mass adoption. We can use second layer but I doubt we won't increase the onchain capacity through some optimization. Currently, the blockchain size growth is roughly ~100GB per year. It's decent but you have to also take into account that most people won't buy an extra HDD for Bitcoin and for the near future, most consumer computers won't include that much storage because there isn't a huge market for it.

It might not seem like a lot but for the average Joe, having something like this hog up their HDD is a far greater problem for them.

That is assuming bootstrapping the entire blockchain will still be the norm 20 years from now. Who knows, perhaps there is a way to truncate or compress the blockchain in a trustless manner in the future.

Even if there isn't, the current blockchain takes about 8 hours to fully synchronize on my computer. We're still seeing quite significant improvements in both IPCs of CPUs and HDD disk size, don't think it'll be a huge problem even without improvements.

Pruned nodes don't solve the problem of having to download and validate the entire blockchain.

I'm not sure if I'm following the discussion correctly since it's getting a bit lengthy but I share the same sentiments as BlackHatCoiner.

The 128bits value is for breaking ECDSA to obtain the private key for secp256k1 curve, as defined here[1] to be 128bits. Unless we're able to get the public keys in the first place, we won't be able to have the 2^128 operations to get to the private keys. If we have no knowledge of the public keys, then we're going to the old school bruteforce for the preimage attack which 160bits of security applies since, 160 due to size of RIPEMD-160.


[1] https://www.secg.org/sec2-v2.pdf

Should be a good practice though. Google does enable automatic updates for some reason by default.
I agree that it is a bit weird, probably would be better to include a changelog screen.

Anyways, that shouldn't be the correct behavior. After updating to 4.1.0 (and above), you have to unlock the wallet to create a new one and the newly created wallet has the same password as the wallet that you've unlocked. However, this shouldn't convert the passwords of any other wallets. If you go to Settings > Password, you should be able to see "Change your password for this wallet". This means that the password change only effects the current wallet.

It isn't that much of a concern. Miners cannot be concerned with fluctuating prices, so at the prices, we can estimate an electrical consumption of roughly 60Twh per year and that is excluding all the miners that are currently in the midst of being redeployed. Since fees in a block are quite variable, there is no point trying to estimate that. At current electrical consumption levels, the annualized consumption is more than Kuwait's which is quite significant. For each halving, which is every 4 years, for the sustained profits, we expect either a doubling of total transaction fees or price of Bitcoin just to maintain the profit margins.

Not out of the realm of possibility, 4 years is quite a long time. Even if we were to calculate using a far lower bound of computational power, it still wouldn't make sense or neither is it very feasible for anyone to attack it. The effects of halving is most significant at the start, with the transaction fees being more important in the later parts.

Yes, that is correct.

Binding that address will make your Core instance to only listen on that address so that connections from others to your node can only be done through the address that you've specified but connections to other nodes are already routed through the proxy.

Which is the problem. In the scenario where a drastic drop in hashrate occurs, the block interval rises quite substantially and making the difficulty epoch even longer, thus prolonging the situation. The caveat being that difficulty lags behind the actual situation quite a bit, which isn't the best for the network. Some altcoins did adopt KGW previously to deal with wild fluctuation from Multipools switching to them. Schemes like that are far more responsive but with some security tradeoff.

Ideally, the difficulty adjustment should be long enough that variance is eliminated sufficiently while still making it prohibitively expensive or difficult for possible partition attacks. Bitcoin doesn't need to change from the seemingly arbitrary number of blocks that Satoshi decided on. While we've had quite a few instances where the block interval was prolonged quite a bit, it isn't that big of an issue, mainly due to its rarity and would be more complicated to change the retargeting parameters.

It does. If you're using any proxy, Tor for example, peers can still connect to you via your clearnet address. This can happen even if you specify oniononly, which only ensures outgoing connections to onion address but doesn't restrict your incoming connections.

If your IP has previously been used with a clearnet address and you didn't bind your Core to your proxy, then incoming peers can still establish a connection without going through your proxy or Tor instance.

Using the proxy already routes the connections to the peers over the proxy that is specified.

OP, if you really prefer Electrum over other wallets, then you can probably use an older APK to generate a legacy seed. Electrum stores the historical releases here: https://download.electrum.org/4.0.9/. Together with the signatures but I'm not sure how to verify PGP signatures on a mobile with a file. It shouldn't present much risks as long as you can validate the authenticity of a download, certainly more secure than Google Play anyways.

First of all, let's acknowledge that ASICs gets continually eliminated by the competition naturally as the rewards decreases. The network doesn't suddenly gets substantially insecure after the various halvings.

If the cost of executing such an attack gets low enough, that will probably mean Bitcoin isn't doing so well. Attacking it is pretty meaningless, we'll just fork it into another algorithm and the attackers don't earn anything and life goes on. ASICs are highly specialized and aren't that easy to manufacture and get your hands on. Both the electrical constraints, space constraints, hardware constraints will almost definitely persist in the future. These are legitimate hindrance to a successful attack. Purchasing so much ASICs and expending resources just to attack something that is half dead (if the network gets less secure) isn't very smart.

Try scaling the current stater of Bitcoin to any possible attacks, including the resources required, difficulty of obtaining them and the opportunity costs incurred by a state sponsored adversary or a very rich person. You can also scale it down to estimate what happens if a certain percentage of the miners gets eliminated.

Partially true, actually. The decrease in the block rewards are far more impactful at the start, 50 -> 25 -> 12.5 -> 6.25, etc. As we go through more halvings, the transaction fees becomes the major composition of the revenue for the miners. By the 10th halving, the block rewards will dwindle down to 0.1BTC per block. Miners who can't afford to mine will probably exit by then.

The game theory isn't affected. The same logic applies, if the miners or attackers stand to gain more from contributing honestly to the network, then there is no concern.

Depends. I don't foresee it being much more desirable to attack Bitcoin, even if the hashrate of the network drops significantly. The profits gained from an attack is far lower than the cost and the complexity of its execution and double spent Bitcoins can potentially just be worthless still. If it remains as a store of value but the value is still fairly high, then there isn't any problems.

There are tons of factors to Bitcoin's survival. If the block rewards were to be reduced exponentially right now, it won't survive. There isn't any time for the market and the miners to adapt to the far lower profits. If we were to stretch out the decrease in the block rewards, there is far lesser shock for the miners to bear. Important to note that the fees are starting to form a more significant part of the miner's income. If no one uses Bitcoin, then I wouldn't think that there is a point to keep Bitcoin afloat anyways.

As of now, blocks has consistently been filled, less some blocks in the recent weeks. Thus, it isn't a stretch to assume that if the capacity were to be somehow increased, then the transactions and subsequently the fees would be greater as well.

Yes. The compensation for the miners comes in the fees within the blocks. I'm assuming that the volume of transactions by then or the derived fee as a result of off-chain transactions would be sufficient to compensate for it.

It is highly unlikely that Bitcoin would insecure by then. The way the block rewards are reduced gradually pads any impact on the miner's income and we're most likely going to see the impact far sooner than the 2140 timeline.

This only affects 4.1.0 and above. I would classify it as a feature rather than the issue. The password is supposed to be used for every wallet on the device, whether it gets created before or after the password is set. Preventing people from creating new wallets without knowing their current password would preserve the behavior.