public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Luke-Jr" <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Newly introduced DoS
Date: Mon, 26 Sep 2011 16:55:57 -0400	[thread overview]
Message-ID: <201109261655.59768.luke@dashjr.org> (raw)
In-Reply-To: <CABsx9T1gfuiHj9aR=1gDxtEqJzov5iXRqVEiEBUx-VBcearAZQ@mail.gmail.com>

On Monday, September 26, 2011 4:47:06 PM Gavin Andresen wrote:
> On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr <luke@dashjr.org> wrote:
> > +        return DoS(10, error("AcceptToMemoryPool() : transaction with
> > out-of- bounds SigOpCount"));
> > +                        return DoS(10, error("ConnectInputs() : tried to
> > spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight));
> > These shouldn't be "DoS"'d, or else you open a new DoS when nodes
> > legitimately relay such transactions/blocks.
> 
> Huh?
> 
> So in the future lets suppose we schedule a change to the acceptable
> block rules that allows more SigOps in a block, or allows generation
> transaction to be spent before 100 confirmations. At that same time,
> the DoS rules will be changed.
> 
> You cannot "legitimately" relay those blocks without a scheduled
> block-chain-split.  If a block-chain-split IS scheduled and the rules
> change, then denying service to nodes running old, obsolete versions
> of bitcoin is the right thing to do-- it is better to "fail hard" and
> find it difficult or impossible to connect to the network rather than
> continue with an obsolete client and a non-majority block chain.
> 
> (and the third DoS in AcceptBlock(): prev block not found  is a
> "should be impossible" case, because AcceptBlock is only called when
> extending the best-block chain).

The first one I was referring to is a *transaction* with "non-standard" sig op 
count, which is AFAIK allowed in blocks, just not accepted by the mainline 
rules. In the second case, that transaction is not tied to a specific block. 
Maybe the person spending it sees it matured beyond 100 confirmations, and you 
only see 99. An attacker could use these things to get nodes to ban each 
other.



  reply	other threads:[~2011-09-26 20:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-26 19:17 [Bitcoin-development] Newly introduced DoS Luke-Jr
2011-09-26 20:47 ` Gavin Andresen
2011-09-26 20:55   ` Luke-Jr [this message]
2011-09-26 21:38     ` Gavin Andresen
2011-09-26 21:53       ` Luke-Jr
2011-09-26 22:34         ` theymos
2011-09-27  0:07         ` Gavin Andresen
2011-09-27 20:08   ` Luke-Jr
2011-09-27 20:23     ` Gregory Maxwell
2011-09-27 20:39     ` Gavin Andresen

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=201109261655.59768.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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