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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
Precedence: list

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