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 so...@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 > 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. > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > 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 ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop 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
