[Bitcoin-development] Bootstrapping full nodes post-pruning

Gregory Maxwell gmaxwell at gmail.com
Mon Jun 11 15:39:20 UTC 2012


On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn <mike at 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




More information about the bitcoin-dev mailing list