From: solar <solar@heliacal•net>
To: kjj <kjj@jerviss•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
Date: Thu, 15 Sep 2011 16:41:05 +0000 [thread overview]
Message-ID: <10E29726-4210-49BC-8C56-5798BC4E7869@heliacal.net> (raw)
In-Reply-To: <4E722215.40401@jerviss.org>
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
> 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
next prev parent reply other threads:[~2011-09-15 16:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 1:57 Gavin Andresen
2011-09-15 2:06 ` Luke-Jr
2011-09-15 10:43 ` Christian Decker
2011-09-15 12:56 ` kjj
2011-09-15 15:36 ` Luke-Jr
2011-09-15 16:04 ` kjj
2011-09-15 16:41 ` solar [this message]
2011-09-15 17:29 ` Luke-Jr
2011-09-15 16:19 ` Gavin Andresen
2011-09-15 17:41 ` Douglas Huff
[not found] ` <CABsx9T3HCVAn5ECuPWfAyZ4zt3WCbyKPF-7DV1HY2j2TKjavrg@mail.gmail.com>
2011-09-15 18:36 ` Douglas Huff
2011-09-15 19:07 ` Gavin Andresen
2011-09-15 11:45 ` Mike Hearn
2011-09-15 12:25 ` Gavin Andresen
2011-09-15 13:00 ` Stefan Thomas
2011-09-15 14:06 ` Gavin Andresen
2011-09-15 14:21 ` Gregory Maxwell
2011-09-15 16:21 ` Mike Hearn
2011-09-16 12:57 ` Joel Joonatan Kaartinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10E29726-4210-49BC-8C56-5798BC4E7869@heliacal.net \
--to=solar@heliacal$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=kjj@jerviss$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox