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 ) id 1SXehS-0003RX-Mp for bitcoin-development@lists.sourceforge.net; Thu, 24 May 2012 20:31:58 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1SXehO-0002A5-OH for bitcoin-development@lists.sourceforge.net; Thu, 24 May 2012 20:31:58 +0000 Received: from ishibashi.localnet (unknown [97.96.85.141]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 0887A56056E; Thu, 24 May 2012 20:31:47 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Thu, 24 May 2012 20:31:38 +0000 User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoonestfix-intelwr; KDE/4.8.1; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205242031.39804.luke@dashjr.org> X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1SXehO-0002A5-OH Subject: Re: [Bitcoin-development] Punishing empty blocks? 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: Thu, 24 May 2012 20:31:58 -0000 On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote: > There appears to be some non-trivial mining power devoted to mining > empty blocks. Even with satoshi's key observation -- hash a fixed > 80-byte header, not the entire block -- some miners still find it > easier to mine empty blocks, rather than watch the network for new > transactions. > > Therefore I was wondering what people thought about a client > implementation change: > > - Do not store or relay empty blocks, if time since last block < X > (where X = 60 minutes, perhaps) > > or even stronger, > > - Ensure latest block includes at least X percent of mempool > unconfirmed TXs These are problematic for legitimate miners: 1) The freedom to reject transactions based on fees or spam filters, is severely restricted. As mentioned in other replies, this is an important point of Bitcoin's design. 1b) This punishes miners with superior transaction spam filtering. As with all spam filtering, it is often an "arms race" and therefore the filter rules must be kept private by the miners, and therefore cannot be disclosed for the validating clients to take into consideration. 2) For a few seconds after a new block is received, the new transaction merkle root(s) are not finished calculating. During this time, most miners are working on "blank" blocks with the new previousblockhash but no transactions. If those blocks are ignored, miners are forced to shutdown mining during this time. 3) As you mentioned, illegitimate miners can easily workaround these restrictions (even the second one, by flooding the network with their own transactions). This puts the legitimate miners at a disadvantage in their own search for valid blocks, unless they also come up with counter-measures themselves. The argument that these are not rule changes is flawed: 1) As of right now, 99% of the network runs a single client. Anything this client rejects does de facto become a rule change. 2) Even if there were a diverse ecosystem of clients in place, discouragement rules that potentially affect legitimate miners significantly mess with the odds of finding a block. 3) If legitimate miners do not adopt counter-rules to bypass these new restrictions, the illegitimate miners are left with an even larger percentage of blocks found. To summarize, I believe such a change as proposed would be very harmful to Bitcoin. Luke