diff options
| author | Ron Elliott <ronaldbelliott@gmail.com> | 2014-06-17 06:58:53 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-06-17 13:59:02 +0000 |
| commit | 0cc02c2a4d1bbc546f741aba4fcae896c1bbdc65 (patch) | |
| tree | 4ddf1fbddaf1eeab21b724eac75949233cf86c4e | |
| parent | 33643c2efeec1f64820867280ce6604254b25ac7 (diff) | |
| download | pi-bitcoindev-0cc02c2a4d1bbc546f741aba4fcae896c1bbdc65.tar.gz pi-bitcoindev-0cc02c2a4d1bbc546f741aba4fcae896c1bbdc65.zip | |
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
| -rw-r--r-- | 6e/b30bec6147fcc6f6718180ec25ef8eb2691748 | 235 |
1 files changed, 235 insertions, 0 deletions
diff --git a/6e/b30bec6147fcc6f6718180ec25ef8eb2691748 b/6e/b30bec6147fcc6f6718180ec25ef8eb2691748 new file mode 100644 index 000000000..9b8ba9885 --- /dev/null +++ b/6e/b30bec6147fcc6f6718180ec25ef8eb2691748 @@ -0,0 +1,235 @@ +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 <ronaldbelliott@gmail.com>) id 1Wwtug-0006vl-8k + for bitcoin-development@lists.sourceforge.net; + Tue, 17 Jun 2014 13:59:02 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.172 as permitted sender) + client-ip=209.85.216.172; envelope-from=ronaldbelliott@gmail.com; + helo=mail-qc0-f172.google.com; +Received: from mail-qc0-f172.google.com ([209.85.216.172]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Wwtud-0006dn-0z + for bitcoin-development@lists.sourceforge.net; + Tue, 17 Jun 2014 13:59:02 +0000 +Received: by mail-qc0-f172.google.com with SMTP id o8so9990086qcw.17 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 17 Jun 2014 06:58:53 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.140.80.67 with SMTP id b61mr13733566qgd.98.1403013533504; + Tue, 17 Jun 2014 06:58:53 -0700 (PDT) +Received: by 10.140.93.69 with HTTP; Tue, 17 Jun 2014 06:58:53 -0700 (PDT) +Received: by 10.140.93.69 with HTTP; Tue, 17 Jun 2014 06:58:53 -0700 (PDT) +In-Reply-To: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com> +References: <CA+8=xuKmE2rgNK+Q4g+Gqvy3QuYAXzVRYtWKC2VttuB_LJmyMA@mail.gmail.com> +Date: Tue, 17 Jun 2014 06:58:53 -0700 +Message-ID: <CAMEND1hS2j6dSjwvRSmVn_=UV-r7gujJ+Wo1VLH3nH54F3vBmQ@mail.gmail.com> +From: Ron Elliott <ronaldbelliott@gmail.com> +To: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= <rme@i-rme.es> +Content-Type: multipart/alternative; boundary=001a11c13692479e6b04fc088b18 +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 + (ronaldbelliott[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: 1Wwtud-0006dn-0z +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 13:59:02 -0000 + +--001a11c13692479e6b04fc088b18 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +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 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 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 k= +now +> 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 independen= +tly +> 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 vali= +d. +> +> +> 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 othe= +r +> 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 +> +> + +--001a11c13692479e6b04fc088b18 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<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, "Ra=C3=BAl Mart=C3= +=ADnez" <<a href=3D"mailto:rme@i-rme.es">rme@i-rme.es</a>> wrote= +:<br type=3D"attribution"><blockquote class=3D"gmail_quote" 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'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'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 & 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">Bitcoin-develo= +pment@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> + +--001a11c13692479e6b04fc088b18-- + + |