diff options
| author | Hector Chu <hectorchu@gmail.com> | 2015-02-11 08:54:15 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-11 08:54:44 +0000 |
| commit | 0244a6f0498375f00aebe557f1dc1652dd88371e (patch) | |
| tree | 08818c5bdd6d459719575100d8a2e7cc775c4848 | |
| parent | 7fa349164c558d684a78def7d4e0247d9826efb3 (diff) | |
| download | pi-bitcoindev-0244a6f0498375f00aebe557f1dc1652dd88371e.tar.gz pi-bitcoindev-0244a6f0498375f00aebe557f1dc1652dd88371e.zip | |
[Bitcoin-development] Proposal: Requiring a miner's signature in the block header
| -rw-r--r-- | 52/7ad4c7ca9c7b4da02329fafe824145de621554 | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/52/7ad4c7ca9c7b4da02329fafe824145de621554 b/52/7ad4c7ca9c7b4da02329fafe824145de621554 new file mode 100644 index 000000000..94c266c8e --- /dev/null +++ b/52/7ad4c7ca9c7b4da02329fafe824145de621554 @@ -0,0 +1,169 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <hectorchu@gmail.com>) id 1YLT4F-0004Vj-Km + for bitcoin-development@lists.sourceforge.net; + Wed, 11 Feb 2015 08:54:44 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.215.54 as permitted sender) + client-ip=209.85.215.54; envelope-from=hectorchu@gmail.com; + helo=mail-la0-f54.google.com; +Received: from mail-la0-f54.google.com ([209.85.215.54]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YLT4E-00077K-J7 + for bitcoin-development@lists.sourceforge.net; + Wed, 11 Feb 2015 08:54:43 +0000 +Received: by labpn19 with SMTP id pn19so1949175lab.4 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 11 Feb 2015 00:54:36 -0800 (PST) +X-Received: by 10.152.8.104 with SMTP id q8mr27523320laa.56.1423644876222; + Wed, 11 Feb 2015 00:54:36 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.114.62.211 with HTTP; Wed, 11 Feb 2015 00:54:15 -0800 (PST) +From: Hector Chu <hectorchu@gmail.com> +Date: Wed, 11 Feb 2015 08:54:15 +0000 +Message-ID: <CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com> +To: bitcoin-development@lists.sourceforge.net +Content-Type: multipart/alternative; boundary=001a11c311982235a7050ecc273b +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 + (hectorchu[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: 1YLT4E-00077K-J7 +Subject: [Bitcoin-development] Proposal: Requiring a miner's signature in + the block header +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: Wed, 11 Feb 2015 08:54:44 -0000 + +--001a11c311982235a7050ecc273b +Content-Type: text/plain; charset=UTF-8 + +A proposal for stemming the tide of mining centralisation -- Requiring a +miner's signature in the block header (the whole of which is hashed), and +paying out coinbase to the miner's public key. + +Please comment on whether this idea is feasible, has been thought of before, +etc., etc. Thank you. + +Motivation +---------- + +Mining is centralising to a handful of pool operators. This is bad for a +number of political reasons, which we won't go into right now. But I have +always believed that some years down the line, they could hold the users +hostage and change the rules to suit themselves. For instance by eliminating +the halving of the block reward. + +Solution +-------- + +Currently the block header is formed by the pool operator and distributed +for +hashing by the pooled miners. It is possible to divide the work among the +miners as the only thing that is used to search the hash space is by +changing +a nonce or two. + +I propose that we require each miner to sign the block header prior to +hashing. The signature will be included in the data that is hashed. Further, +the coinbase for the block must only pay out to the public key counterpart +of +the private key used to sign the block header. + +A valid block will therefore have a signature in the block header that is +verified by the public key being paid by the coinbase transaction. + +Ramifications +------------- + +Work can no longer be divided among the pooled miners as before, without +sharing the pool's private key amongst all of them. If the pool does try to +take this route, then any of the miners may redeem the coinbase when it +matures. Therefore, all miners will use their own key pair. + +This will make it difficult to form a cooperating pool of miners who may not +trust each other, as the block rewards will be controlled by disparate +parties +and not by the pool operator. Only a tight clique of trusted miners would be +able to form their own private pool in such an environment. + +Attacks +------- + +Pooled hashpower, instead of earning bitcoins legitimately may try to break +the system instead. They may try a double-spending attack, but in order to +leverage the pool to its full potential the pool operator would again have +to +share their private key with the whole pool. Due to the increased +cooperation +and coordination required for an attack, the probability of a 51% attack is +much reduced. + +--001a11c311982235a7050ecc273b +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>A proposal for stemming the tide of mining centralisa= +tion -- Requiring a</div><div>miner's signature in the block header (th= +e whole of which is hashed), and</div><div>paying out coinbase to the miner= +'s public key.</div><div><br></div><div>Please comment on whether this = +idea is feasible, has been thought of before,</div><div>etc., etc. Thank yo= +u.</div><div><br></div><div>Motivation</div><div>----------</div><div><br><= +/div><div>Mining is centralising to a handful of pool operators. This is ba= +d for a</div><div>number of political reasons, which we won't go into r= +ight now. But I have</div><div>always believed that some years down the lin= +e, they could hold the users</div><div>hostage and change the rules to suit= + themselves. For instance by eliminating</div><div>the halving of the block= + reward.</div><div><br></div><div>Solution</div><div>--------</div><div><br= +></div><div>Currently the block header is formed by the pool operator and d= +istributed for</div><div>hashing by the pooled miners. It is possible to di= +vide the work among the</div><div>miners as the only thing that is used to = +search the hash space is by changing</div><div>a nonce or two.</div><div><b= +r></div><div>I propose that we require each miner to sign the block header = +prior to</div><div>hashing. The signature will be included in the data that= + is hashed. Further,</div><div>the coinbase for the block must only pay out= + to the public key counterpart of</div><div>the private key used to sign th= +e block header.</div><div><br></div><div>A valid block will therefore have = +a signature in the block header that is</div><div>verified by the public ke= +y being paid by the coinbase transaction.</div><div><br></div><div>Ramifica= +tions</div><div>-------------</div><div><br></div><div>Work can no longer b= +e divided among the pooled miners as before, without</div><div>sharing the = +pool's private key amongst all of them. If the pool does try to</div><d= +iv>take this route, then any of the miners may redeem the coinbase when it<= +/div><div>matures. Therefore, all miners will use their own key pair.</div>= +<div><br></div><div>This will make it difficult to form a cooperating pool = +of miners who may not</div><div>trust each other, as the block rewards will= + be controlled by disparate parties</div><div>and not by the pool operator.= + Only a tight clique of trusted miners would be</div><div>able to form thei= +r own private pool in such an environment.</div><div><br></div><div>Attacks= +</div><div>-------</div><div><br></div><div>Pooled hashpower, instead of ea= +rning bitcoins legitimately may try to break</div><div>the system instead. = +They may try a double-spending attack, but in order to</div><div>leverage t= +he pool to its full potential the pool operator would again have to</div><d= +iv>share their private key with the whole pool. Due to the increased cooper= +ation</div><div>and coordination required for an attack, the probability of= + a 51% attack is</div><div>much reduced.</div><div><br></div></div> + +--001a11c311982235a7050ecc273b-- + + |