Proposal: Malice Reactive Proof of Work Additions (MR POWA). Self defense HF

[pondjohn]

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.

Any thoughts?

[theymos]

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.

A big issue with this is that although online nodes might be able to detect a long invalid chain, nodes that were offline at the time (or didn't exist yet) have no way of independently verifying that invalid blocks actually existed then. Maybe the invalid blocks were created much later in order to trigger a PoW change earlier than appropriate on some nodes, splitting the network.

You could make a rule that a block is allowed to change the PoW if it presents headers for an invalid chain of length > 50 or something, with the fork point close to the new-PoW block. So once a long invalid chain comes into existence, anyone can create the first new-PoW block containing the invalid chain's headers. This can be more readily verified later on.

Exactly what the new PoW should be is a complicated issue with years of past discussion already...

[pondjohn]

A big issue with this is that although online nodes might be able to detect a long invalid chain, nodes that were offline at the time (or didn't exist yet) have no way of independently verifying that invalid blocks actually existed then. Maybe the invalid blocks were created much later in order to trigger a PoW change earlier than appropriate on some nodes, splitting the network.

You could make a rule that a block is allowed to change the PoW if it presents headers for an invalid chain of length > 50 or something, with the fork point close to the new-PoW block. So once a long invalid chain comes into existence, anyone can create the first new-PoW block containing the invalid chain's headers. This can be more readily verified later on.

Exactly what the new PoW should be is a complicated issue with years of past discussion already...

That is a good point about verifying the historical existence of invalid blocks.

One of the things we can do with the addition of proof of work rather than a complete change is we can compare the hashpower of the SHA256 between different competing chains. Future nodes will be able to assess the health of a the MR POWA fork compared to the 'malicious' chain. If the POWA fork has a substantially lower hashpower it can be assumed the POWA fork failed to achieve economic significance. A proof of work change (POWC) hardfork has no way to relatively compare different chains and determine whether one likely succeeded economically over the other.