public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: kjj <kjj@jerviss•org>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
Date: Thu, 15 Sep 2011 11:04:37 -0500	[thread overview]
Message-ID: <4E722215.40401@jerviss.org> (raw)
In-Reply-To: <201109151136.47485.luke@dashjr.org>

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.



  reply	other threads:[~2011-09-15 16:04 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 [this message]
2011-09-15 16:41         ` solar
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=4E722215.40401@jerviss.org \
    --to=kjj@jerviss$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=luke@dashjr$(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