1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hectorchu@gmail.com>) id 1YLT4F-0004Vj-Km
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Feb 2015 08:54:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.54 as permitted sender)
client-ip=209.85.215.54; envelope-from=hectorchu@gmail.com;
helo=mail-la0-f54.google.com;
Received: from mail-la0-f54.google.com ([209.85.215.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLT4E-00077K-J7
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Feb 2015 08:54:43 +0000
Received: by labpn19 with SMTP id pn19so1949175lab.4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Feb 2015 00:54:36 -0800 (PST)
X-Received: by 10.152.8.104 with SMTP id q8mr27523320laa.56.1423644876222;
Wed, 11 Feb 2015 00:54:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.62.211 with HTTP; Wed, 11 Feb 2015 00:54:15 -0800 (PST)
From: Hector Chu <hectorchu@gmail.com>
Date: Wed, 11 Feb 2015 08:54:15 +0000
Message-ID: <CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=001a11c311982235a7050ecc273b
X-Spam-Score: -0.6 (/)
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
(hectorchu[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YLT4E-00077K-J7
Subject: [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: Wed, 11 Feb 2015 08:54:44 -0000
--001a11c311982235a7050ecc273b
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.
--001a11c311982235a7050ecc273b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>A proposal for stemming the tide of mining centralisa=
tion -- Requiring a</div><div>miner's signature in the block header (th=
e whole of which is hashed), and</div><div>paying out coinbase to the miner=
's public key.</div><div><br></div><div>Please comment on whether this =
idea is feasible, has been thought of before,</div><div>etc., etc. Thank yo=
u.</div><div><br></div><div>Motivation</div><div>----------</div><div><br><=
/div><div>Mining is centralising to a handful of pool operators. This is ba=
d for a</div><div>number of political reasons, which we won't go into r=
ight now. But I have</div><div>always believed that some years down the lin=
e, they could hold the users</div><div>hostage and change the rules to suit=
themselves. For instance by eliminating</div><div>the halving of the block=
reward.</div><div><br></div><div>Solution</div><div>--------</div><div><br=
></div><div>Currently the block header is formed by the pool operator and d=
istributed for</div><div>hashing by the pooled miners. It is possible to di=
vide the work among the</div><div>miners as the only thing that is used to =
search the hash space is by changing</div><div>a nonce or two.</div><div><b=
r></div><div>I propose that we require each miner to sign the block header =
prior to</div><div>hashing. The signature will be included in the data that=
is hashed. Further,</div><div>the coinbase for the block must only pay out=
to the public key counterpart of</div><div>the private key used to sign th=
e block header.</div><div><br></div><div>A valid block will therefore have =
a signature in the block header that is</div><div>verified by the public ke=
y being paid by the coinbase transaction.</div><div><br></div><div>Ramifica=
tions</div><div>-------------</div><div><br></div><div>Work can no longer b=
e divided among the pooled miners as before, without</div><div>sharing the =
pool's private key amongst all of them. If the pool does try to</div><d=
iv>take this route, then any of the miners may redeem the coinbase when it<=
/div><div>matures. Therefore, all miners will use their own key pair.</div>=
<div><br></div><div>This will make it difficult to form a cooperating pool =
of miners who may not</div><div>trust each other, as the block rewards will=
be controlled by disparate parties</div><div>and not by the pool operator.=
Only a tight clique of trusted miners would be</div><div>able to form thei=
r own private pool in such an environment.</div><div><br></div><div>Attacks=
</div><div>-------</div><div><br></div><div>Pooled hashpower, instead of ea=
rning bitcoins legitimately may try to break</div><div>the system instead. =
They may try a double-spending attack, but in order to</div><div>leverage t=
he pool to its full potential the pool operator would again have to</div><d=
iv>share their private key with the whole pool. Due to the increased cooper=
ation</div><div>and coordination required for an attack, the probability of=
a 51% attack is</div><div>much reduced.</div><div><br></div></div>
--001a11c311982235a7050ecc273b--
|
