Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.175 as permitted sender)
	client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-qy0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <E0AD809E-7446-4E18-9A2D-7E7480F8AB89@ceptacle.com>
References: <E0AD809E-7446-4E18-9A2D-7E7480F8AB89@ceptacle.com>
Date: Wed, 5 Oct 2011 08:50:52 -0400
Message-ID: <CAAS2fgRiM9SFGVtYU1GJM8U0z8aMecc3Ng9wM4SNWkE5_MKPwQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] vtxPrev
Precedence: list

On Wed, Oct 5, 2011 at 8:31 AM, Michael Gr=C3=B8nager <gronager@ceptacle.co=
m> wrote:
> The vtxPrev stores 3 transactions back, but as transactions need 7 block =
to maturity and respendability isn't it overkill - I mean it is highly unli=
kely that a transaction gets invalid after 7 confirmations and

They don't need 7 blocks to maturity and respendability. The software
will attempt to use older inputs when available but if not it will use
what it has.  It's also prone to respending its own outputs quickly
because it reasonably trusts that it won't doublespend its own
transactions.

And, yes, if there is a deep split then its possible that inputs might
have been spent differently in the new split. But it's not especially
likely. Retransmitting one of your own txn's parents if its dropped
but not yet impossible sounds prudent to me.