Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

[Nick ODell <nickodell@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5296 bytes --]

Chain work currently means the expected number of sha256d evaluations
needed to build a chain. Given that these hash functions are not equally
hard, what should the new definition of chain work be?

On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> By doing this you're significantly changing the economic incentives behind
> bitcoin mining. How can you reliably invest in hardware if you have no idea
> when or if your profitability is going to be cut by 50-75% based on a whim?
>
> You may also inadvertently create an entirely new attack vector if 50-75%
> of the SHA256 hardware is taken offline and purchased by an entity who
> intends to do harm to the network.
>
> Bitcoin only works if most miners are honest, this has been known since
> the beginning.
>
> On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 8929 bytes --]