FWIW: https://www.2uo.de/myths-about-urandom/.

There seems to be quite a bit of a misconception about /dev/urandom and /dev/random. Bitcoin Core and many other wallets all uses /dev/urandom. There is absolutely nothing wrong with using SHA256, btw. The only important part is for the input to have sufficient randomness.

Electrum 3.0.4 and below had an unprotected RPC. If you were to access any webpage and the webpage sends a CORS preflight request, then your seeds will get compromised.

Out of an abundance of caution, I would probably create a new wallet if you used your wallet before 3.0.5. After that, the vulnerability was the phishing through the rich text. If you didn't click on any links and download any files through Electrum, you're okay.

Actually doesn't really make sense. Tesla declared more than a billion dollars that they've invested in Bitcoin. Suddenly withdrawing support and pulling out from it was a dumb move. Prices tanked and so did their stocks, it was bound to make a few heads turn. Why didn't they do their own due diligence before investing in it? Was the entire point from the start to buy Bitcoins and lose money on it?

The market manipulation is quite obvious. Elon Musk was certainly not trying to profit from it though, it wouldn't have been worth his time.

You cannot accurate measure the decentralization of Bitcoin or it's pool by taking the distribution of the hashrate at face value. There are a lot of factors to take into account when we're measuring the true decentralization of it. The top few pools are all located within the jurisdiction of PRC, which is known for their iron grip on the companies. Is Bitcoin decentralized if those pools owns a majority of the network's hashrate?  While pools matters less for the miners, as they can switch out to another pool whenever they want, there lies the problem with the fact that miners are often concentrated in certain areas, which coincidentally, is China (though it's starting to change). There is also a lack of perfect information; taking the proportion of the pools isn't a good idea. Anyone can own a few large farms and split them across the pools. While it seems to make it seem more decentralized on the surface, an individual still owns a good proportion of it. Measuring how decentralized a network is by purely looking at the numbers will thus often be misleading.

The nature of PoW encourages centralization. Having loads of resources or reducing your costs will maximize your profits. Either of them will encourage some sort of centralization.

Most users don't require a txindex. Chainstate is about 7-8GB right now(?), certainly less than 10GB. Block data grows way faster than chainstate, the UTXO set is constantly having entries added and removed but the block data grows linearly.

Then isn't it a bit strange to be giving a random figure without any concrete data? I think the Bitcoin mining council said they're using 56%, not a high number considering they're probably one of the few in the spotlight.

Climate change or environmental damage isn't only caused by the electrical usage of Bitcoin. Ewaste and the production of the ASICs contribute immensely as well. Actually, not all renewable generation are particularly carbon neutral at all. It's quite a common fallacy to assume that just because you're using renewable energy, you're being green.

That is rarely the case. Building the facilities and using it often comes in a fairly huge expense of the environment.

Unfortunately, most of the arguments appears to be centered on exactly that. I think I addressed the point about the lack of utility of Bitcoin and why it isn't a fair point to be comparing it to driving your cars. If you consider the issue of environmental degradation to be only about the direct electrical consumption, you're barking up the wrong tree. If the government really cared about the environment, we wouldn't be facing the whole issue of climate change today. Historically, government hasn't been as concerned with the environment as long as there is economic growth. Miners didn't care whether they're using 'green' energy or not as long as they're generating the most profits.

No concrete data, AFAIK. 75% sounds quite unrealistic.

Bitcoin contributes to global warming, simple as that. Manufacturing ASIC requires huge amount of energy, from mining the silicon, producing the wafer, etc. The entire process consumes a significant amount of energy as well. Sure, okay you compare Bitcoin to banking systems, different payment systems. That is hardly a fair comparison, the userbase of those are far greater than Bitcoin's with the transactions arguably far more useful, for their volume and utility. Use of Bitcoin in the real world remains fairly scarce as of now, and that isn't looking to be changed anytime soon.

It's quite stupid to assert that Bitcoin doesn't contribute to global warming. Fact is, as much as you like to deny it, it does. Simple as that, your car, AC all contributes to global warming by producing demand for electricity and/or production of the said products. Do you think it'll be more reasonable to compare something that is far more useful to Bitcoin?

Obviously, when Bitcoin becomes more useful than it is now, people would stop saying that it is a waste of electricity. Just like how people don't refer to those industries which produces more pollutant than Bitcoin as frivolous and wasteful use of electricity. They're mostly attacked by hardcore environmentalist rather than the general public which are often far more rational.

I've never looked into that part of the mailing list, can't say anything about that. OP_return are the only outputs that aren't included in the UTXO set.

The dust limit serves as a threshold for the transaction to be considered non-standard, and thus invalid to be relayed. You can of course still create those outputs, they just won't get relayed. You can spend them with no problems but as the paper references, it costs more to consolidate and spend them as the extra input occupies extra space.
They aren't. Core doesn't exclude dust outputs from the UTXO set.

They cannot, and should not. Excluding any valid UTXO from your client's UTXO set will result in your client not accepting a block if the UTXO happens to be spent in that block. The missing UTXO will make Bitcoin Core invalidate the entire block. You don't mark UTXOs as unspendable, you "freeze" them to ensure they're left alone and never spent in the transactions that you're making. If it were to be spent in the transaction, the linkage will compromise your privacy. They are a cheap way to exploit the privacy.
Depends on the type of script it is locked to. Differs between Segwit and Legacy.

Oh, I think I got what's going on.

You have to restart your Ubuntu OS after the first pip installation for the path variables to take effect. I reproduced this with 21.04 and found Electrum to be correctly installed in ~/.local/bin but you can't execute it in terminal without first navigating to that. Restarting Ubuntu after the installation fixes this. Weird, I've never had this problem with the older Ubuntu or other Linux distributions.
The reason why you're able to launch Electrum through the link you've followed is that you're directly executing Electrum. The icon that is created directly points to the Electrum that is installed for all users using pip. You could've used Electrum if you were to restart your computer and use terminal to launch electrum (by typing electrum in the terminal). pip doesn't create icons, so you're supposed to be executing through the terminal but in the guide you've linked, you're creating your own shortcut.

No matter how many times I've tried, I can't replicate the issue. Electrum reorganizes the sequence of the config during shutdown, could you check if you missed it due to the shuffling? (Sorry it might be a bit obvious but I suspect that might be the case.)
skipmerklecheck persists if I enter it at the end like this:


Take care to not break the syntax of the config. Oneserver should disable autoconnect, if I'm not wrong (doesn't hurt to include). As long as you trust the server, you don't have to include confirmed_only either. The use_rbf depends on whether you want your transactions to have opt-in RBF.

Edit: Okay anyways. Since you're explicitly running Electrum with -oneserver and the server you're connecting to, you don't have to include the two config variables for that. For confirmed_only = true, it would prevent you from spending any unconfirmed UTXO. Again, doesn't hurt to add them; your arguments will override the appropriate configs.

--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.