1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
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 <jgarzik@exmulti.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
<201205242031.39804.luke@dashjr.org>
Date: Thu, 24 May 2012 17:00:42 -0400
Message-ID: <CA+8xBpcO2h-rZnDA4i+9dBxUmx3Q+sjTti_M7uuM2t-O9yu1nA@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Luke-Jr <luke@dashjr.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 21:00:53 -0000
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
|
