Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.175 as permitted sender)
	client-ip=209.85.161.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-gg0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <20120706165204.GA27215@vps7135.xlshosting.net>
References: <20120706165204.GA27215@vps7135.xlshosting.net>
Date: Fri, 6 Jul 2012 13:19:59 -0400
Message-ID: <CAAS2fgTME9sNC6O0UnTGvNSN3ruC8P6YNVKZY-TZTVWoQi0yzA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Pruning in the reference client:
	ultraprune mode
Precedence: list

Pieter's performance numbers are a bit conservative if anything=E2=80=94
profiles on ultraprune[1] show that the reference client's wasting of
a lot of time in redundant serialization and hashing operations is
the major time sink. Once thats cleared up it should be quite a
bit faster

[1] https://people.xiph.org/~greg/ultraprune_profile.png

On Fri, Jul 6, 2012 at 12:52 PM, Pieter Wuille <pieter.wuille@gmail.com> wr=
ote:
> Also note that this is not directly related to the recent pruning
> proposals that use an alt chain with an index of unspent coins (and
> addresses), merged mined with the main chain. This could be a step
> towards such a system, however.

In particular,  if the BDB indexing in ultraprune is replaced with
a hash committed tree structure who's root is committed in the
blockchain you then have a txout commitment scheme.
Ultraprune is most of the messy structural work for that. The
rest is mostly storage differences.