path: root/8e/70ac72f8cd3bb709ad46a16b5cfc89b4158ee8

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 <stanga@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <ittay.eyal@cornell.edu>
Date: Thu, 12 Feb 2015 08:56:02 -0500
X-Google-Sender-Auth: 99t92V1_Q2nDvnguffHTE6DLX50
Message-ID: <CABT1wWnU9mq-AV_oPSLRNsSj_7r5iXQPspHvPJki0_vUMStgLA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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...
>
> ------------------------------
>
>

--001a113de2724531dd050ee47c73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>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&#39;s standard Po=
W and the second phase requires the signature. This way Bitcoin doesn&#39;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</div><d=
iv><br></div><div>For a more general view of nonoutsourceable puzzles you c=
an check out Miller et al.&#39;s paper [2].=C2=A0</div><div><br></div><div>=
Ittay=C2=A0</div><div><br></div><div>[1]=C2=A0<a href=3D"http://hackingdist=
ributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/">h=
ttp://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin=
-mining-pools/</a>=C2=A0=C2=A0</div><div>[2]=C2=A0<a href=3D"https://cs.umd=
.edu/~amiller/nonoutsourceable.pdf">https://cs.umd.edu/~amiller/nonoutsourc=
eable.pdf</a>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">------------------=
------------<br>
<br>
Message: 2<br>
Date: Wed, 11 Feb 2015 08:54:15 +0000<br>
From: Hector Chu &lt;<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail=
.com</a>&gt;<br>
Subject: [Bitcoin-development] Proposal: Requiring a miner&#39;s signature<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in=C2=A0 =C2=A0 =C2=A0 the block header<br>
To: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de=
velopment@lists.sourceforge.net</a><br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CAAO2FKEFxC_byt4xVJb0S-7y=
y0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com">CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-A=
v7MHUH-RBDuri_GAFtw@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
A proposal for stemming the tide of mining centralisation -- Requiring a<br=
>
miner&#39;s signature in the block header (the whole of which is hashed), a=
nd<br>
paying out coinbase to the miner&#39;s public key.<br>
<br>
Please comment on whether this idea is feasible, has been thought of before=
,<br>
etc., etc. Thank you.<br>
<br>
Motivation<br>
----------<br>
<br>
Mining is centralising to a handful of pool operators. This is bad for a<br=
>
number of political reasons, which we won&#39;t go into right now. But I ha=
ve<br>
always believed that some years down the line, they could hold the users<br=
>
hostage and change the rules to suit themselves. For instance by eliminatin=
g<br>
the halving of the block reward.<br>
<br>
Solution<br>
--------<br>
<br>
Currently the block header is formed by the pool operator and distributed<b=
r>
for<br>
hashing by the pooled miners. It is possible to divide the work among the<b=
r>
miners as the only thing that is used to search the hash space is by<br>
changing<br>
a nonce or two.<br>
<br>
I propose that we require each miner to sign the block header prior to<br>
hashing. The signature will be included in the data that is hashed. Further=
,<br>
the coinbase for the block must only pay out to the public key counterpart<=
br>
of<br>
the private key used to sign the block header.<br>
<br>
A valid block will therefore have a signature in the block header that is<b=
r>
verified by the public key being paid by the coinbase transaction.<br>
<br>
Ramifications<br>
-------------<br>
<br>
Work can no longer be divided among the pooled miners as before, without<br=
>
sharing the pool&#39;s private key amongst all of them. If the pool does tr=
y to<br>
take this route, then any of the miners may redeem the coinbase when it<br>
matures. Therefore, all miners will use their own key pair.<br>
<br>
This will make it difficult to form a cooperating pool of miners who may no=
t<br>
trust each other, as the block rewards will be controlled by disparate<br>
parties<br>
and not by the pool operator. Only a tight clique of trusted miners would b=
e<br>
able to form their own private pool in such an environment.<br>
<br>
Attacks<br>
-------<br>
<br>
Pooled hashpower, instead of earning bitcoins legitimately may try to break=
<br>
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<br>
share their private key with the whole pool. Due to the increased<br>
cooperation<br>
and coordination required for an attack, the probability of a 51% attack is=
<br>
much reduced.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 11 Feb 2015 10:25:27 +0100<br>
From: Natanael &lt;<a href=3D"mailto:natanael.l@gmail.com">natanael.l@gmail=
.com</a>&gt;<br>
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner&#39;s<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signature in the block header<br>
To: Hector Chu &lt;<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail.c=
om</a>&gt;<br>
Cc: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de=
velopment@lists.sourceforge.net</a><br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CAAt2M1_qj0r03=3D<a href=3D"mailto:Ref9mN7b=
JLg-odep3m5teZ7JWDLC%2BzknQdQQ@mail.gmail.com">Ref9mN7bJLg-odep3m5teZ7JWDLC=
+zknQdQQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Den 11 feb 2015 09:55 skrev &quot;Hector Chu&quot; &lt;<a href=3D"mailto:he=
ctorchu@gmail.com">hectorchu@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; A proposal for stemming the tide of mining centralisation -- Requiring=
 a<br>
&gt; miner&#39;s signature in the block header (the whole of which is hashe=
d), and<br>
&gt; paying out coinbase to the miner&#39;s public key.<br>
&gt;<br>
&gt; Please comment on whether this idea is feasible, has been thought of<b=
r>
before,<br>
&gt; etc., etc. Thank you.<br>
&gt;<br>
&gt; Motivation<br>
&gt; ----------<br>
&gt;<br>
&gt; Mining is centralising to a handful of pool operators. This is bad for=
 a<br>
&gt; number of political reasons, which we won&#39;t go into right now. But=
 I have<br>
&gt; always believed that some years down the line, they could hold the use=
rs<br>
&gt; hostage and change the rules to suit themselves. For instance by<br>
eliminating<br>
&gt; the halving of the block reward.<br>
<br>
[...]<br>
<br>
&gt; I propose that we require each miner to sign the block header prior to=
<br>
&gt; hashing. The signature will be included in the data that is hashed.<br=
>
Further,<br>
&gt; the coinbase for the block must only pay out to the public key<br>
counterpart of<br>
&gt; the private key used to sign the block header.<br>
<br>
[...]<br>
<br>
&gt; This will make it difficult to form a cooperating pool of miners who m=
ay<br>
not<br>
&gt; trust each other, as the block rewards will be controlled by disparate=
<br>
parties<br>
&gt; and not by the pool operator. Only a tight clique of trusted miners wo=
uld<br>
be<br>
&gt; able to form their own private pool in such an environment.<br>
<br>
People already trust things like cloud mining, so your solution with<br>
increasing technical trust requirements won&#39;t help. But you will howeve=
r<br>
break P2Pool instead.<br>
<br>
Also, note that threshold signatures (group signatures) could probably be<b=
r>
used by an actual distrusting pool&#39;s miners. There are already a proof =
of<br>
concept for this implemented with secp256k1 that works with Bitcoin clients=
<br>
silently. This wouldn&#39;t prevent such a pool from working.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br><br></blockquote></div></div></div>

--001a113de2724531dd050ee47c73--