From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwpJj-0000it-BP for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 09:04:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of i-rme.es designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; envelope-from=rme@i-rme.es; helo=mail-la0-f44.google.com; Received: from mail-la0-f44.google.com ([209.85.215.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwpJh-0003Ks-EC for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 09:04:35 +0000 Received: by mail-la0-f44.google.com with SMTP id ty20so1721905lab.31 for ; Tue, 17 Jun 2014 02:04:26 -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:from:date:message-id:subject:cc :content-type; bh=9rkOAo81OUuToTgwBB4cCDBQzoIS8B/82k4Xv9a0vG0=; b=LHUwSFuzKoMpiGdDQ8Jw1ovQoFz+0d7vyGWuaMUVO0DeK9vlDP8FKb4R7F+Br+13YW bbzNjokFHNAlBHnAsFrF25nB5lUrJX0iKmKzGGSNoEwS1Y8qPftZ+hwOdjLX6Bs/a8PO TohVp0nRcEdHUWYEpp90W7KVFmS5SLQ2BQsIXhKUNkJmHbeojv4qmb38FMF46znPIW5x k8Jkmt0fu8aks2ScPLHzfz/9UZ4IPwCVwHHdgxkRNdsACdd1V3xeyZ0chu4qbOykLOeQ i8yShP0vq+cwnh52902M+QIi/pTijlJ9bw/cZQ2KjcYBpEtMHd+dxilWAonRdc+JYvVf 0IBw== X-Gm-Message-State: ALoCoQld1lpE/kf7cL9OaAErCKnqkzOiJrhNokWNwyp9lMkFuJaIb3Cquvh7PoamtH+p4oMNzo28 X-Received: by 10.152.4.39 with SMTP id h7mr18040192lah.12.1402995456087; Tue, 17 Jun 2014 01:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.199.8 with HTTP; Tue, 17 Jun 2014 01:57:06 -0700 (PDT) X-Originating-IP: [85.251.84.81] From: =?UTF-8?B?UmHDumwgTWFydMOtbmV6?= Date: Tue, 17 Jun 2014 10:57:06 +0200 Message-ID: Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e013d1c46c82de704fc04559b 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.2 MISSING_HEADERS Missing To: header 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: 1WwpJh-0003Ks-EC Subject: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:04:35 -0000 --089e013d1c46c82de704fc04559b Content-Type: text/plain; charset=UTF-8 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 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 independently 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 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. --089e013d1c46c82de704fc04559b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.

----

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.

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

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.

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.

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=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)
  • 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 independently = that is from his pool or other).

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.

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.


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.
--089e013d1c46c82de704fc04559b--