From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLuFq-0003FY-Vq for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:56:31 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=stanga@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLuFp-0007CU-B2 for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:56:30 +0000 Received: by mail-ob0-f175.google.com with SMTP id va2so10028069obc.6 for ; Thu, 12 Feb 2015 05:56:23 -0800 (PST) X-Received: by 10.202.212.214 with SMTP id l205mr2517501oig.117.1423749383793; Thu, 12 Feb 2015 05:56:23 -0800 (PST) MIME-Version: 1.0 Sender: stanga@gmail.com Received: by 10.202.54.214 with HTTP; Thu, 12 Feb 2015 05:56:02 -0800 (PST) From: Ittay Date: Thu, 12 Feb 2015 08:56:02 -0500 X-Google-Sender-Auth: 99t92V1_Q2nDvnguffHTE6DLX50 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113de2724531dd050ee47c73 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stanga[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YLuFp-0007CU-B2 Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:56:31 -0000 --001a113de2724531dd050ee47c73 Content-Type: text/plain; charset=UTF-8 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 > 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 > Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's > signature in the block header > To: Hector Chu > Cc: bitcoin-development@lists.sourceforge.net > Message-ID: > Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Den 11 feb 2015 09:55 skrev "Hector Chu" : > > > > 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... > > ------------------------------ > > --001a113de2724531dd050ee47c73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A similar idea was proposed by Sirer and me as a part of two-phase proof o= f work (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard Po= W 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 possib= le to gradually switch from the current PoW to the signature-based one, slo= wly phasing out the existing hardware and mining datacenters.=C2=A0

For a more general view of nonoutsourceable puzzles you c= an check out Miller et al.'s paper [2].=C2=A0

= Ittay=C2=A0


------------------= ------------

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<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 in=C2=A0 =C2=A0 =C2=A0 the block header
To: bitcoin-de= velopment@lists.sourceforge.net
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-A= v7MHUH-RBDuri_GAFtw@mail.gmail.com>
Content-Type: text/plain; charset=3D"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), a= nd
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 ha= ve
always believed that some years down the line, they could hold the users hostage and change the rules to suit themselves. For instance by eliminatin= g
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<= br> 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 tr= y 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 no= t
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 b= e
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<= br> leverage the pool to its full potential the pool operator would again have<= br> 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signature in the block header
To: Hector Chu <hectorchu@gmail.c= om>
Cc: bitcoin-de= velopment@lists.sourceforge.net
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAAt2M1_qj0r03=3DRef9mN7bJLg-odep3m5teZ7JWDLC= +zknQdQQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"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 hashe= d), 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 use= rs
> 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 m= ay
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 wo= uld
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 howeve= r
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...

------------------------------

--001a113de2724531dd050ee47c73--