<oembed><type>rich</type><version>1.0</version><author_name>npub1t6suh64e65qzzjtthffl6sa3cagp6k9usnx4qev4jsjzf7xud8psdhe2py</author_name><author_url>https://nostr.ae/npub1t6suh64e65qzzjtthffl6sa3cagp6k9usnx4qev4jsjzf7xud8psdhe2py</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2012-05-24&#xA;📝 Original message:On Thu, 24 May 2012 12:33:12 -0400, Jeff Garzik wrote:&#xA;&gt; There appears to be some non-trivial mining power devoted to mining&#xA;&gt; empty blocks.  Even with satoshi&#39;s key observation -- hash a fixed&#xA;&gt; 80-byte header, not the entire block -- some miners still find it&#xA;&gt; easier to mine empty blocks, rather than watch the network for new&#xA;&gt; transactions.&#xA;&gt;&#xA;&gt; Therefore I was wondering what people thought about a client&#xA;&gt; implementation change:&#xA;&gt;&#xA;&gt;      - Do not store or relay empty blocks, if time since last block &lt; &#xA;&gt; X&#xA;&gt;        (where X = 60 minutes, perhaps)&#xA;&gt;&#xA;&gt; or even stronger,&#xA;&gt;&#xA;&gt;      - Ensure latest block includes at least X percent of mempool&#xA;&gt; unconfirmed TXs&#xA;&#xA;If miners wanted to continue mining empty blocks without bothering to &#xA;monitor the Tx pool they would just switch to stuffing the empty blocks &#xA;with a dummy transaction of their own to get round your new rules. They &#xA;could also spam them to the p2p network so that they end up in the &#xA;mempool if that were necessary. This would probably still be slightly &#xA;easier than &#39;doing it properly&#39;.&#xA;&#xA;Once the block reward halves in a few months time then receiving &#xA;transaction fees will probably become more important to the miner&#39;s &#xA;profit and loss calculations and they&#39;ll spend the extra time to &#xA;implement proper transaction processing. I suspect if we do nothing this &#xA;particular issue will go away. Perhaps it could be helped along by &#xA;publishing some example code to make it easier for them.&#xA;&#xA;The ability to refuse transactions seems like an important part of the &#xA;game theory of transaction pricing. Miners are supposed to be able to &#xA;jack up transaction costs by declining to process no fee or too low fee &#xA;(in their opinion) transactions.. the counter balance is that they are &#xA;losing money by doing that and leaving more on the table for the next &#xA;miner to score a block.&#xA;&#xA;I expect that in the future there will be other instances when people &#xA;complain that the miners are being &#39;unfair&#39; and that the rules should be &#xA;changed in some way to lower transaction fees (ie: increase block size).&#xA;&#xA;If block sizes are increased ever larger and miners aren&#39;t allowed to &#xA;refuse to process transactions it will get rid of the financial &#xA;motivation for mining and less mining will happen. We should be very &#xA;careful when making these kinds of changes.&#xA;&#xA;Setting percentage quotas of stuff in the mempool sounds dangerous.. &#xA;miners that hear about a block from a rival miner soon enough could &#xA;possibly DOS the mempool on the rest of the network to get the block &#xA;rejected. I think it should be legitimate not to publish a transaction &#xA;to the p2p network at all.. in the future there will probably be lots of &#xA;networks other than the p2p network.. right now we have the IPv6 network &#xA;and the IPv4 network.. in the future there could be many other protocols &#xA;and perhaps not all transactions will make it back to the old legacy &#xA;ipv4 p2p network or into the mempool of bitcoin nodes on that network.. &#xA;but they should still be able to get into the block chain.&#xA;&#xA;Rob</html></oembed>