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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <SRS0=2GaZs2hg=4A=jerviss.org=kjj@jerviss.org>)
id 1R4EQf-0008Am-9y for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:04:45 +0000
X-ACL-Warn:
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1R4EQe-0003le-CQ
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:04:45 +0000
Received: from [156.99.25.142] ([156.99.25.142])
(username: kjj authenticated by PLAIN symmetric_key_bits=0)
by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id p8FG4bcF001976
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 15 Sep 2011 11:04:38 -0500
Message-ID: <4E722215.40401@jerviss.org>
Date: Thu, 15 Sep 2011 11:04:37 -0500
From: kjj <kjj@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3
MIME-Version: 1.0
To: Luke-Jr <luke@dashjr.org>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
<201109142206.40455.luke@dashjr.org> <4E71F5F8.2020807@jerviss.org>
<201109151136.47485.luke@dashjr.org>
In-Reply-To: <201109151136.47485.luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (inana.jerviss.org: 156.99.25.142 is authenticated by a
trusted mechanism)
X-Spam-Score: -1.8 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R4EQe-0003le-CQ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
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, 15 Sep 2011 16:04:45 -0000
Luke-Jr wrote:
> On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
>> Luke-Jr wrote:
>>> On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
>>>> I'm looking for review of this pull request:
>>>> https://github.com/bitcoin/bitcoin/pull/517
>>> "Non-standard" transactions, or those with "insufficient" fees should not
>>> be penalised. These are properly relay/miner policy decisions, not
>>> protocol violations, and should be made more easily configurable, not
>>> punished for configuration.
>> A few non-standard transactions are probably legitimate. A whole bunch
>> of them are probably not. I would think that assigning a point or two
>> of badness to a peer sending one is pretty reasonable, with the
>> understanding that we would need to adjust that as the network evolves.
> No. There is no such thing as "non-standard transactions" really; it is simply
> "transactions outside of the bounds that I as a user/miner will relay/accept".
> It is perfectly legitimate for other users/miners to relay/accept transactions
> more liberally. By penalising for transactions falling outside of your
> *personal policies*, you would end up banning many legitimate nodes.
It is certainly true that standardness is an artificial construct that
only has meaning to this particular implementation of the software, but
no meaning in the context of the protocol or the system as a whole.
On the other hand, the vast, vast majority of all transactions follow a
particular pattern. If someone gives you one that doesn't match the
standard pattern, you might be a little suspicious, but it is no big
deal. But, if they emit dozens or hundreds, it is hardly unreasonable
to disconnect them until you figure out what's going on.
|
