Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.47 as permitted sender)
	client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com;
	helo=mail-qa0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
References: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
Date: Mon, 11 Jun 2012 11:39:20 -0400
Message-ID: <CAAS2fgSB6--PzpnTrx_DXrwZ7uzXrTCH3a1aMVFmWPBNO6FuqA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bootstrapping full nodes post-pruning
Precedence: list

On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn <mike@plan99.net> wrote:
> I remember some people, Greg in particular, who were not a fan of
> approach (2) at all, though it has the benefit of speeding startup for
> new users as there's no indexing overhead.

I'm not a fan of anything which introduces unauditable single source
material.  "Trust us" is a bad place to be because it would greatly
increase the attractiveness of compromising developers.

If we wanted to go the route of shipping pruned chains I'd prefer to
have a deterministic process to produce archival chains and then start
introducing commitments to them in the blockchain or something like
that.   Then a client doing a reverse header sync[1] would bump into a
commitment for an archival chain that they have and would simply stop
syncing and use the archival chain for points before that.

This would leave it so that the distribution of the software could
still be audited.

More generally we should start doing something with the service
announcements so that full nodes that don't have enough bandwidth to
support a lot of syncing from new nodes can do so without turning off
listening.


[1] https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync