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