Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SXf9R-0003zB-MR for bitcoin-development@lists.sourceforge.net; Thu, 24 May 2012 21:00:53 +0000 X-ACL-Warn: Received: from mail-lpp01m010-f47.google.com ([209.85.215.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SXf9M-0000Y4-TA for bitcoin-development@lists.sourceforge.net; Thu, 24 May 2012 21:00:53 +0000 Received: by lags15 with SMTP id s15so260549lag.34 for ; Thu, 24 May 2012 14:00:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mTAV5261ul33JCgXIKv9TPY2WqFPip3+MvpbeW9YC5o=; b=MMCgU3IIH5hL5vwmYZ8ftCn1607tOibAXLD6zL8KXKe9rgbsmufBbXDfRY1wNwmHJx zw2UAAP5ePaKfI0m0fdg6Td/wqObq7BJnTkuhRdUpbKbDQD3iQgfxSmycsFUQ2LtBQOS fENiqmTZxeS4EvLvMqgfoXq43FqaZg5XURRxpPF4u82JHark7TMaI/wrOFEr9et+apYx CyP66s3CiETCjO5V8Ha4mQoVIH0VNDk36TPP2J8/YwfjDuvmDLc8gUk2C47t9M4hjoMm bBclgtKp/AKKa85z7xDgR9CFZo9gUrKp5rSs7U8EDo5gAfQpGYVK1bN8n26gdnJlkegQ AWEA== MIME-Version: 1.0 Received: by 10.152.46.6 with SMTP id r6mr978214lam.7.1337893242092; Thu, 24 May 2012 14:00:42 -0700 (PDT) Received: by 10.114.0.103 with HTTP; Thu, 24 May 2012 14:00:42 -0700 (PDT) X-Originating-IP: [99.43.178.25] In-Reply-To: <201205242031.39804.luke@dashjr.org> References: <201205242031.39804.luke@dashjr.org> Date: Thu, 24 May 2012 17:00:42 -0400 Message-ID: From: Jeff Garzik To: Luke-Jr Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmkCfx7wv7ktQBe9rF8lt1aTrxuF8ZQd45n9X0RMSGZRza8y7jCKKckNFPHZBebtcdQtbaZ X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1SXf9M-0000Y4-TA Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Punishing empty blocks? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:00:53 -0000 On Thu, May 24, 2012 at 4:31 PM, Luke-Jr 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