From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 79E10259; Fri, 24 Mar 2017 16:03:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from forward2.bravehost.com (forward2.bravehost.com [65.39.211.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AFC7EF1; Fri, 24 Mar 2017 16:03:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at bravehost.com Received: from [10.137.4.20] (tor2.anonymizer.ccc.de [217.115.10.132]) (Authenticated sender: cannon@cannon-ciota.info) by forward2.bravehost.com (Postfix) with ESMTPSA id 94E06115A; Fri, 24 Mar 2017 09:03:36 -0700 (PDT) X-Priority: 2 (High) From: CANNON Message-ID: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info> Date: Fri, 24 Mar 2017 16:03:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 To: undisclosed-recipients: ; Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 24 Mar 2017 16:05:44 +0000 Subject: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 16:03:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 When the original white paper was written the idea was that nodes would be miners at same time. That the distribution of mining power being mostly on par with the distribution of nodes if I understand correctly. The problem we face now I fear, is the mining power becoming centralized. Even if every bitcoin node invested a $1000 into mining power and mined at a loss, it still would not even make a dent in hash distribution. Currently there are around 6000 known nodes. If each node invested $1000 for say 10 ths of hashing power. At current hashrate of around 3,674,473,142 GH/s this would only make up %16 of hash power. This is out of balance as while nodes are distributed mining power is becoming very centralized due to the creation of monopolization of ASICs. The problem we are facing is a small group of a couple people whom control a large amount and growing of hash power. At time of this writing it has quickly risen to 39% and at current rate will soon become 50% of hashing power that is controlled by a small group of a few people. Their intentions are too hijack the bitcoin network to a cryptocurrency that suits their dangerous agenda. Dangerous because their plan would centralize power of consensus as I understand it, to themselves the miners. Dangerous also because the code base of the attempting subverters is buggy, insecure, and reckless from a technological standpoint. Even though they only have very minute amount of nodes compared to legitimate bitcion nodes, the danger is that they are very quickly taking over in mining power. While it is true that nodes will not accept invalid blocks that would be attempted to be pushed by the conspirators, they are threatening to attack the valid (or in their words, "minority chain") by dedicating some mining power soley to attacking the valid chain by mining empty blocks and orphaning the valid chain. So even though the majority of nodes would be enforcing what blocks are valid and as a result block the non-compliant longer chain, the conspiring miner can simply (as they are currently threatening to) make the valid chain unuseable by mining empty blocks. If a malicious miner with half or majority control passes invalid blocks, the worst case scenario is a hardfork coin split in which the non-compliant chain becomes an alt. However the problem is that this malicious miner is very recently threatening to not just simply fork, but to kill the valid chain to force economic activity to the adversary controlled chain. If we can simply defend against attacks to the valid chain, we can prevent the valid chain from dying. While empty or near empty blocks would generally be protected by the incentive of miners to make money. The threat is there if the malicious miner with majority control is willing to lose out on these transaction fees and block reward if their intention is to suppress it to force the majority onto their chain. Proposal for potential solution Update nodes to ignore empty blocks, so this way mined empty blocks cannot be used to DOS attack the blockchain. But what about defense from say, blocks that are not empty but intentionally only have a couple transactions in it? Possible to have nodes not only ignore empty blocks, but also blocks that are abnormally small compared to number of valid transactions in mempool? For example would be something like this: If block = (empty OR <%75 of mempool) THEN discard This threshold just an example. What would be any potentials risks and attacks resulting from both having such new rulesets and not doing anything? Lets assume that the first problem of blocking empty or near empty blocks has been mitigated with the above proposed solution. How likely and possible would it be for a malicious miner with lots of mining power to orphan the chain after so many blocks even with non empty blocks? Is there a need to mitigate this? If so is it possible? Time is running short I fear. There needs to be discussion on various attacks and how they can be guarded against along with various other contingency plans. - -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: cannon@cannon-ciota.info NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. If this matters to you, use PGP. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2 WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/ S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d Gu3oWoE1ld+BC6At28AD =SSuj -----END PGP SIGNATURE-----