From: Natanael <natanael.l@gmail•com>
To: Hector Chu <hectorchu@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
Date: Wed, 11 Feb 2015 10:25:27 +0100 [thread overview]
Message-ID: <CAAt2M1_qj0r03=Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail.gmail.com> (raw)
In-Reply-To: <CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]
Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu@gmail•com>:
>
> 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.
[...]
> 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.
[...]
> 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.
People already trust things like cloud mining, so your solution with
increasing technical trust requirements won't help. But you will however
break P2Pool instead.
Also, note that threshold signatures (group signatures) could probably be
used by an actual distrusting pool's miners. There are already a proof of
concept for this implemented with secp256k1 that works with Bitcoin clients
silently. This wouldn't prevent such a pool from working.
[-- Attachment #2: Type: text/html, Size: 2179 bytes --]
next prev parent reply other threads:[~2015-02-11 9:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 8:54 Hector Chu
2015-02-11 9:25 ` Natanael [this message]
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='CAAt2M1_qj0r03=Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail.gmail.com' \
--to=natanael.l@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=hectorchu@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