From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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: <201109142206.40455.luke@dashjr.org> <4E71F5F8.2020807@jerviss.org> <201109151136.47485.luke@dashjr.org> <4E722215.40401@jerviss.org> To: kjj 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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