On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn <m...@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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
