Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.175 as permitted sender)
	client-ip=209.85.220.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-vx0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <1313681783.14523.79.camel@mei>
References: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com>
	<1313681783.14523.79.camel@mei>
Date: Thu, 18 Aug 2011 17:52:03 +0200
Message-ID: <CANEZrP0rXWO51O6wJfQ3r3A6bviZ7zpthJjzZkA0JDC7auBEdw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack
Precedence: list

> Also, receiving a block with a transaction that hasn't been broadcast to
> the network is in itself quite suspect. Are there cases where that
> happens legitimately?

There's no way to obtain the memory pools of your peers today, so if
you're newly started up it can happen that you get blocks with unseen
transactions.

For vectors variant, I wonder if it'd be safe to report the number of
confirmations differently for the duration of a chain split. If you
have a block but a majority of peers relayed a block that split the
chain, subtract 1 from each confirmation reported via RPC.