public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Robert Taylor <roberttaylorgen@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Centralizing mining by force
Date: Tue, 7 Nov 2017 10:55:59 +0700	[thread overview]
Message-ID: <CAArA6tURLo0yiM+js=KJEo8i1FTwOKV7V+qjC8yGd8q2PgvewQ@mail.gmail.com> (raw)

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

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: 1018 bytes --]

             reply	other threads:[~2017-11-07  3:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  3:55 Robert Taylor [this message]
2017-11-08  5:04 ` [bitcoin-dev] Centralizing mining by force Marc Bevand
2017-11-09 18:18   ` Eric Voskuil
2017-11-08  5:37 ` ZmnSCPxj

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='CAArA6tURLo0yiM+js=KJEo8i1FTwOKV7V+qjC8yGd8q2PgvewQ@mail.gmail.com' \
    --to=roberttaylorgen@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