From: "Luke-Jr" <luke@dashjr•org>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Date: Thu, 24 May 2012 20:31:38 +0000 [thread overview]
Message-ID: <201205242031.39804.luke@dashjr.org> (raw)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
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
next prev parent reply other threads:[~2012-05-24 20:31 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
2012-05-24 18:16 ` Jeff Garzik
2012-05-24 20:31 ` Luke-Jr [this message]
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=201205242031.39804.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--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