From: Ittay <ittay.eyal@cornell•edu>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
Date: Thu, 12 Feb 2015 08:56:02 -0500 [thread overview]
Message-ID: <CABT1wWnU9mq-AV_oPSLRNsSj_7r5iXQPspHvPJki0_vUMStgLA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6115 bytes --]
A similar idea was proposed by Sirer and me as a part of two-phase proof of
work (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard PoW and
the second phase requires the signature. This way Bitcoin doesn't lose its
mining power (read: security) in one day, but rather it is possible to
gradually switch from the current PoW to the signature-based one, slowly
phasing out the existing hardware and mining datacenters.
For a more general view of nonoutsourceable puzzles you can check out
Miller et al.'s paper [2].
Ittay
[1]
http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/
[2] https://cs.umd.edu/~amiller/nonoutsourceable.pdf
------------------------------
>
> Message: 2
> Date: Wed, 11 Feb 2015 08:54:15 +0000
> From: Hector Chu <hectorchu@gmail•com>
> Subject: [Bitcoin-development] Proposal: Requiring a miner's signature
> in the block header
> To: bitcoin-development@lists•sourceforge.net
> Message-ID:
> <
> CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail•gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Feb 2015 10:25:27 +0100
> From: Natanael <natanael.l@gmail•com>
> Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's
> signature in the block header
> To: Hector Chu <hectorchu@gmail•com>
> Cc: bitcoin-development@lists•sourceforge.net
> Message-ID:
> <CAAt2M1_qj0r03=
> Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail•gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
[-- Attachment #2: Type: text/html, Size: 7759 bytes --]
next reply other threads:[~2015-02-12 13:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 13:56 Ittay [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-02-11 8:54 Hector Chu
2015-02-11 9:25 ` Natanael
2015-02-11 13:52 ` Mike Hearn
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=CABT1wWnU9mq-AV_oPSLRNsSj_7r5iXQPspHvPJki0_vUMStgLA@mail.gmail.com \
--to=ittay.eyal@cornell$(echo .)edu \
--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