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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
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 <solar@heliacal.net>) id 1R4FF2-000304-RL
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:56:48 +0000
X-ACL-Warn:
Received: from pelican.heliacal.net ([173.246.103.92] helo=pelican)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1R4FF1-0005XT-JZ for bitcoin-development@lists.sourceforge.net;
Thu, 15 Sep 2011 16:56:48 +0000
Received: from [IPv6:2001:470:d9e0:deaf:a18d:785:7f92:3986] (unknown
[IPv6:2001:470:d9e0:deaf:a18d:785:7f92:3986])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by pelican (Postfix) with ESMTPSA id 23DE0190FA;
Thu, 15 Sep 2011 16:41:07 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: solar <solar@heliacal.net>
In-Reply-To: <4E722215.40401@jerviss.org>
Date: Thu, 15 Sep 2011 16:41:05 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <10E29726-4210-49BC-8C56-5798BC4E7869@heliacal.net>
References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com>
<201109142206.40455.luke@dashjr.org> <4E71F5F8.2020807@jerviss.org>
<201109151136.47485.luke@dashjr.org> <4E722215.40401@jerviss.org>
To: kjj <kjj@jerviss.org>
X-Mailer: Apple Mail (2.1244.3)
X-Helo-Check: bad, Not FQDN (pelican)
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 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
0.5 VA_HELO_CHECK Host Used Invalid or Forged HELO/EHLO
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
X-Headers-End: 1R4FF1-0005XT-JZ
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:56:48 -0000
I don't think that any kind of peer disconnection should be present in =
the reference client implementation. This is a lot like using packet =
filters and stateful firewalls - they are implemented based on local =
policy and they require constant tweaking because they always cause =
problems when some change in usage dictates allowing things that weren't =
allowed before. Essentially every new service, protocol (or creative =
use of an existing protocol) needs to be 'opened up' so it's a hassle to =
change it each time.
Perhaps there is a use for this in helping implement local policy but =
even something that's considered a 'liberal' filtering rule today will =
eventually be in the way of something legitimate and will need to be =
adjusted. It is not possible to just adjust this network wide when and =
adjustment needs to be created, so any type of built-in filtering is =
limiting to future innovation.
Maybe this type of thing would be better implemented in a separate =
bitcoin proxy - much like how a firewall can be placed between a router =
and network. All traffic is legitimate to a router (bitcoind) if it's =
formatted correctly and can be forwarded, but the firewall can implement =
local policy. The problem with providing this out-of-the-box is that =
even in the case of internet traffic, they are often misused and =
configured too restrictively so they end up causing service problems for =
the users behind them.
I think the idea is good, in that we need a way to filter out things we =
consider bad, but I don't think it is the job of the bitcoin client. =
There are tons of tunable things and people will want to tweak them - =
what is 'a lot' to me might be nothing to someone else. People's =
policies will differ greatly as you can see with everything else on the =
internet.
Laszlo Hanyecz
solar@heliacal.net
On Sep 15, 2011, at 4:04 PM, kjj wrote:
> 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=20=
> only has meaning to this particular implementation of the software, =
but=20
> no meaning in the context of the protocol or the system as a whole.
>=20
> On the other hand, the vast, vast majority of all transactions follow =
a=20
> particular pattern. If someone gives you one that doesn't match the=20=
> standard pattern, you might be a little suspicious, but it is no big=20=
> deal. But, if they emit dozens or hundreds, it is hardly unreasonable=20=
> to disconnect them until you figure out what's going on.
>=20
> =
--------------------------------------------------------------------------=
----
> Doing More with Less: The Next Generation Virtual Desktop=20
> What are the key obstacles that have prevented many mid-market =
businesses
> from deploying virtual desktops? How do next-generation virtual =
desktops
> provide companies an easier-to-deploy, easier-to-manage and more =
affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
