Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header

[Ittay <ittay.eyal@cornell.edu>]

[-- 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 --]