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, "Karel B=C3=ADlek"= ; <<a href=3D"mailto:kb@karelbilek.com">kb@karelbilek.com</a>> 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> <<a href=3D"mailto:christophe.biocca@gmail.com">christophe.biocca@gmail.= com</a>> wrote:<br> > <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> > 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> > Unfortunately, it is opt-in,<br> > and GHash.io doesn'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> > Also most miners don't care and don't do the work to set it up= . To do<br> > transaction inclusion themselves, they'd need to run a full node,<= br> > which is a bit more work and resources than just pointing hashpower at= <br> > a stratum server.<br> <br> Also, yep. If the miners cared about 51% attack, they wouldn'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> > If you figure out a way to make GBT widely used (>50% hashpower), k= udos to you.<br> ><br> > On Tue, Jun 17, 2014 at 4:57 AM, Ra=C3=BAl Mart=C3=ADnez <<a href= =3D"mailto:rme@i-rme.es">rme@i-rme.es</a>> wrote:<br> >> First of all I apologice due to the possible mistakes in my writin= g below, I<br> >> am not a Bitcoin developer but I have some knowledge about it.<br> >><br> >> ----<br> >><br> >> We all know the recent news, Ghash pool controlling 51% of the has= hrate.<br> >> While some consider it a threat others think that is not harmful.<= br> >><br> >> The thing is that we have to do something to stop this from happen= ing again.<br> >><br> >> My proposal is to start thinking about miners that join a pool lik= e<br> >> independent miners and not slave miners, this includes creating a = new mining<br> >> protocol that does not rely on the pool sending the list of transa= ctions to<br> >> include in a block. Each individual miner has to collect transacti= ons by his<br> >> own and mine that, this can be achieved by running a full node or = by running<br> >> a SPV like node that ask other nodes for transactions.<br> >><br> >> Once this protocol is developed and standarised we as a community = could<br> >> require all pools to use it (because its better, because is more<b= r> >> trustless...), not by imposing it but by recommending it.<br> >><br> >> Pool owners could send some instructions using this protocol to th= e miner<br> >> about how many transactions to include per block (some pools want = small<br> >> blocks), how many 0 fee transactions to include, how much is the m= inimum fee<br> >> per Kb to include transactions and some info about the Coinbase fi= eld in the<br> >> block.<br> >><br> >> This way is impossible to perform some of the possible 51% attacks= :<br> >><br> >> A pool owner cant mine a new chain (selfish mining) (pool clients = have a SPV<br> >> or full node that has checkpoints and ask other peers about the le= ngth of<br> >> the chain)<br> >> A pool owner can't perform double spends or reverse transactio= ns (pool<br> >> clients know all the transactions relayed to the network, they kno= w if they<br> >> are already included on a block)<br> >> A pool owner cant decide which transactions not to include (but th= ey can<br> >> configure the minimum fee).<br> >> A pool owner cant get all the rewards by avoiding other pools from= mining<br> >> blocks (Because the pool client knows the last block independently= that is<br> >> from his pool or other).<br> >><br> >><br> >> The only thing that a 51% pool owner can do is to shut down his po= ol and<br> >> drop the hashrate by 51% because he does not control the miners.<b= r> >><br> >> If the pool owner owns all the hardware in the pool my proposal is= not<br> >> valid, if the pool clients dont use this protocol my proposal is n= ot valid.<br> >><br> >><br> >> I want to know if this is possible or its been developed or there = is already<br> >> a working protocol that works like this, also I want to read other= people's<br> >> ways to address this threat, thanks for reading.<br> >><br> >> ------------------------------------------------------------------= ------------<br> >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk So= lutions<br> >> 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 & Easy Data Explo= ration<br> >> <a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http= ://p.sf.net/sfu/hpccsystems</a><br> >> _______________________________________________<br> >> Bitcoin-development mailing list<br> >> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco= in-development@lists.sourceforge.net</a><br> >> <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> >><br> ><br> > ----------------------------------------------------------------------= --------<br> > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Soluti= ons<br> > 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 & Easy Data Explorati= on<br> > <a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p= .sf.net/sfu/hpccsystems</a><br> > _______________________________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <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--