path: root/d0/9e9d3ffadd4443f9630d05ce0ffb27f2d00a30

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