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
