AFAICT, the capital costs seems to assume the depreciation of it but doesn't necessarily consider the fact that they become practically useless after any forms of attack, completely. Attacking the hardest chain would only serve as a warning to the rest and your ASICs can all go to the scrapyard right after. Instead, take into the account the costs of the ASICs rather than the running costs due to depreciation. The chip suppliers are fairly inelastic at the moment and ASIC chips aren't the focus of chipmakers right now. In fact, the majority wafers are almost always allocated to the bigger manufacturers and there isn't a lot left for ASIC manufacturers. Whether you can scale up the production through the years, and race against the network is another issue.
For a fact, mining pools cannot sustain the attack. The miners in a mining pool has vested interest to ensure that they can continue to run pools, and their miners want to continue to mine and not have their equipment becoming useless. At the first sign of any possible attacks, the miners can easily just point their ASICs somewhere else, and not continue to mine with them. You can't do the same if your funds are trapped with an exchange.

At the end of the day, I'm not going to be name-calling, whether they favour PoS or not. It isn't the purpose of my posts. I'm only here to provide my 2 cents and it is totally up to you to do your own research and come up with your own conclusion. Be objective and consider both sides of the camp, but DYOR and don't get misled.

Not really programmed from the start, it is an observation.
Quantum isn't like a silver bullet, it still obeys physics but it's just that it is not immediately clear what we can do with it. The issue here is with the recovery of PK keypairs, and no one is denying that it is possible. We have proven that Shor's algorithm is able to factor integers far faster than classical computers. I don't think that it isn't possible in the distant future, but that it would be so expensive that people wouldn't bother with it. By then, most would've shifted to a different algorithm or the remainder *could've* also been burned.

There is a myth floating around that paper wallets are generally safer than software wallets. That is untrue and quite often it can be the exact opposite. If you were to use it online, or loaded from the website, the contents can be dynamic and the user would be unable to validate the authenticity of them. The general consensus is that it is difficult to implement crypto functions on JS than locally. Ultimately, the main difference comes from how you handle the keys and the environment you're generating it in. Unsanitized browsers are not the best.

The broadcast button is only clickable when you sign. If you don't sign it then saving it wouldn't result in it being clickable.

You don't have to save any transactions. Saving transactions are only for situations where you don't want to send the transactions or you are unable to do so. Sign and Broadcast are beside each other and broadcasting it also entails it being stored within your data files. No further action should be required and no RSI either

Doesn't this reinforce the fact that we need to use multiple mixers?

It depends though. As far as possible, you should assume that an adversary, if given enough resources can and will expose your identity regardless of the precautions that you take. Unfortunately, there is no way to tell whether blockchain analysis on your TXes are possible, or if your mixers are a honeypot. I would probably prefer using a privacy coins over this, or at the very least choose a mixer that I know and can trust. Else, I'd like to assume that the first mixer would be the most important link and the rest are merely supplementary. It shouldn't really decrease the privacy beyond that provided by the first mixer though.

Do your own due diligence and partition your funds properly, you should have an emergency funds before setting aside funds for investments. You should ideally have covered your personal expenses by that point. With the funds that you're using for investments, please do not put everything into Bitcoin. You probably can't afford to lose them all, try to have different tiers of investment for your risk profile. Investing everything into cryptos is just shooting yourself in the foot.

I believe that having a "local" transaction is evident enough for most people to understand that it was never broadcast. There is no confusion associated with this, and any confusion as a result of this is solely due to the user's poor understanding of how Bitcoin/Electrum works and trying to overcomplicate the UI doesn't fix anything but only serves to create more problems. If a transaction is signed, then the TXID will appear as it should. The problem would've been solved if OP would search up on what "local" means and what the expected behavior should be.

It would be futile to try to achieve anything if there is any form of privacy leakage while using the second mixer. If either your browser or any modules within your computer is leaking any personally identifiable information, be it having DNS leakage, Torrent leaks, WebRTC, then you should assume your privacy to be dependent only on the second mixer.

Reason why I didn't do so is because of the author of the article that you linked. I didn't run the numbers because I didn't have time so I cannot vouch for the accuracy of either. Given the author and the possible ulterior motives behind it, I prefer to refrain from giving my opinion on it but rather take a more neutral approach which doesn't agree nor disagree with it. Just for starters, the article seems to be ignoring the problem with nothing at stake. There are also several miscellaneous costs that the article seems to have ignored (Do CMMIW tho), but it assumes that some adversary has the capacity and the ability to produce that many ASICs, to supply that much power, given how the supply is already generally inelastic.

Anyhow, I think there were several threads on this previously. Perhaps reading them would provide you with more insights into this.
Hmm. Is it easier to get a large proportion of coins or is it easier to set up your mining rigs and hooking up a few power stations with it? The former is probably far easier given how users are already prone to storing their funds in exchanges and centralization is already not uncommon.

They aren't true quantum computers. The number of qubits isn't of any significance if they cannot be used to achieve what we need. The current quantum computers that you see, ie. by DWave claims to have a fairly high qubit but the technology that they're using to achieve it is quantum annealing. Quantum annealing cannot run Shor's algorithm to achieve the exponential decrease in the time taken. They are used for entirely different applications, universal gate QCs are the ones which are of concern.

No. Any sampling that you're going to obtain is going to be either highly biased or just outright inaccurate. Only the miners who are using a huge percentage of green energy would bother declaring that they're doing so, if they do then how should we check and enforce it? It is simply impossible for the target to be achieved, or at least without a guarantee that the statistics are accurate.

If you think that the problem of energy consumption is solved by renewable energy, you're dead wrong. Elon Musk obviously doesn't care about the environment or perhaps he's just living in his own world.

I rather have people asking questions about how to verify. There is a very common misconception about how to verify the authenticity of their files; where people seems to assume that so long as the hash of their file is the same as the ones that they see on the website, then it is safe. PGP is often a very novel concept for them and most of them wouldn't follow the best practices to validate their downloads. I rather have users going through the longwinded way of doing things than to risk having them having an illusion of their security.

There is also a problem with the WOT of PGP, and that it concerns the security of the user as well. That is a whole other issue together.

Doubt so. Even if he did, QCs were too far away of a threat that it still made sense to use ECDSA.
Maybe. Who knows?
It is a misnomer. Definition of cryptography, as specified in RFC2828 states that; The mathematical science that deals with transforming data to render its meaning unintelligible (i.e., to hide its semantic content), prevent its undetected alteration, or prevent its unauthorized use. If the transformation is reversible,cryptography also deals with restoring encrypted data to intelligible form.

Cue the bolded part which concerns Bitcoin. If you disagree, please highlight the part in Bitcoin that would prove otherwise.

Yes.

Could you point out the timestamp for which this is mentioned? The livestream is far too long and I can't find anything related to this when doing a quick scrub of the timeline.

The alternative to the scheme which is much simpler still gives sufficient redundancy if several pieces are lost, just like in Multisig where you have redundancy in terms of the signers which are not cooperative. Common seed splitting schemes are easily implemented and reproduced without the need for any complicated code.

Depends. Resources needed is immense.
Because the difficulty of cracking them becomes exponentially harder. Exhausting 80 bits of search space is 2.8147498e+14 times easier than going through the search space of 128bits. Currently, the entire Bitcoin network calculates ~ 80+ bits within a short period of time, but if you were to go to 128bits, that would go to billions of years (~8.43e+10 year). The search space is gigantic and I believe that we've talked about how big 128 bits of entropy is, many many times and how infeasible it would for anyone to even try to exhaust the search space. There is a reason why the topic was centered about partial cracking and not fully compromising Bitcoin seeds.

As a disclaimer, the hashrate of Bitcoin network cannot be approximated to be the same. Reason being, the ASICs that we have operates by a simple principle; where you only take data to double hash them, check the hash and then increment or change the parameters. The same cannot be said for an ASIC that would be made specifically for cracking BIP39 seeds. Even if it does, if it takes billions of dollars of equipment, not including R&D together with the electrical consumption of a country. All that just to crack a few dollars worth of nearly fully exposed BIP39 seeds. It's far cheaper, easier and impactful to just execute a 51% attack, don't you think?

BIP39 is a way to get the mnemonic to generate BIP32 seeds. BIP32 seeds are used to generate master keys to generate Bitcoin address. Are we talking about cracking Bitcoin addresses or are we talking about the possibility of cracking a standard for generating Bitcoin addresses? We aren't talking about cracking individual addresses in the first place and even if we are, it is practically impossible.

This doesn't impact Bitcoin. The security that the 12 word or 24 seeds provide isn't the issue here. The issue here is how many words can be exposed before it becomes vulnerable to an adversary, which doesn't concern Bitcoin's security at all. The entropy that our seeds provide >128bits isn't vulnerable to any attacks, ASICs or not, at least it isn't feasible in the near or the far future.

The market for this ONLY exists if there is an abundance of seeds out there, which are partially exposed. Since we are concerned about the cost/benefits of developing such an ASIC, would it be reasonable to assume that in the future, there exists billions of dollars worth of partially exposed seeds? Probably not. No one really cares if you can bruteforce partial seeds anyways, because the negligence of the user is at place here, not how we designed BIP39 to be. It doesn't undermine the security of our implementation, and cracking a seed that is securely generated and stored is far, far, far more expensive (both in terms of the monetary and the resources required) and also improbable than any rewards you'd possibly get.

Shamir's Secret Snakeoil : https://en.bitcoin.it/wiki/Shamir_Secret_Snakeoil#Examples_of_Shamir_Secret_Snakeoil.

Our current mining ASICs are incredibly specialized in the sense that they are very good at hashing block headers and incrementing the nonces but nothing else. There is a reason why ASICboost has made certain ASICs faster than those without. I agree, the network hashrate and cracking BIP39 seeds cannot scale to the same level.

Thought I'll address this as well: It can be developed, for sure. It isn't particularly difficult. The problem is not how hard is it to be developed, but how big is the market for it. Would there be any point in the future where people are able to get partial seeds readily? Scrypt was ASIC resistant as well, but it didn't take too long for an ASIC for it to be developed... Just that it was quite memory intensive. The costs of the R&D into the mining ASICs that we've seen today is subsidized by the huge market for it.

---

I'm not so sure if I agree on it from a cost-benefit POV. Sure, it might weaken the security but does it mean that it'll get exponentially easier and cheaper in the future to do so? For one, you need to compromise the partial seeds first and you also need to invest time and money into cracking it. Wouldn't it be more worth to just go out and buy some Bitcoins instead of cracking some partial seeds. Not that SSS is fundamentally flawed, but if you're asking me to choose between something that is foolproof and infeasible enough to crack or something that is difficult to implement and difficult to crack, I'll choose the former.

Actually, I remember I used to hear that certain gambling sites were implementing this before but eventually stopped doing this. An attack vector for this would be to deposit funds > If loss = Double spend, else confirm. The tactic was exploited through GHash.io previously, but I recall there were more instances of this happening and eventually it was stopped altogether or at least available only for non-optinRBF Txes.

0-conf TXes at low amounts would still be feasible in the case that the attacker exposes their identity in the first place and makes it easy to persecute if needed. Else, then it really doesn't make sense and even with $3 TXes, I never had the chance to get instant TXes anymore.

Well, yeah. Technically the greatest possible target, or a difficulty of 1 is a hash that is smaller than 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF. PoW is a concept whereby we measure the estimated work done to do something, where in this case would be a hash that meets the specific requirement.
Actually, difficulty is just a representation of the target. It is far easier to say a number than to actually say the target. I find it easier to describe target with the number of zeros, because a the maximum target (and lowest difficulty) has 8 zeros and loads of people have no idea what it means when I talk about target. Leading zeros is a dumb down concept that is easier to describe to most people. The more correct method of describing a target is to compare the hash to a 256bit number, and it's validity is determined by comparing the hash and the target, where the hash has to be smaller than the target to be valid.

---

I didn't really refer to your terminology but your understanding of how a pool function. If you can understand how a pool works, either through looking at stratum documentation or a pool's code, then it shouldn't be difficult to understand what's going on.

Okay. When you submit a share, you submit the job ID, nonce, timestamp and every data needed to reconstruct your hash. The pool reconstructs your hash and checks if it is a valid share > X difficulty as specified by your client or your pool. PoW is a hash and you don't need an ASIC to generate a hash... Your hash is always rebuilt and validated by the pool, you cannot just submit random values because the pool checks it.

Just to contextualize it; when your ASIC takes 1 billion attempts at finding a block, it'll probably hit one hash that fits the difficulty (ie. 1) as specified by the pool. That is a valid share, even if the current difficulty is 10,000, because your pool specifies a much lower difficulty than the current PoW to validate that you are infact attempting to find a block. By submitting several valid shares, you are proving to the pool that you are contributing to the effort. You will probably understand this better if you can look at how pools actually work, perhaps starting with how the stratum protocol does the communication between the pool and the miner.

A share does include a PoW. If you were to mine in a pool, you'll realize that your client finds and submits shares of X difficulty. The precise mechanism is as follows:

1. Pools sends the data required to construct a block and the difficulty for which it expects before a share is submitted to the client. A share doesn't necessarily have to meet the target, it is just something to determine if a miner is in fact contributing to the pool.
2. With the data given, the user hashes to find a hash that meets the difficulty as specified by the pool.
3. Once they find a hash greater than the specified difficulty by the pool, they send it to the pool, together with the information necessary to reconstruct it. If the pool cannot reconstruct it to form a hash that meets a specific target, then it is invalid. It is futile to send any shares that don't meet the specified difficulty because they won't be considered by the pool.

I think you have a fundamental misunderstanding of Bitcoin, rather than how pool works. PoW is not a random number, PoW in Bitcoin is defined with the hash that is difficult to find, ie. your leading zeros in simplified terms.