<oembed><type>rich</type><version>1.0</version><author_name>npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</author_name><author_url>https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58</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, May 24, 2012 at 1:27 PM, Robert McKay &lt;robert at mckay.com&gt; wrote:&#xA;&gt; If miners wanted to continue mining empty blocks without bothering to&#xA;&gt; monitor the Tx pool they would just switch to stuffing the empty blocks&#xA;&gt; with a dummy transaction of their own to get round your new rules.&#xA;&#xA;Yes.  This was stated in the original email.&#xA;&#xA;&#xA;&gt; Once the block reward halves in a few months time then receiving&#xA;&gt; transaction fees will probably become more important to the miner&#39;s&#xA;&gt; profit and loss calculations and they&#39;ll spend the extra time to&#xA;&gt; implement proper transaction processing. I suspect if we do nothing this&#xA;&gt; particular issue will go away. Perhaps it could be helped along by&#xA;&gt; publishing some example code to make it easier for them.&#xA;&#xA;At current rates it is potentially years before that point is reached&#xA;-- years of degraded service for existing users.&#xA;&#xA;&#xA;&gt; The ability to refuse transactions seems like an important part of the&#xA;&gt; game theory of transaction pricing. Miners are supposed to be able to&#xA;&gt; jack up transaction costs by declining to process no fee or too low fee&#xA;&gt; (in their opinion) transactions.. the counter balance is that they are&#xA;&gt; losing money by doing that and leaving more on the table for the next&#xA;&gt; miner to score a block.&#xA;&gt;&#xA;&gt; I expect that in the future there will be other instances when people&#xA;&gt; complain that the miners are being &#39;unfair&#39; and that the rules should be&#xA;&gt; changed in some way to lower transaction fees (ie: increase block size).&#xA;&#xA;If you see a rule change, you have misunderstood the proposal.&#xA;&#xA;This is an -implementation- change, which users and miners are free to&#xA;accept or reject as part of their choice of software to use in the&#xA;bitcoin ecosystem.&#xA;&#xA;As such, miners continue to be free to build upon empty blocks, and&#xA;let those blocks become part of a useful chain.  You would not simply&#xA;/ban/ empty blocks completely, but avoid relaying top-of-chain empty&#xA;blocks.&#xA;&#xA;Mining power and network collaborate to choose the best chain at that&#xA;point -- perhaps even including those empty blocks.  Clients will&#xA;continue to follow the longest, strongest chain, even after this&#xA;implementation change.&#xA;&#xA;An implementation change is a soft vote of choice by the user, not a&#xA;hard requirement on all users.&#xA;&#xA;&gt; I think it should be legitimate not to publish a transaction&#xA;&gt; to the p2p network at all.. in the future there will probably be lots of&#xA;&gt; networks other than the p2p network.. right now we have the IPv6 network&#xA;&gt; and the IPv4 network.. in the future there could be many other protocols&#xA;&gt; and perhaps not all transactions will make it back to the old legacy&#xA;&gt; ipv4 p2p network or into the mempool of bitcoin nodes on that network..&#xA;&gt; but they should still be able to get into the block chain.&#xA;&#xA;See above -- such behavior is perfectly fine.&#xA;&#xA;It should be noted that out of band (OOB) TXs, transited through third&#xA;party means outside P2P network, would not cause _empty_ blocks, as&#xA;the block chain will continue to have traffic for the foreseeable&#xA;future.&#xA;&#xA;OOB TXs are a great idea, too.  In a hyperscaled bitcoin future, OOB&#xA;TXs might even be the norm.&#xA;&#xA;-- &#xA;Jeff Garzik&#xA;exMULTI, Inc.&#xA;jgarzik at exmulti.com</html></oembed>