Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.175 as permitted sender)
	client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-vx0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <jdtaol$3ku$1@dough.gmane.org>
References: <jdrds3$3tf$1@dough.gmane.org>
	<CALxbBHU7f1m+p45RHLhN-VGBoXJEi62x5mZUiAe_d5D-5Ga7yA@mail.gmail.com>
	<jdtaol$3ku$1@dough.gmane.org>
Date: Mon, 2 Jan 2012 17:41:10 -0500
Message-ID: <CAAS2fgTOZKM9c=UvfVW1rajnPQVQMNS4mR5KUqq8p0HreG=vuQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Elden Tyrell <tyrell.elden@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] does "stubbing" off Merkle trees reduce
 initial download bandwidth?
Precedence: list

On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell <tyrell.elden@gmail.com> wrote=
:
> On 2012-01-02 05:31:19 -0800, Christian Decker said:
>> Later full blocks would be required to detect usable inputs for future
>> outgoing transactions.
>
> Er, yes, this is what I meant; I guess I should have been more specific.
>
> So, a paranoid client cannot confirm reciept of coins until it has an
> unstubbed copy of the entire chain. =C2=A0It can do other things (like se=
nd
> coins) using a stubbed chain, but it needs the whole unstubbed chain in
> order to be sure that incoming coins haven't already been spent.
>
> Thanks for confirming this.


Er, no=E2=80=94  if a node controls the private keys for a transaction, and
that transaction makes it into the chain then it can safely assume
that its unspent (at least once its buried a few blocks into the
chain).  This is the essence of a SPV node.

What it can't do is perform this function for txn which aren't its
own. Though the system could be extended in a compatible manner to
make this possible: https://bitcointalk.org/index.php?topic=3D21995.0