Harry asks, "What are your thoughts on a Bitcoin proof-of-work change to combat mining centralisation?
Lately we've had the pseudonymous owner of Bitcoin.org, Cobra, come out in favour of
a proof-of-work change.
He has been voicing concerns about Bitmain controlling ownership over three of the main
Bitcoin mining pools."
The quote here is: "As of last writing, at least 53% of the hashrate is controlled by
[three pools].
This is a dangerous level of centralisation.
Is this a real concern / threat to Bitcoin?
Does something like a proof-of-work change really address the core issue of mining centralisation
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.
So I would like to know why Bitcoin itself cannot respond in a similar way.
An example below."
It goes on.
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 centralisation.
In fact, it's likely to make it worse.
The thing about proof-of-work at the moment is the centralisation is driven by economic
factors that have a lot to do with how quickly Bitcoin went from being [mined by] CPUs, GPUs,
field-programmable gate arrays (FPGAs) and finally ASICs over a period of about nine
years.
This meant that the hardware was being obsoleted very quickly, which gave enormous advantage
to those who had close proximity to silicon fabrication plants and cheap electricity.
That's 99% where it's concentrated, in particular regions of China.
But those incentives and that economic structure is pretty much over.
The reason for that is, as ASICs achieved the highest level of silicon density (about
16 nanometers, moving toward 12 nanometers), there is no more 1000x performance improvement
available in the next level of density.
We've already hit the wall, Moore's Law applies.
Now you can maybe get a 2x improvement in performance over the next eighteen months.
Even that is doubtful.
At these levels of density, we're kind of reaching the end of Moore's Law in the traditional
sense of chip density.
What does that mean?
That means this ASIC equipment, when manufactured, now has a shelf life of more than two years
-- not just two months.
That means it can be deployed in many other places where there are a set of favourable
conditions, which include cheap electricity and low operating cost.
But [this also includes] political considerations.
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, fires in one of the
warehouses, or some other situation like that.
I expect we will see that the centralisation 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 competing for this.
Let's play the other side of the game, which is what would happen if you did a change in
the proof-of-work.
First of all, that would devastate the security of the Bitcoin network.
Maybe you can do it on a smaller network like Monero, but quite honestly Bitcoin's security
is the most robust level of security that exists at the moment.
A change in the proof-of-work would basically reset that and all of the investment in ASICs
would be wiped out.
That also means all of the existing security investment in Bitcoin would be wiped out.
We're talking about several billion dollars of industrial-scale infrastructure that secures
Bitcoin against various forms of attack.
That's not a good thing.
I think it's a very cavalier suggestion to simple 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 issue that would not
have majority consensus.
As a result, it would result in a fork that would split Bitcoin into 'Bitcoin SHA-256'
and Bitcoin with something else.
The [latter] would have a very hard time rebooting its security.
Who do you think would reboot that security faster?
Let's say the proof-of-work algorithm is changed, maybe made a bit more ASIC-resistant.
Theoretically, the very same players who have a couple billion dollars of liquid cash available
to them, all of the operating expertise in manufacturing pipelines and relationships
with silicon fabrication, and access to inexpensive electricity...
Do 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 [mining] the new proof-of-work algorithm,
because it would set back everybody.
They would have the advantage of eight years of experience, billions of dollars, and existing
relationships with manufacturers.
I think it would actually undo the effects of competition that we're already seeing taking
hold in this space.
So [I would say] "no" to a proof-of-work algorithm change, "no" to shooting Bitcoin in the foot,
in order to deal with a threat of centralisation that is already waning.
Also, "no" to giving more power to developers or other parties who make unilateral decisions
about the proof-of-work algorithm and split the consensus of the network.
"Is a hard fork still an option in case of an emergency?
In cases [where it is] 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?
In your opinion, what threat or event could lead to a hard fork?
Thanks."
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 vast majority of the system, meaning
the economic actors (the users, the merchants, the exchanges, the wallets, the miners), where
everybody is on board, agrees this needs to happen, and is willing to put in the effort
to upgrade their software clients to effectuate a fork that is properly executed and well-developed
with high-quality code... then a hard fork can be done.
It can be done effectively and with a minimum amount of disruption.
There are some cryptocurrencies and blockchains that regularly do hard forks, [for example
as a response] to problems.
We've seen denial-of-service attacks in the Ethereum network that involved poorly-chosen
values for gas.
In that case, Tangerine Whistle and Spurious Dragon (funny names) were a couple of the
hard forks that were introduced to solve those problems and were executed very effectively
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, it's
a much bigger economy and user community.
Nevertheless that doesn't mean a hard fork can't be pulled off.
Contentious hard forks, where a small part of the network wants the fork but the majority
doesn't, those are very problematic.
These can lead to chainsplits, as we've seen in the past.
You asked me what threat or event could lead to a hard fork.
Let's say, for example, that a fatal flaw was discovered in SHA-256 which would very
quickly lead to a compromise of the proof-of-work algorithm and a 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.
The reason is, there is a lot of deployed infrastructure in the form of ASICs that would
become obsolete with that hard fork.
That would require a refresh of all the mining hardware.
That's not entirely impossible.
Keep in mind that up until very recently, as the pace of development in ASICs was frenetic,
many of the mining companies developed the skill of being able to completely refresh
the majority of their ASIC infrastructure every six months.
Those ASICs 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 algorithm
change.
The mining companies (if it was in their interest) would not only go along but would be able
to quickly refresh their hardware infrastructure within six months.
Another possible event would be discovering a fatal flaw in ECDSA.
Discovering some kind of weakness or discovering a widely available, powerful enough quantum
computing system.
That could start negatively impacting the security of ECDSA.
In cryptography, these things generally don't happen overnight.
Cryptographic algorithms that have had flaws, like the Data Encryption Standard (DES) or
MD5 or SHA-1, they didn't just fall apart overnight.
They didn't go from 'completely robust' to 'completely useless' overnight.
Instead what happens is, weaknesses were found that 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.
Still, there was plenty of time for organisations to re-tool those algorithms.
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 such that, in six months from now, we anticipate you can [break] it
for less than $10 million and less than one warehouse full of equipment.
So we'd better start changing things up now to protect against that eventuality.
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 [a hard fork] would still be a viable option in an emergency.