[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious m
From:       john () seebitcoin ! com (John Hardy)
Date:       2017-03-20 21:29:29
Message-ID: BL2PR03MB4354CBF603056F44BD98C61EE3A0 () BL2PR03MB435 ! namprd03 ! prod ! outlook ! com
[Download RAW message or body]

> 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?

They're not equally hard, but they can be equally relative.

If you had 4 proofs of work you can weigh them each at 25% and compare the overall \
chain weight from there, shouldn't be difficult.

Initially, some hardware would have an advantage, but over time the market will \
always average itself out.


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces at \
lists.linuxfoundation.org> on behalf of Nick ODell via bitcoin-dev <bitcoin-dev at \
                lists.linuxfoundation.org>
Sent: Monday, March 20, 2017 6:02:52 PM
To: Andrew Johnson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): \
Protecting Bitcoin from malicious miners

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 at \
lists.linuxfoundation.org<mailto:bitcoin-dev at 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 at \
lists.linuxfoundation.org<mailto:bitcoin-dev at 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 at lists.linuxfoundation.org<mailto:bitcoin-dev at \
lists.linuxfoundation.org> \
                https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at \
lists.linuxfoundation.org> \
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/46f7569c/attachment-0001.html>



[prev in list] [next in list] [prev in thread] [next in thread]