Sounds like a blanket ban as opposed to selective restrictions on the server. The update check communicates with electrum.org/version and if OP was able to access electrum.org in the first place, then the restriction is only specific to the Electrum instance and not on the IPs/domains.

Simply impossible to truly determine the non-provably burned Bitcoins to any degree of accuracy. Coins are lost through several methods, be it intentional burning or accidental. The latter is far harder to identify as there might just be dormant addresses which could become active in the future. Of course, certain accidental burning is identifiable.

Chainanalysis did a report on this before, might be slightly outdated: https://blog.chainalysis.com/reports/money-supply.

Higher security risks but not unsafe. Actually, Electrum seeds are not compatible with Mycelium they are generated differently.

If you need segregation due to various purposes (your gambling sites and sales), it'll be more advisable to keep them stored on different seeds as well. You wouldn't have to use coin control to select the inputs to avoid linking them all together.

Your wallet is just a tool for you to spend your Bitcoins. You can have multiple wallets on different computers but you'll never be able to spend the funds twice.

If the addresses generated on mycelium and Electrum differs from each other and you still see the same transactions on both wallets, that is not possible.

Bitcoin's block interval is 10 minutes, you're likely to only get 9 confirmations on average.

After 6 confirmations, the probability of you getting attack is only restricted to 51% attacks and the feasibility of it. The confirmation pretty much never matters after 6, because there isn't any reason why you would need more than 6. The speed is mostly determined by the time it takes for the first confirmation because that is what matters to most people.

An exception being block rewards/generation transactions.

Weird. Most exchange really don't require 10 confirmations for Bitcoin, that is an odd number.

To be fair, when you're converting your entropy to a seed or an address, you're also blindly trusting the script as well. Some of them are mostly unaudited and have certain inadvertent bugs that could reduce entropy. Iancoleman had this with their manual entropy generation. Understanding entropy isn't just about trying to look at a few lines of codes.

Most users don't look at what they run and wouldn't understand the code behind it either, even if it is as simple as trying to generate a seed from a given set of entropy. Most well known wallets are very well audited nowadays and has far more stringent checks in this respect.

If you cannot trust the most simple and important function of the wallet, then there is no reason why you should be using the wallet. Even if you're generating your own entropy, there are still multiple points of failure within that.

JavaScript used to have fairly weak CSPRNG and randomness is not guaranteed as the recommendation is just for browsers to implement the correct entropy sources. JS is generally just worse off in terms of cryptographic security.

Sure, you can generate your own entropy. Whether you're able to do it securely and without any loss of security is debatable. If you can do your own due diligence, then sure go ahead. You probably won't get a better entropy than what is used in the various wallets.

There is a reason why major wallets don't allow their users to randomly specify their own entropy.

---

The best scenario that I can think of is to use multiple sources of entropy and include all of them, dice and your OS random. That way, the theoretical entropy cannot fall below either of the entropy and serves as a good enough fallback. Allowing user to generate their own entropy without being sufficiently educated about it is akin just letting them shoot themselves in the foot.

The Electrum server. It is done intentionally to avoid overloading them by including a cap on the addresses that can be queried by individual servers.
There is currently a PR to include scripts in payto/paytomany RPC.

I doubt the reason is for the spam, or at least it shouldn't be a valid one.

B&H is an okay section, I occasionally browse that section and answer questions which I'm interested in or if they're asking for help about something. The real spammer's cesspool is actually Bitcoin Discussion.

No seriously, go look up a thread with at least 2 pages. You'll realize certain contents being paraphrased over and over again, worse still, some of them are outright incorrect. Unfortunately, you can't really ban Bitcoin Discussion from your signature campaign, the spam would just move elsewhere and that is where the Bitcoiners are always gathered. I do get some meaningful discussion from time to time but it's quite rare.

Brainwallets are a good example of why user specified entropy is not a good idea. Note that I did state afterwards that it is sufficiently secure if the user knows exactly what he is doing. Rolling 100 dices at once and having the user choose the sequence of numbers also reduces the entropy (think you can find a thread in the hardware wallet section which I discussed this). The fact that there are so many things that can go wrong, and that most users probably doesn't know how to generate it properly can be quite concerning.

If you can be sure to generate the entropy correctly, and also ensure that you're converting the entropy in a secure manner without any sources of entropy leakage, then go ahead.

Perhaps not "usually" but there is definitely a far higher chance. I apologize for my wrong choice of words.

I consider that poor software implementation, as with how Blockchain.info/.com has always been plagued with. Pushing out an update that includes a faulty RNG is gross incompetence, any changes done to that has to be tested and ensure that the calls are correctly received. That is not their first time with faulty RNG, their signatures were bugged as well. Oh and of course, the fundamental problem is that they were okay with just relying on random.org for entropy, when the internal system fails. For Bitcoin Core, failure to get the CSPRNG from the OS entropy will result in the function failing.

Most codes that requires a high degree of entropy is often hardened with something else, so there is a chance for your survival given a catastrophic failure of several sources, not what Blockchain.info did. Till this day, I still don't understand what is the point of trying to XOR your entropy with data fetched from another site. There is no guarantees that the site is working correctly, the data can be manipulated and you're effectively ONLY relying on securerandom again. So what is the point? If both fails, then you're doomed.

Honestly, I was quite in disbelief when I took a look at their code. Mind you, I was very new to programming (and cryptography) back then but I could identify the possible security risks of implementing something like this.
Read the code. Does it reference the required entropy properly? Those parts that concerns the entropy is often done with loads of scrutiny by far more experienced coders than the average Joe: https://github.com/bitcoin/bitcoin/pull/14955. Several wallets uses multiple sources of data to fold into the entropy, current time, OS version, etc.

Perhaps you can do better than them, but not everyone understands what they're doing; for example:

Oh, I'll roll 50 dices and I'll get an entropy more random than those derived from /dev/random. Proceeds to roll a very biased dice which perhaps lands mostly on 3 sides out of 6 and ending up with less than 128bits of entropy. That isn't very ideal, at all.

It probably isn't that the miners don't know, just that they couldn't be bothered about it. If all of the pools don't bother to compensate the miners for this, then they would have no choice either.

In actual fact, the acceleration service is ridiculously expensive. In certain cases, people can just buy more Bitcoins and send them for the price of the acceleration. If you have a very big transaction, then there isn't a point trying to accelerate it. Else, RBF or even CPFP would be way more convenient and this should be considered as a fallback in case both of them is not possible. The market for transaction acceleration isn't particularly big in the first place. It isn't ethical for the miners to not be compensated, but at the same time there isn't any way to prove that the miners are receiving their fair share. Including a lower fee transaction may or may not mean that the transaction is accelerated.

Perhaps you can setup a tool to monitor this but unless it gains any traction among the miners, nothing will be enforced.

ViaBTC accelerates quite a few transactions for free as a political statement; Bitcoin needs a block size increase. You can see it on their page so doing something like this at the expense of their miners isn't very ethical in the first place.

Miners are concentrated in regions which would net them the most profits, factors are but not limited to: cost of labour, electrical costs, cost of landspace, cost of shipping and setting up the ASICs. Higher energy surplus, vast availability of land space, etc. It isn't hard to see why China is such a great place.

They haven't really done anything to the miners until quite recently. Even then the crackdowns were justified to be for the environment and not against Bitcoin.

Again, message signing is done with the private key. Don't consider the concept of addresses, the same message when signed with a single private key can be validated against P2PKH and P2WPKH, provided that they're derived from the same public key. You can sign messages using your bech32 address (actually the private key, but since you insist on not talking about the private key), just replace the legacy address being shown in the results with your own bech32 address. You're probably talking about message validation as opposed to signing, for which you will be correct.

Apologies though if you found that I was repetitive. I had a hard time following your train of thoughts.
There is a BIP actually, still in the drafting stage: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki.

You need to understand that you're not signing using an address, you're signing using the private key. The public key is derived using the ECDSA signature and the client can parse and convert it to an address, if the address generated matches the address given and that the signature is valid, then brainwallet will return positive. This is also the reason how the client can deduce a set of possible addresses using the signature alone. As BlackHatCoiner has mentioned, replacing a message that was signed in brainwallet with its legacy address also means that the signature is valid for the bech32 version as well, because your client can generate and confirm the bech32 address that is given.

Brainwallet doesn't convert any addresses to Segwit, unless there is some fork out there. It has been discontinued for quite awhile. Message signing at its current form doesn't prove knowledge of the private key.

Alright fair enough. I wasn't very happy after spending quite some time reading through both threads to figure out what's going on and got chided like that. I was just trying to clarify on the scenario that you've presented. Your second response explained everything that I needed to know, didn't respond afterwards seeing the reply and edited my post instead to avoid padding the thread up unnecessarily. Nonetheless, apologies if I was harsh on my words.

HCP's response basically encompasses the gist of the entire thread.

There is no reason for anyone other than China to ban those that you've mentioned. Think about it, why would any other country want to ban Google? Not everyone has a motive like China to ban western products.

Conversely, US banned Huawei and influenced loads of its allies to choose alternative solutions for their 5G networks. Last I checked, Huawei isn't doing so well. Admittedly, not an apples to apples comparison but that is what strict regulations on Bitcoin can do.

Bitcoin mining is often seen to be damaging to the environment and having them in certain regions can be damaging to the local climate and/or exacerbate any energy shortage. Tons of reasons to try to ban anything that helps Bitcoin, most governments aren't exactly a fan of Bitcoin. What China did was to set a dangerous precedent; mining is huge in China and they're happy to let go of that share. Sure, it'll thrive, that is how it is designed but the adoption will still be crippled to a certain extent.

By importing the private key into the fork wallets. You should always transfer the Bitcoins out before attempting to recover any forkcoins.


On a side note, are you sure you want to redeem your Casascius coins? Depending on the condition, the actual unredeemed coin can fetch up to a couple grand more than it's loaded value. Check the collectibles section to see if anyone is interested.

It isn't that much of a concern. It is difficult to regulate mining if done on a smaller scale and some countries are definitely more welcoming to miners. At worst, the hashrate drops significantly and smaller scale mining operations thrives. The problem arises if the country has a certain agenda, that isn't favourable to Bitcoin.

Miners are important economic agents in the economic system. While you can argue that they don't wield as much power in terms of the network decisions, they still play an important role. If the country that the miner relocates forces the miners to adopt policies that are detrimental to Bitcoin, then I suppose there is really some real concern there. Certainly don't think everyone wants to see more pools adopting some dubious OFAC compliant blocks.

Mining will always be centralized, even if China bans it. There is no telling of the kinds of regulations that the relocated miners will be subjected to. If anything, China banning it just shows that they never had any intention of weaponizing the miners that they have so it really wasn't of any concern in the first place.

The actual problem is the fact that governments are starting to take anti-Bitcoin stance. That is not good, no matter which government is implementing it. The negative sentiment is mostly focused on the drop in the value of Bitcoin. Demographics of the investors makes it such that they are particularly susceptible to FUD.

Yes. Casascius coins uses mini private key as their format which is supported by Electrum. Download electrum from electrum.org, verify the authenticity and open it. Create a new wallet > Import Private Keys or Bitcoin addresses.

Put it in this format: p2pkh:PRIVATE KEY.

I assume you're talking about P2PKH, not P2PK.

Go to Window>Console, and type in this:


If it is encrypted,

Core automatically generates (and imports) all 3 main address type (P2PKH, P2WPKH, P2SH-P2WPKH) during importing.