summaryrefslogtreecommitdiff
path: root/d0/9e9d3ffadd4443f9630d05ce0ffb27f2d00a30
blob: 3373c590bafae33d7a1bef2002b5d397764100a1 (plain)
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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <rme@i-rme.es>) id 1Wwtwn-00075z-CE
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 14:01:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of i-rme.es
	designates 209.85.217.170 as permitted sender)
	client-ip=209.85.217.170; envelope-from=rme@i-rme.es;
	helo=mail-lb0-f170.google.com; 
Received: from mail-lb0-f170.google.com ([209.85.217.170])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wwtwj-0006i2-Uf
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 14:01:13 +0000
Received: by mail-lb0-f170.google.com with SMTP id 10so2937289lbg.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 17 Jun 2014 07:01:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=T8sVAnzvbd1n5k0x81IDboZXgshynMIFZYlge+n90gI=;
	b=kQEF+Cfnd8ytrqoXuaQtNrkMmHMA9ELmVQGvz2pu2pAK4EQX4L9IzgUelAqrc++kk9
	XykLqx4UkCt16/R3uhreoFyiHYbQf/lCYVqDNMK3jT1Vd0YTsAX+TGKwvTjuWl/2QRZH
	9s9tPeACDRT2rfCor8g4DWghU5F5aMuBT5KMNJn7MJ213ida01nhNeUksZ07ExpQ+YZR
	UPV9cn6anm9zrvFYLpqZ1GKuRwblxhZfPn5oVupvsOLhRAgcZzcJXIM645QkpCXXtgn+
	VJAWeV0XNOrswrRlWm0DTjOswOgAdlinX03g1MkmQx0oLo0WQtuLFICKgyFLGHpXE9/N
	fbzA==
X-Gm-Message-State: ALoCoQkPHlIZYQkjXngECBCMUzUB2ekxDVc2yb2vBFn2/3pc1kkjuFnp51Zr/sTeQMcuPgWY0XPZ
MIME-Version: 1.0
X-Received: by 10.112.35.14 with SMTP id d14mr10252677lbj.43.1403013662978;
	Tue, 17 Jun 2014 07:01:02 -0700 (PDT)
Received: by 10.152.199.8 with HTTP; Tue, 17 Jun 2014 07:01:02 -0700 (PDT)
X-Originating-IP: [85.251.84.81]
Received: by 10.152.199.8 with HTTP; Tue, 17 Jun 2014 07:01:02 -0700 (PDT)
In-Reply-To: <CAMEND1hS2j6dSjwvRSmVn_=UV-r7gujJ+Wo1VLH3nH54F3vBmQ@mail.gmail.com>
References: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com>
	<CAMEND1hS2j6dSjwvRSmVn_=UV-r7gujJ+Wo1VLH3nH54F3vBmQ@mail.gmail.com>
Date: Tue, 17 Jun 2014 16:01:02 +0200
Message-ID: <CA+8=xuLCAyYGV6hmdKRxOGNGHyQvkgnGcwKNN=1JYUhSzvxD2w@mail.gmail.com>
From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es>
To: Ron Elliott <ronaldbelliott@gmail.com>
Content-Type: multipart/alternative; boundary=14dae93d8f52ff497c04fc089200
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 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: 1Wwtwj-0006i2-Uf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposals for improving Bitcoin mining
	decentralization
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: Tue, 17 Jun 2014 14:01:13 -0000

--14dae93d8f52ff497c04fc089200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Because he cant change the coinbase once the proof of work is done.
 El 17/06/2014 15:58, "Ron Elliott" <ronaldbelliott@gmail.com> escribi=C3=
=B3:

> In this scenario how do you ensure the miner solving the block cannot
> reapportion the subsidy to himself rather than the pool?
> On Jun 17, 2014 2:09 AM, "Ra=C3=BAl Mart=C3=ADnez" <rme@i-rme.es> wrote:
>
>> First of all I apologice due to the possible mistakes in my writing
>> below, I am not a Bitcoin developer but I have some knowledge about it.
>>
>> ----
>>
>> We all know the recent news, Ghash pool controlling 51% of the hashrate.
>> While some consider it a threat others think that is not harmful.
>>
>> The thing is that we have to do something to stop this from happening
>> again.
>>
>> My proposal is to start thinking about miners that join a pool like
>> independent miners and not slave miners, this includes creating a new
>> mining protocol that does not rely on the pool sending the list of
>> transactions to include in a block. Each individual miner has to collect
>> transactions by his own and mine that, this can be achieved by running a
>> full node or by running a SPV like node that ask other nodes for
>> transactions.
>>
>> Once this protocol is developed and standarised we as a community could
>> require all pools to use it (because its better, because is more
>> trustless...), not by imposing it but by recommending it.
>>
>> Pool owners could send some instructions using this protocol to the mine=
r
>> about how many transactions to include per block (some pools want small
>> blocks), how many 0 fee transactions to include, how much is the minimum
>> fee per Kb to include transactions and some info about the Coinbase fiel=
d
>> in the block.
>>
>> This way is impossible to perform some of the possible 51% attacks:
>>
>>    - A pool owner cant mine a new chain (selfish mining) (pool clients
>>    have a SPV or full node that has checkpoints and ask other peers abou=
t the
>>    length of the chain)
>>    - A pool owner can't perform double spends or reverse transactions
>>    (pool clients know all the transactions relayed to the network, they =
know
>>    if they are already included on a block)
>>    - A pool owner cant decide which transactions not to include (but
>>    they can configure the minimum fee).
>>    - A pool owner cant get all the rewards by avoiding other pools from
>>    mining blocks (Because the pool client knows the last block independe=
ntly
>>    that is from his pool or other).
>>
>>
>> The only thing that a 51% pool owner can do is to shut down his pool and
>> drop the hashrate by 51% because he does not control the miners.
>>
>> If the pool owner owns all the hardware in the pool my proposal is not
>> valid, if the pool clients dont use this protocol my proposal is not val=
id.
>>
>>
>> I want to know if this is possible or its been developed or there is
>> already a working protocol that works like this, also I want to read oth=
er
>> people's ways to address this threat, thanks for reading.
>>
>>
>> ------------------------------------------------------------------------=
------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solution=
s
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>

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

<p dir=3D"ltr">Because he cant change the coinbase once the proof of work i=
s done.<br>
</p>
<div class=3D"gmail_quote">El 17/06/2014 15:58, &quot;Ron Elliott&quot; &lt=
;<a href=3D"mailto:ronaldbelliott@gmail.com">ronaldbelliott@gmail.com</a>&g=
t; escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">In this scenario how do you ensure the miner solving the blo=
ck cannot reapportion the subsidy to himself rather than the pool?</p>
<div class=3D"gmail_quote">On Jun 17, 2014 2:09 AM, &quot;Ra=C3=BAl Mart=C3=
=ADnez&quot; &lt;<a href=3D"mailto:rme@i-rme.es" target=3D"_blank">rme@i-rm=
e.es</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div>First of all I apologice due to the possible mistakes=
 in my writing below, I am not a Bitcoin developer but I have some knowledg=
e about it.</div><div><br></div><div>----</div><div><br></div>We all know t=
he recent news, Ghash pool controlling 51% of the hashrate. While some cons=
ider it a threat others think that is not harmful.<div>



<br></div><div>The thing is that we have to do something to stop this from =
happening again.</div><div><br></div><div>My proposal is to start thinking =
about miners that join a pool like independent miners and not slave miners,=
 this includes creating a new mining protocol that does not rely on the poo=
l sending the list of transactions to include in a block. Each individual m=
iner has to collect transactions by his own and mine that, this can be achi=
eved by running a full node or by running a SPV like node that ask other no=
des for transactions.</div>



<div><br></div><div>Once this protocol is developed and standarised we as a=
 community could require all pools to use it (because its better, because i=
s more trustless...), not by imposing it but by recommending it.</div>


<div>
<br></div><div>Pool owners could send some instructions using this protocol=
 to the miner about how many transactions to include per block (some pools =
want small blocks), how many 0 fee transactions to include, how much is the=
 minimum fee per Kb to include transactions and some info about the Coinbas=
e field in the block.</div>



<div><br></div><div>This way is impossible to perform some of the possible =
51% attacks:</div><div><ul><li>A pool owner cant mine a new chain (selfish =
mining) (pool clients have a SPV or full node that has checkpoints and ask =
other peers about the length of the chain)</li>



<li>A pool owner can&#39;t=C2=A0perform double spends or reverse transactio=
ns (pool clients know all the transactions relayed to the network, they kno=
w if they are already included on a block)</li><li>A pool owner cant decide=
 which transactions not to include (but they can configure the minimum fee)=
.<br>



</li><li>A pool owner cant get all the rewards by avoiding other pools from=
 mining blocks (Because the pool client knows the last block independently =
that is from his pool or other).</li></ul><div><br></div></div><div>The onl=
y thing that a 51% pool owner can do is to shut down his pool and drop the =
hashrate by 51% because he does not control the miners.</div>



<div><br></div><div>If the pool owner owns all the hardware in the pool my =
proposal is not valid, if the pool clients dont use this protocol my propos=
al is not valid.</div><div><br></div><div><br></div><div>I want to know if =
this is possible or its been developed or there is already a working protoc=
ol that works like this, also I want to read other people&#39;s ways to add=
ress this threat, thanks for reading.</div>



</div>
<br>-----------------------------------------------------------------------=
-------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing &amp; Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>
</blockquote></div>

--14dae93d8f52ff497c04fc089200--