 Harry asks, what are your thoughts on a Bitcoin proof-of-work change to combat mining centralization? Lately, we've had the anonymous owner of bitcoin.org, Cobra, come out in favor of a proof-of-work change. There have been voicing concerns about bitmain controlling ownership over three of the main mining pools. The quote here is, as of the last writing, at least 53% more likely of the hash rate is controlled by... and they mentioned three different pools. This is a dangerous level of centralization. Is this a real concern threat to Bitcoin, and does something like a proof-of-work change really address the core issue of mining centralization and control? Or would it only delay the inevitable? What other options would be available for Bitcoin to combat hidden pool ownership by large actors such as bitmain? If such ownership is in fact legitimate? There are good examples of other communities trying to combat ASICs in recent times. I would like to know why Bitcoin itself could not respond in a similar way. An example below. You can read the question yourselves, but it goes on to talk about a recent change in the way Monero does its proof-of-work algorithm in response to the release of ASICs. I disagree. I think a proof-of-work change doesn't combat mining centralization. In fact, it's likely to make it worse. The thing about proof-of-work at the moment is that the centralization is driven by economic factors... that have a lot to do with how quickly Bitcoin went from being CPU-mined to being GPU, FPGA, and finally ASIC-mined over a period of about nine years. This meant that the hardware was being obsolete very, very quickly, which gave enormous advantage to those who had close proximity to silicon-fabrication plants and cheap electricity. That 99% was concentrated in particular regions of China, but those incentives and that economic structure is pretty much over. The reason for that is that as ASICs achieved the highest level of silicon density, not about 16 nm, but now moving towards 12 nm of silicon fabrication, there is no more 1,000x performance improvement available in the next level of silicon-fabrication density. We've already hit the wall, Moore's Law applies, and now you can get maybe a 2x improvement in performance over the next 18 months. Even that's doubtful because at these levels of densities, we're reaching the end of Moore's Law in a traditional sense of chip density. What does that mean? That means that this silicon, these ASICs, this equipment, when manufactured now has a shelf-life that is more than two years, not just two months, and that means that it can be deployed in many other places where there are a set of favorable conditions, which includes both cheap electricity, low operating costs, but also several other considerations, such as political considerations. In fact, the concentration of mining in China is a disadvantage for Chinese miners, too, because having too much mining in one place makes you susceptible to political coercion and extortion. It also increases the risks from natural disasters, electricity shortages, a fire in one of the warehouses, or some other situation like that. I expect we will see that the centralization of mining is already reversing itself. It's going to take several years until that plays out, but we're beginning to see the emergence of other manufacturers making ASICs and other locations vying and competing for this. Let's play the other side of the game, which is what happens if you did a change in the proof-of-work. First of all, that would devastate the security of the Bitcoin network, and maybe you can do it on a smaller network like Monero. But quite honestly, Bitcoin security is the most robust level of security that exists at the moment, and a change in the proof-of-work would basically reset that, and all of the investment in ASICs would be wiped out. But that also means all of the existing security investment in Bitcoin would be wiped out. We're talking about several billion dollars of industrial-skill infrastructure that secures Bitcoin against various forms of attack. That's not a good thing, and it's a very, I think, cavalier suggestion to simply change proof-of-work. Also, I don't think it would be effective. I think an attempt to change Bitcoin's proof-of-work would be a contentious fork... that would not have majority consensus and, as a result, would result in a fork of Bitcoin, a contentious fork... that would split Bitcoin into Bitcoin SHA-256 and Bitcoin something else, and the Bitcoin something else would have a very hard time rebooting its security. Also, who do you think would reboot that security faster? So, let's say the proof-of-work algorithm is changed, maybe made a bit more ASIC-resistant. Well, theoretically, the very same players who have a couple billion dollars of liquid cash available to them, all of the operating expertise, manufacturing pipelines, relationships with silicon fabrication, and access to an expensive electricity, you think they might have an advantage in rebooting their entire operation... and investing in the new proof-of-work algorithm? Arguably, they would gain an even bigger share of the new proof-of-work algorithm mining and manufacturing facility... because it would set back everybody, only they would have the advantage of eight years of experience, two billion dollars, and existing relationships with manufacturers. So, I think it would actually undo the effects of competition that we're already seeing taking hold in this space. So, no to a proof-of-work algorithm change, no to shooting Bitcoin in the foot in order to really deal with a threat of centralization... that I think is already waning, and no to giving more power to developers or other parties who make unilateral decisions... about proof-of-work algorithm and split the consensus of the network. Is a hard fork still a valid option in case of emergency? In case it's needed to hard fork Bitcoin for any reason, is that still a valid option? Now that Bitcoin has started to have a lot of users, would that not be a big mess? And in your opinion, what threat or event could lead to a hard fork? Thanks. So, I think the question here really comes down to what we mean by a hard fork. A hard fork in itself is not necessarily a bad or disruptive thing. A hard fork, if properly planned and supported by a majority of the system, meaning the economic actors, the users, the merchants, the exchanges, the wallets, the miners, everybody is on board. Everybody agrees this needs to happen, or at least the vast majority of the participants in the system agree that a hard fork needs to happen. And it's planned, and people are willing to put in the effort to upgrade their software clients, so as to effectuate a fork. And it's properly executed and well-developed, and high-quality code is produced. Then a hard fork can be done, and it can be done effectively, and it can be done with a minimum amount of disruption. There are some cryptocurrencies and blockchains that regularly do hard forks, either to respond to problems. As we've seen with, for example, denial-of-service attacks in the Ethereum network that involved poorly chosen values for gas. And in that case, Tangerine, Whistle, and Spurious Dragon, which are some funny names for a couple of the hard forks that were introduced to solve those problems, were executed very effectively and on a fairly tight timeline. There are other blockchains that have regularly scheduled hard forks every six months in order to introduce new features that are backwards incompatible. That's generally not the development culture in Bitcoin. Bitcoin has a much more conservative approach to its software management, probably because there's a lot more at stake, and it's a much, much bigger economy and user community. But nevertheless, that doesn't mean that a hard fork can be pulled off. Contentious hard forks, where a small part of the network wants the hard fork and the majority doesn't. That was our very problematic, and these can lead to chain splits, as we've seen in the past. But let's say, for example, you asked me what threat or event could lead to a hard fork. Let's say, for example, that the fatal flaw was discovered in SHA-256 that would very quickly lead to a compromise of the proof-of-work algorithm and the weakening of the security of the chain. It's very likely that under those circumstances there would be a broad move to change the proof-of-work algorithm. That would be quite disruptive, and the reason for that being very disruptive is that there is a lot of deployed infrastructure in the form of A6 that would become obsolete with that hard fork. That would require a refresh of all of the mining hardware. Now, that's not entirely impossible. Keep in mind that up to very recently, as the pace of development in A6 was frenetic, many of the mining companies developed the skill of being able to completely refresh the majority of their A6 infrastructure every six months, because those A6 were basically becoming obsolete within three to six months of being deployed. So, it's not unthinkable that you might need to be able to execute a proof-of-work change algorithm. The mining companies, if it was in their interest, would not only go along, but would be able to quickly refresh probably within six months of their hardware infrastructure. Another possible event would be discovering a fatal flaw in ECDSA, or discovering some kind of weakness, or discovering a more widely available, powerful enough quantum computing system that could start negatively impacting the security of ECDSA. Now, in cryptography, these things generally don't happen overnight. Cryptographic algorithms that have had flaws like, for example, the data encryption standard, DES, or MD5, or SHA-1, these algorithms didn't just fall apart overnight, and they didn't go from completely robust to completely useless overnight. Instead, what happens is weaknesses were found that changed the effort required, and they changed the effort required so that it became feasible for very well-funded adversaries to start attacking these algorithms, but only over long periods of time. And still, there was plenty of time for organizations to retool those algorithms. So cryptography generally... there are exceptions to this rule, of course, but generally speaking, cryptography weaknesses do not fatally compromise an algorithm once and for all overnight, and in such a way that everyone can break it. Instead, they weaken it, and they weaken it such that we anticipate that, six months from now, you can do it for less than $10 million, and less than a warehouse full of equipment, so we'd better start changing things up now to protect against that eventuality. So in those cases, we might need to implement a hard fork. But then again, some of these problems, perhaps many of these problems, can be solved with a soft fork, too. It remains to be seen. I think it's still a viable option in an emergency.