Bitcoin's sole purpose is to be used as an alternative currency. The value of which comes from (or at least should come from) the value of the coins being determined by the market for it's utility as a currency. If you're not going to use Bitcoin as a currency that can be transacted, there is no purpose for Bitcoin at all. At that point, Bitcoin's value falls and the cycle repeats. The current rapid rise is due to the widespread speculation, which isn't exactly healthy for Bitcoin's price stability.

Gresham's Law doesn't apply to Bitcoin but rather currencies which contains precious metals.

That is untrue. Economics indicates that for a specific price, there is a specific number of people that are willing to purchase and/or sell. There will be no point where scarcity of the actual coins becomes an actual issue due to people being unwilling to sell. Something like this would just cause Bitcoin to completely lose it's utility. At that point, then what is the use of Bitcoin? Why would people still be interested in it? Do they find something interesting with digital money that isn't functional as a currency?

The jurisdiction shouldn't extend to the rest of EU, after brexit AFAIK. UK can instruct their ISPs to selectively redirect traffic directed to that website to their own to enforce censorship like what they've done before. Problem being, if Cobra's identity remains hidden that is nothing that they can do. Especially if the location of their servers is located in a country where IP laws doesn't apply.

BIP38 isn't the same as BIP39. HMAC-SHA512 is involved with the hashing of the mnemonic. Passphrase for BIP39 is included in the salt of that.

BIP38 encrypts the string.

The court case wasn't contested by the defendant and that was the default judgement. It doesn't necessarily mean that the claims were valid.

It depends on how the IP laws is enacted within the jurisdiction that the website is hosted in. At best, it wouldn't be taken down completely. Just that the site or parts of it won't be accessible within the UK, assuming that Cobra is unwilling to comply.

Segwit is infact sometimes considered a block size increase. Segwit compatible clients includes the witness and the block size is greater than 1MB in raw size.

Any changes within Bitcoin is unfortunately marred by the politics that exists within. Miners were unwilling to adopt Segwit to further their agenda and some are still doing so today, coercing people to switch to Bitcoin Cash. MASF gave too much control to the miners without any accountability, IMO.

The rate of supply increase is decreasing. By logic, this achieves a deflationary currency due to the purchasing power increasing with a lower rate of supply increase. Having a fixed supply with gradual decrease ensures a fairer distribution rather than constant rate of distribution and does nothing against padding the shock received by the miners as one day the block rewards has to be close to 0.

It doesn't affect security, or at least to any significant extent but several cryptos do adopt a tail emission which ensures stability of the network as well. As compared to the direct deflationary concept of Bitcoin, that involves far more modelling of economic conditions.

You used 2FA, you probably didn't include any passphrase because you would probably know if you did.

That is probably not the "web address". If you are recovering a 2FA wallet, just restore it with your 12 word seed. When creating a new wallet, Select Wallet with two factor authentication> I already have a seed. Key in your 12 word seed in there. That will make your 2FA wallet like a normal wallet and you should just create another wallet to transfer all your funds to it.

No. If you were to implement a system which gives arguably easier ways to recover their Bitcoin, then it won't work. Bitcoin cannot restrict the number of people or ensure the authenticity of such requests, because there isn't any central authority. It is up to their user to create multiple backups and redundancy for their funds, and I expect this to be practiced more nowadays given the rise in the price. If they can't properly store their private keys or seeds, then too bad for them.

Why do people always think we need to reincoporate the Bitcoins back into the supply? There isn't any way to ascertain if coins are lost at all and having 21 million or anywhere near that is not necessarily for Bitcoin. There is no problems with a circulating supply that is much lower than that.  You cannot start stealing user's funds like that, nor is Bitcoin designed to have an unlimited supply cap.

Bump still looking.

Electrum seeds that were generated prior to a more recent versions has the potential to be a valid BIP39 mnemonic as well. It is not until recently that they decided to specifically grind for checksums that are only valid for Electrum and not BIP39. But yes, then the addresses generated will be different due to the different derivation paths.

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.