path: root/3e/038baff0357f09b5df6c16f88ce5d5709e3e43

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <rme@i-rme.es>) id 1Wwyd3-00077j-Io
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 19:01:09 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of i-rme.es
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=rme@i-rme.es;
	helo=mail-la0-f52.google.com; 
Received: from mail-la0-f52.google.com ([209.85.215.52])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wwyd1-0005o5-Hj
	for bitcoin-development@lists.sourceforge.net;
	Tue, 17 Jun 2014 19:01:09 +0000
Received: by mail-la0-f52.google.com with SMTP id ty20so1851846lab.11
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 17 Jun 2014 12:01:00 -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=U2Z9uy6PJdMDa4RsZaxvs48XudUqmWcGtboyGuUO/8w=;
	b=i+/Ey0X/9Y9c9/dsTZQFErFbH+0QIsf4B3rB0jk1cWgZyihP3pYQjCZNNjzu30KrWG
	0nm6bwaESAcKGT9om9yLiaZTn5SPVC+6Oado8MH+X+E8XwIb1cgAOxumHAuxPQ8cL96f
	ZeRgWAsJr0JLgfFAqLbU3A6aRoVm5DF79BVtKq0+RTmRHyzdUTG5T/1VaoxM3wr1okC8
	dfXiOGHa+egxj7TMMTyA07REEpPr/uhurxbss6Z3LiHW28xBRnLNaw8G6UHt+M/8b5x8
	p5Xt0f/o/YlAivINpidtxmSoQIvzcjvkMSZPhfuyPORH+OTg1xf/IWCO0d1+rDa5kn3F
	XBaQ==
X-Gm-Message-State: ALoCoQneUTWWqVUi40B2L6lYRV06aNoqCuLcHHyUrga4tbbTArelNhllw/mhhVC4/zmUF8CYJJbR
MIME-Version: 1.0
X-Received: by 10.112.50.2 with SMTP id y2mr2636980lbn.66.1403031660235; Tue,
	17 Jun 2014 12:01:00 -0700 (PDT)
Received: by 10.152.199.8 with HTTP; Tue, 17 Jun 2014 12:01:00 -0700 (PDT)
X-Originating-IP: [31.4.239.206]
Received: by 10.152.199.8 with HTTP; Tue, 17 Jun 2014 12:01:00 -0700 (PDT)
In-Reply-To: <CAGUkT8ZTtR_ysR+0Ufq4k=SLeifEOQYtrak6G_iJRQqc3dt6Jg@mail.gmail.com>
References: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com>
	<CANOOu=9W42upZGtXWvRwyJH0tO766VT37jAR23V_rCZ9+qxTTw@mail.gmail.com>
	<CAGUkT8ZTtR_ysR+0Ufq4k=SLeifEOQYtrak6G_iJRQqc3dt6Jg@mail.gmail.com>
Date: Tue, 17 Jun 2014 21:01:00 +0200
Message-ID: <CA+8=xuLJPQnx8OdoeWRNemDme8h5ySHOg9JOH5A6Norgk0xBgg@mail.gmail.com>
From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es>
To: =?UTF-8?B?S2FyZWwgQsOtbGVr?= <kb@karelbilek.com>
Content-Type: multipart/alternative; boundary=001a113367acb7a1c604fc0cc33c
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: 1Wwyd1-0005o5-Hj
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 19:01:10 -0000

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

But miners dont want to run full nodes, its better to develop some SPV like
that connects to some nodes.

Also I believe that stratum mining protocol improves some performance
things that GBT lacks.

If a new protocol that requires blocks created by miners is developed and
named in a cool way, miners could ask for protocol support to his favourite
pool.
El 17/06/2014 20:26, "Karel B=C3=ADlek" <kb@karelbilek.com> escribi=C3=B3:

> On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
> <christophe.biocca@gmail.com> wrote:
> > https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> > of the pooling-centralization problems.
>
> This. There is no need to create anything new when GBT already exists.
> In my opinion.
>
> > Unfortunately, it is opt-in,
> > and GHash.io doesn't support it.
>
> Yep. As pools in general are not a part of the bitcoin protocol itself
> (nobody cares how the work happened), I am not sure how this can be
> forced.
>
> > Also most miners don't care and don't do the work to set it up. To do
> > transaction inclusion themselves, they'd need to run a full node,
> > which is a bit more work and resources than just pointing hashpower at
> > a stratum server.
>
> Also, yep. If the miners cared about 51% attack, they wouldn't join
> ghash in the first place. All the miners willingly accept the risk in
> joining the big pool.
>
> K. B.
>
> > If you figure out a way to make GBT widely used (>50% hashpower), kudos
> to you.
> >
> > On Tue, Jun 17, 2014 at 4:57 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 hashrat=
e.
> >> 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 coul=
d
> >> 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
> miner
> >> about how many transactions to include per block (some pools want smal=
l
> >> 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 field
> 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 about 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 c=
an
> >> 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 independently tha=
t
> is
> >> from his pool or other).
> >>
> >>
> >> The only thing that a 51% pool owner can do is to shut down his pool a=
nd
> >> 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
> valid.
> >>
> >>
> >> 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 other
> people's
> >> ways to address this threat, thanks for reading.
> >>
> >>
> -------------------------------------------------------------------------=
-----
> >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
> Solutions
> >> 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
> >>
> >
> >
> -------------------------------------------------------------------------=
-----
> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutio=
ns
> > 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
>

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

<p dir=3D"ltr">But miners dont want to run full nodes, its better to develo=
p some SPV like that connects to some nodes.</p>
<p dir=3D"ltr">Also I believe that stratum mining protocol improves some pe=
rformance things that GBT lacks.</p>
<p dir=3D"ltr">If a new protocol that requires blocks created by miners is =
developed and named in a cool way, miners could ask for protocol support to=
 his favourite pool.</p>
<div class=3D"gmail_quote">El 17/06/2014 20:26, &quot;Karel B=C3=ADlek&quot=
; &lt;<a href=3D"mailto:kb@karelbilek.com">kb@karelbilek.com</a>&gt; escrib=
i=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">
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca<br>
&lt;<a href=3D"mailto:christophe.biocca@gmail.com">christophe.biocca@gmail.=
com</a>&gt; wrote:<br>
&gt; <a href=3D"https://en.bitcoin.it/wiki/Getblocktemplate" target=3D"_bla=
nk">https://en.bitcoin.it/wiki/Getblocktemplate</a> is supposed to solve mo=
st<br>
&gt; of the pooling-centralization problems.<br>
<br>
This. There is no need to create anything new when GBT already exists.<br>
In my opinion.<br>
<br>
&gt; Unfortunately, it is opt-in,<br>
&gt; and GHash.io doesn&#39;t support it.<br>
<br>
Yep. As pools in general are not a part of the bitcoin protocol itself<br>
(nobody cares how the work happened), I am not sure how this can be<br>
forced.<br>
<br>
&gt; Also most miners don&#39;t care and don&#39;t do the work to set it up=
. To do<br>
&gt; transaction inclusion themselves, they&#39;d need to run a full node,<=
br>
&gt; which is a bit more work and resources than just pointing hashpower at=
<br>
&gt; a stratum server.<br>
<br>
Also, yep. If the miners cared about 51% attack, they wouldn&#39;t join<br>
ghash in the first place. All the miners willingly accept the risk in<br>
joining the big pool.<br>
<br>
K. B.<br>
<br>
&gt; If you figure out a way to make GBT widely used (&gt;50% hashpower), k=
udos to you.<br>
&gt;<br>
&gt; On Tue, Jun 17, 2014 at 4:57 AM, Ra=C3=BAl Mart=C3=ADnez &lt;<a href=
=3D"mailto:rme@i-rme.es">rme@i-rme.es</a>&gt; wrote:<br>
&gt;&gt; First of all I apologice due to the possible mistakes in my writin=
g below, I<br>
&gt;&gt; am not a Bitcoin developer but I have some knowledge about it.<br>
&gt;&gt;<br>
&gt;&gt; ----<br>
&gt;&gt;<br>
&gt;&gt; We all know the recent news, Ghash pool controlling 51% of the has=
hrate.<br>
&gt;&gt; While some consider it a threat others think that is not harmful.<=
br>
&gt;&gt;<br>
&gt;&gt; The thing is that we have to do something to stop this from happen=
ing again.<br>
&gt;&gt;<br>
&gt;&gt; My proposal is to start thinking about miners that join a pool lik=
e<br>
&gt;&gt; independent miners and not slave miners, this includes creating a =
new mining<br>
&gt;&gt; protocol that does not rely on the pool sending the list of transa=
ctions to<br>
&gt;&gt; include in a block. Each individual miner has to collect transacti=
ons by his<br>
&gt;&gt; own and mine that, this can be achieved by running a full node or =
by running<br>
&gt;&gt; a SPV like node that ask other nodes for transactions.<br>
&gt;&gt;<br>
&gt;&gt; Once this protocol is developed and standarised we as a community =
could<br>
&gt;&gt; require all pools to use it (because its better, because is more<b=
r>
&gt;&gt; trustless...), not by imposing it but by recommending it.<br>
&gt;&gt;<br>
&gt;&gt; Pool owners could send some instructions using this protocol to th=
e miner<br>
&gt;&gt; about how many transactions to include per block (some pools want =
small<br>
&gt;&gt; blocks), how many 0 fee transactions to include, how much is the m=
inimum fee<br>
&gt;&gt; per Kb to include transactions and some info about the Coinbase fi=
eld in the<br>
&gt;&gt; block.<br>
&gt;&gt;<br>
&gt;&gt; This way is impossible to perform some of the possible 51% attacks=
:<br>
&gt;&gt;<br>
&gt;&gt; A pool owner cant mine a new chain (selfish mining) (pool clients =
have a SPV<br>
&gt;&gt; or full node that has checkpoints and ask other peers about the le=
ngth of<br>
&gt;&gt; the chain)<br>
&gt;&gt; A pool owner can&#39;t perform double spends or reverse transactio=
ns (pool<br>
&gt;&gt; clients know all the transactions relayed to the network, they kno=
w if they<br>
&gt;&gt; are already included on a block)<br>
&gt;&gt; A pool owner cant decide which transactions not to include (but th=
ey can<br>
&gt;&gt; configure the minimum fee).<br>
&gt;&gt; A pool owner cant get all the rewards by avoiding other pools from=
 mining<br>
&gt;&gt; blocks (Because the pool client knows the last block independently=
 that is<br>
&gt;&gt; from his pool or other).<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The only thing that a 51% pool owner can do is to shut down his po=
ol and<br>
&gt;&gt; drop the hashrate by 51% because he does not control the miners.<b=
r>
&gt;&gt;<br>
&gt;&gt; If the pool owner owns all the hardware in the pool my proposal is=
 not<br>
&gt;&gt; valid, if the pool clients dont use this protocol my proposal is n=
ot valid.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I want to know if this is possible or its been developed or there =
is already<br>
&gt;&gt; a working protocol that works like this, also I want to read other=
 people&#39;s<br>
&gt;&gt; ways to address this threat, thanks for reading.<br>
&gt;&gt;<br>
&gt;&gt; ------------------------------------------------------------------=
------------<br>
&gt;&gt; HPCC Systems Open Source Big Data Platform from LexisNexis Risk So=
lutions<br>
&gt;&gt; Find What Matters Most in Your Big Data with HPCC Systems<br>
&gt;&gt; Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
&gt;&gt; Leverages Graph Analysis for Fast Processing &amp; Easy Data Explo=
ration<br>
&gt;&gt; <a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http=
://p.sf.net/sfu/hpccsystems</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Bitcoin-development mailing list<br>
&gt;&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco=
in-development@lists.sourceforge.net</a><br>
&gt;&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/b=
itcoin-development</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; HPCC Systems Open Source Big Data Platform from LexisNexis Risk Soluti=
ons<br>
&gt; Find What Matters Most in Your Big Data with HPCC Systems<br>
&gt; Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
&gt; Leverages Graph Analysis for Fast Processing &amp; Easy Data Explorati=
on<br>
&gt; <a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p=
.sf.net/sfu/hpccsystems</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
</blockquote></div>

--001a113367acb7a1c604fc0cc33c--