From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Robert Taylor <roberttaylorgen@gmail•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Centralizing mining by force
Date: Wed, 08 Nov 2017 00:37:39 -0500 [thread overview]
Message-ID: <3lQrEWAXGaWFeAuMR_DCfyO6i_5p8pI3aLdW2BCFPSgxD1fqL-dVvkaJ1miUREAYqB7MEBerXRqsveFQICtSW1k1_UzZBMku0P5jB1an8W4=@protonmail.com> (raw)
In-Reply-To: <CAArA6tURLo0yiM+js=KJEo8i1FTwOKV7V+qjC8yGd8q2PgvewQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
Good morning Robert,
What you describe is precisely one possible result of a 51% attack.
At below the 50% threshold, miners outside the cartel will on average outrace miners inside the cartel, so fullnodes which do not follow cartel rules will reject them as per Nakamoto Consensus. At some point, the chain split becomes permanent, with miners outside the cartel pulling above the cartel miners.
However, above the 50% threshold, miners outside the cartel will be unable to keep up with the cartel and be unable to build on top of the cartel chain (as presumably they are not valid signatories). Outside-cartel miners, however, may institute an opposing cartel, or an anti-cartel (blocks must have a fixed, invalid with high probability, 00000 signature).
In the end, what matters is what fullnodes accept. If fullnodes do not care, then the group of miners that is larger wins. If fullnodes do check one or the other set of rules, then that set of rules will win.
Given current politics, it is likely that fullnodes will institute an anti-cartel rule in this case, and reject the cartel and suffer low hashrate. Eventually, the cartel will be betrayed by one of its members mining the anti-cartel chain in return for fees and valuable block rewards.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: [bitcoin-dev] Centralizing mining by force
> Local Time: November 7, 2017 11:55 AM
> UTC Time: November 7, 2017 3:55 AM
> From: bitcoin-dev@lists•linuxfoundation.org
> To: bitcoin-dev@lists•linuxfoundation.org
>
> Forgive me if this has been asked elsewhere before, but I am trying to understand a potential failure mode of Bitcoin mining.
>
> A majority of miners can decide which valid blocks extend the chain. But what would happen if a majority of miners, in the form of a cartel decided to validly orphan any blocks made by miners outside of their group? For example, they could soft fork a new rule where the block number is signed by set of keys known only to the cartel, and that signature placed in the coinbase. Miners outside of the cartel would not be able to extend the chain.
>
> It would be immediately obvious but still valid under the consensus rules. What are the disincentives for such behavior and what countermeasures could be done to stop it and ensure mining remained permissionless? I think this is a valid concern because while it may not be feasible for one actor to gain a majority of hash alone, it is certainly possible with collusion.
>
> Robert
[-- Attachment #2: Type: text/html, Size: 3299 bytes --]
prev parent reply other threads:[~2017-11-08 5:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 3:55 Robert Taylor
2017-11-08 5:04 ` Marc Bevand
2017-11-09 18:18 ` Eric Voskuil
2017-11-08 5:37 ` ZmnSCPxj [this message]
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='3lQrEWAXGaWFeAuMR_DCfyO6i_5p8pI3aLdW2BCFPSgxD1fqL-dVvkaJ1miUREAYqB7MEBerXRqsveFQICtSW1k1_UzZBMku0P5jB1an8W4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roberttaylorgen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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