From: Hector Chu <hectorchu@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
Date: Wed, 11 Feb 2015 08:54:15 +0000 [thread overview]
Message-ID: <CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]
A proposal for stemming the tide of mining centralisation -- Requiring a
miner's signature in the block header (the whole of which is hashed), and
paying out coinbase to the miner's public key.
Please comment on whether this idea is feasible, has been thought of before,
etc., etc. Thank you.
Motivation
----------
Mining is centralising to a handful of pool operators. This is bad for a
number of political reasons, which we won't go into right now. But I have
always believed that some years down the line, they could hold the users
hostage and change the rules to suit themselves. For instance by eliminating
the halving of the block reward.
Solution
--------
Currently the block header is formed by the pool operator and distributed
for
hashing by the pooled miners. It is possible to divide the work among the
miners as the only thing that is used to search the hash space is by
changing
a nonce or two.
I propose that we require each miner to sign the block header prior to
hashing. The signature will be included in the data that is hashed. Further,
the coinbase for the block must only pay out to the public key counterpart
of
the private key used to sign the block header.
A valid block will therefore have a signature in the block header that is
verified by the public key being paid by the coinbase transaction.
Ramifications
-------------
Work can no longer be divided among the pooled miners as before, without
sharing the pool's private key amongst all of them. If the pool does try to
take this route, then any of the miners may redeem the coinbase when it
matures. Therefore, all miners will use their own key pair.
This will make it difficult to form a cooperating pool of miners who may not
trust each other, as the block rewards will be controlled by disparate
parties
and not by the pool operator. Only a tight clique of trusted miners would be
able to form their own private pool in such an environment.
Attacks
-------
Pooled hashpower, instead of earning bitcoins legitimately may try to break
the system instead. They may try a double-spending attack, but in order to
leverage the pool to its full potential the pool operator would again have
to
share their private key with the whole pool. Due to the increased
cooperation
and coordination required for an attack, the probability of a 51% attack is
much reduced.
[-- Attachment #2: Type: text/html, Size: 2992 bytes --]
next reply other threads:[~2015-02-11 8:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 8:54 Hector Chu [this message]
2015-02-11 9:25 ` Natanael
2015-02-11 13:52 ` Mike Hearn
2015-02-12 13:56 Ittay
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=CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com \
--to=hectorchu@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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