public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nick ODell <nickodell@gmail.com>
To: Andrew Johnson <andrew.johnson83@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
Date: Mon, 20 Mar 2017 12:02:52 -0600	[thread overview]
Message-ID: <CANN4kmdMcbQ9pYC44a02+wzzVzoMt8n5TAL=Z3bRaBkT_6Vnpg@mail.gmail.com> (raw)
In-Reply-To: <CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.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 --]

  parent reply	other threads:[~2017-03-20 18:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-18 16:01 [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy
2017-03-20 15:38 ` Andrew Johnson
2017-03-20 15:46   ` John Hardy
2017-03-20 16:10     ` Andrew Johnson
2017-03-20 15:55   ` Marcos mayorga
2017-04-16 20:04     ` Erik Aronesty
2017-04-17  1:28       ` bfd
     [not found]         ` <CAJowKg+1vUBmr7cTzUy8gAdjEWTM_+07G9Z96Bo=wd6_htgv1Q@mail.gmail.com>
     [not found]           ` <CAJowKgJPjWb_S0jb+RJ9-90sucb=ZeU2-qrNqrVN5USTaxDjDw@mail.gmail.com>
2017-04-17  7:47             ` Erik Aronesty
     [not found]               ` <CAJowKgKqyb7DCs-yrbj4Z8Kzmgg0GCKXh+wwdSvfPHregiwdvA@mail.gmail.com>
     [not found]                 ` <CAJowKgL=UmJvE0KpSsa20AJBF6Ur85ghRymHY+=11VOezmaaxw@mail.gmail.com>
2017-04-17 11:17                   ` Erik Aronesty
2017-04-17 22:34                     ` Natanael
2017-03-20 18:02   ` Nick ODell [this message]
2017-03-20 18:51     ` David Vorick
2017-03-20 21:29     ` John Hardy
2017-03-20 17:49 ` Bram Cohen
2017-03-20 21:23   ` John Hardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANN4kmdMcbQ9pYC44a02+wzzVzoMt8n5TAL=Z3bRaBkT_6Vnpg@mail.gmail.com' \
    --to=nickodell@gmail.com \
    --cc=andrew.johnson83@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox