From: Jeff Garzik <jgarzik@exmulti•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Date: Thu, 24 May 2012 17:00:42 -0400 [thread overview]
Message-ID: <CA+8xBpcO2h-rZnDA4i+9dBxUmx3Q+sjTti_M7uuM2t-O9yu1nA@mail.gmail.com> (raw)
In-Reply-To: <201205242031.39804.luke@dashjr.org>
On Thu, May 24, 2012 at 4:31 PM, Luke-Jr <luke@dashjr•org> wrote:
> 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.
This is simply not true given current available data, i.e. the current
blockchain and ongoing not-spam transaction rate/pool.
> 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.
According to your own numbers even, this is not true. 99% of the
network runs a wide variety of rules and versions. Even with a
"critical" security announcement, the percentage of those running the
latest version is not large.
> 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.
Miners are not the -only- ones that get a say in what is spam, and
what is not. If miners are generating garbage, network users have the
right to veto that garbage.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
next prev parent reply other threads:[~2012-05-24 21:00 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
2012-05-24 21:00 ` Jeff Garzik [this message]
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=CA+8xBpcO2h-rZnDA4i+9dBxUmx3Q+sjTti_M7uuM2t-O9yu1nA@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/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