> Actual BDB files are absolutely not deterministic. Nor is the raw
> blockchain itself currently, because blocks aren't always added in the
> same order (plus they get orphans in them)
That's true. Though if you prune up to the last checkpoint, orphans
before that point can be safely thrown away.
On Mon, Jun 11, 2012 at 4:36 PM, Mike Hearn wrote:
> Unless BDB has some weird behaviour in it, that shouldn't require any
HAHAHA. Have you consider doing comedy full time?
Actual BDB files are absolutely not deterministic. Nor is the raw
blockchain itself currently, because blocks aren't alwa
> If we wanted to go the route of shipping pruned chains I'd prefer to
> have a deterministic process to produce archival chains
Yeah, that sounds reasonable. I mean, I can't see why pruning would
not be deterministic. So if you download a binary that contains a
pre-indexed and pruned chain up to
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn 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 singl
Apologies if this has been discussed elsewhere. I don't recall us ever
reaching a solid conclusion on it.
A node that has pruned its block chain cannot serve the chain to new
nodes. So there are three options for bootstrapping a newly installed
node:
1) Have some kind of special archival nodes th
5 matches
Mail list logo
