From: Robert McKay <robert@mckay•com>
To: <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Date: Thu, 24 May 2012 18:27:42 +0100 [thread overview]
Message-ID: <81d184ee3a3f5386f6b23090a2a55718@webmail.mckay.com> (raw)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
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
next prev parent reply other threads:[~2012-05-24 18:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 16:33 Jeff Garzik
2012-05-24 17:05 ` Arthur Britto
2012-05-24 17:13 ` Joel Joonatan Kaartinen
2012-05-24 17:23 ` Jeff Garzik
2012-05-24 17:27 ` Robert McKay [this message]
2012-05-24 18:16 ` Jeff Garzik
2012-05-24 20:31 ` Luke-Jr
2012-05-24 21:00 ` Jeff Garzik
2012-05-25 0:45 ` Luke-Jr
2012-05-25 0:51 ` Jeff Garzik
2012-05-25 0:57 ` Luke-Jr
2012-05-25 1:17 ` Jeff Garzik
2012-05-25 7:47 ` Christian Decker
2012-05-25 13:44 ` Alan Reiner
2012-05-25 14:00 ` Peter Vessenes
2012-05-25 1:00 ` Gregory Maxwell
2012-05-26 5:03 ` Zooko Wilcox-O'Hearn
2012-05-26 11:52 ` Stefan Thomas
2012-05-28 14:54 ` Peter Vessenes
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
2012-05-28 16:25 ` [Bitcoin-development] Fw: " Amir Taaki
2012-05-29 8:52 ` [Bitcoin-development] " Michael Grønager
2012-05-29 14:47 ` Luke-Jr
2012-05-29 15:05 ` Peter Vessenes
2012-05-29 15:18 ` Luke-Jr
2012-05-29 15:28 ` Peter Vessenes
2012-05-29 15:34 ` Luke-Jr
2012-05-29 15:36 ` Peter Vessenes
2012-05-29 15:39 ` Luke-Jr
2012-05-29 15:45 ` Peter Vessenes
2012-05-29 16:30 ` Rebroad (sourceforge)
2012-05-29 15:33 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81d184ee3a3f5386f6b23090a2a55718@webmail.mckay.com \
--to=robert@mckay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox