Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-fx0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <201109271608.07053.luke@dashjr.org>
References: <201109261517.11245.luke@dashjr.org>
	<CABsx9T1gfuiHj9aR=1gDxtEqJzov5iXRqVEiEBUx-VBcearAZQ@mail.gmail.com>
	<201109271608.07053.luke@dashjr.org>
Date: Tue, 27 Sep 2011 16:39:32 -0400
Message-ID: <CABsx9T3Znz83XpCBZO_J8jNecKkmUseVsBgHDDmbiVuZ1HFaoQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Newly introduced DoS
Precedence: list

> @@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock()
> =A0 =A0 // Get prev block index
> =A0 =A0 map<uint256, CBlockIndex*>::iterator mi =3D
> mapBlockIndex.find(hashPrevBlock);
> =A0 =A0 if (mi =3D=3D mapBlockIndex.end())
> - =A0 =A0 =A0 =A0return error("AcceptBlock() : prev block not found");
> + =A0 =A0 =A0 =A0return DoS(10, error("AcceptBlock() : prev block not fou=
nd"));
>
>
> Is it certain that it cannot be triggered by a peer having some huge numb=
er
> more blocks than you?

As I said, that is a "can't never happen but we'll wear a
belt-and-suspenders just in case" case.

AcceptBlock() is called from two places in the code:

ProcessBlock, if the block is not an orphan:
    // If don't already have its previous block, shunt it off to
holding area until we get it
    if (!mapBlockIndex.count(pblock->hashPrevBlock))
    {
....  orphan processing stuff...
      return true;
    }

    // Store to disk
    if (!pblock->AcceptBlock())
        return error("ProcessBlock() : AcceptBlock FAILED");

The mapBlockIndex.find(hashPrevBlock) in AcceptBlock can't fail.

The second place is recursively, in AcceptBlock(), processing orphans
that link to the block being accepted, and mapBlockIndex.find() would
find the used-to-be-an-orphan-block-that-is-now-being-accepted.

So: it is a case that should be impossible to trigger. However, in
case there is some subtle bug or edge case I'm not considering it seem
to me keeping the check is appropriate, and, because it will be a
subtle bug or edge case, it seems to me keeping the DoS penalty is
also appropriate, because attackers look for subtle bugs and edge
cases that can be exploited.


--=20
--
Gavin Andresen