From: "Luke-Jr" <luke@dashjr.org>
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: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201205242031.39804.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Precedence: list

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