I’m very worried about the state of miner centralisation in Bitcoin.
I always felt the centralising effects of ASIC manufacturing would resolve themselves once the first mover advantage had been exhausted and the industry had the opportunity to mature.
I had always assumed initial centralisation would be harmless since miners have no incentive to harm the network. This does not consider the risk of a single entity with sufficient power and either poor, malicious or coerced decision making. I now believe that such centralisation poses a huge risk to the security of Bitcoin and preemptive action needs to be taken to protect the network from malicious actions by any party able to exert influence over a substantial portion of SHA256 hardware.
Inspired by UASF, I believe we should implement a Malicious miner Reactive Proof of Work Additions (MR POWA).
This would be a hard fork activated in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork.
The activation would occur once a fork was detected violating protocol (likely oversize blocks) with a majority of hashpower. The threshold and duration for activation would need to be carefully considered.
I don’t think we should eliminate SHA256 as a hashing method and change POW entirely. That would be throwing the baby out with the bathwater and hurt the non-malicious miners who have invested in hardware, making it harder to gain their support.
Instead I believe we should introduce multiple new proofs of work that are already established and proven within existing altcoin implementations. As an example we could add Scrypt, Ethash and Equihash. Much of the code and mining infrastructure already exists. Diversification of hardware (a mix of CPU and memory intensive methods) would also be positive for decentralisation. Initial difficulty could simply be an estimated portion of existing infrastructure.
This example would mean 4 proofs of work with 40 minute block target difficulty for each. There could also be a rule that two different proofs of work must find a block before a method can start hashing again. This means there would only be 50% of hardware hashing at a time, and a sudden gain or drop in hashpower from a particular method does not dramatically impact the functioning of the network between difficulty adjustments. This also adds protection from attacks by the malicious SHA256 hashpower which could even be required to wait until all other methods have found a block before being allowed to hash again.
50% hashing time would mean that the cost of electricity in relation to hardware would fall by 50%, reducing some of the centralising impact of subsidised or inexpensive electricity in some regions over others.
Such a hard fork could also, counter-intuitively, introduce a block size increase since while we’re hard forking it makes sense to minimise the number of future hard forks where possible. It could also activate SegWit if it hasn’t already.
The beauty of this method is that it creates a huge risk to any malicious actor trying to abuse their position. Ideally, MR POWA would just serve as a deterrent and never activate.
If consensus were to form around a hard fork in the future nodes would be able to upgrade and MR POWA, while automatically activating on non-upgraded nodes, would be of no economic significance: a vestigial chain immediately abandoned with no miner incentive.
I think this would be a great way to help prevent malicious use of hashpower to harm the network. This is the beauty of Bitcoin: for any road block that emerges the economic majority can always find a way around.
If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE
John Hardy
Longtime Bitcoin advocate.
Email [email protected]
Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE
Latest posts by John Hardy (see all)
- The great P2PK Bitcoin heist. Millions of Bitcoins WILL be stolen, but should we even try to stop it? - 24 Aug 2018
- Follow up: Bitcoin Cash has 51% attack vulnerability double jeopardy - 31 Jul 2018
- Bitcoin rival has a major vulnerability which could help Bitcoin miners to destroy it in 2020 - 30 Jul 2018
This can be rolled out as a soft fork, it doesn’t have to be hard. Let a block contain two proofs of work. One is the current SHA256 POW, compatible with all nodes. Then add an extra POW which upgraded nodes will check in addition to the SHA256 POW. Depending on how this is done, it can force the current miners to either buy a lot of CPU and RAM, or cooperate with people with normal computers to find blocks in a pool where users send a special transaction with a special POW, then the SHA256 hashing power try to mine this transaction into a block. The special transaction can even be a coinbase output sending some of the generated coins to the user or user-pool.
This wouldn’t really do much to resolve the balance of power if a malicious entity had control of a majority hashpower. It also misses the point of it being a responsive fork, if we’re changing something as significant as the PoW we should do it properly.
If you change the POW in a hard fork, the result will be a new chain and a mess. If you change the main POW, users will even need to upgrade their SPV wallets to use the new chain, or they will stay on the old. If you want to change the POW entirely, the best would be to make a new coin. Using the extra POW method, old wallets and nodes will continue to work, just unable to verify the extra POW, and there will still only be one chain.