To: <bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 24 May 2012 18:27:42 +0100
From: Robert McKay <robert@mckay.com>
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
Message-ID: <81d184ee3a3f5386f6b23090a2a55718@webmail.mckay.com>
User-Agent: Roundcube Webmail/0.5.3
Subject: Re: [Bitcoin-development] =?utf-8?q?Punishing_empty_blocks=3F?=
Precedence: list

On Thu, 24 May 2012 12:33:12 -0400, 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

If miners wanted to continue mining empty blocks without bothering to 
monitor the Tx pool they would just switch to stuffing the empty blocks 
with a dummy transaction of their own to get round your new rules. They 
could also spam them to the p2p network so that they end up in the 
mempool if that were necessary. This would probably still be slightly 
easier than 'doing it properly'.

Once the block reward halves in a few months time then receiving 
transaction fees will probably become more important to the miner's 
profit and loss calculations and they'll spend the extra time to 
implement proper transaction processing. I suspect if we do nothing this 
particular issue will go away. Perhaps it could be helped along by 
publishing some example code to make it easier for them.

The ability to refuse transactions seems like an important part of the 
game theory of transaction pricing. Miners are supposed to be able to 
jack up transaction costs by declining to process no fee or too low fee 
(in their opinion) transactions.. the counter balance is that they are 
losing money by doing that and leaving more on the table for the next 
miner to score a block.

I expect that in the future there will be other instances when people 
complain that the miners are being 'unfair' and that the rules should be 
changed in some way to lower transaction fees (ie: increase block size).

If block sizes are increased ever larger and miners aren't allowed to 
refuse to process transactions it will get rid of the financial 
motivation for mining and less mining will happen. We should be very 
careful when making these kinds of changes.

Setting percentage quotas of stuff in the mempool sounds dangerous.. 
miners that hear about a block from a rival miner soon enough could 
possibly DOS the mempool on the rest of the network to get the block 
rejected. I think it should be legitimate not to publish a transaction 
to the p2p network at all.. in the future there will probably be lots of 
networks other than the p2p network.. right now we have the IPv6 network 
and the IPv4 network.. in the future there could be many other protocols 
and perhaps not all transactions will make it back to the old legacy 
ipv4 p2p network or into the mempool of bitcoin nodes on that network.. 
but they should still be able to get into the block chain.

Rob