Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.47 as permitted sender)
	client-ip=209.85.214.47; envelope-from=joel.kaartinen@gmail.com;
	helo=mail-bw0-f47.google.com; 
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com>
References: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 18 Aug 2011 18:36:23 +0300
Message-ID: <1313681783.14523.79.camel@mei>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack
Precedence: list

On Thu, 2011-08-18 at 10:00 -0400, Gavin Andresen wrote:
> The lessons are "don't accept 1-confirmation transactions" and  "try
> to be well-connected."
> 
> But maybe the deeper lesson is "don't trust information you get from
> only one peer." Or maybe "watch for peers that are trying to fool
> you."

This particular attack seems quite dependant on the target not using the
deposit Tx as input. I believe this whole class of attacks become
ineffective if each account has it's own separate wallet.

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? Perhaps in such a case, don't treat the block it
came in as a confirmation at all. Instead, start counting from the next
one.

- Joel