From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bootstrapping full nodes post-pruning
Date: Mon, 11 Jun 2012 11:39:20 -0400 [thread overview]
Message-ID: <CAAS2fgSB6--PzpnTrx_DXrwZ7uzXrTCH3a1aMVFmWPBNO6FuqA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3kOysjENpkHom5MHg0usq1jkQdEFAM3vuR1KgFAnJHhg@mail.gmail.com>
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
next prev parent reply other threads:[~2012-06-11 15:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-10 23:06 Mike Hearn
2012-06-11 15:39 ` Gregory Maxwell [this message]
2012-06-11 20:36 ` Mike Hearn
2012-06-11 20:43 ` Gregory Maxwell
2012-06-11 20:48 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgSB6--PzpnTrx_DXrwZ7uzXrTCH3a1aMVFmWPBNO6FuqA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox