From: Gregory Maxwell <gmaxwell@gmail•com>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed additional options for pruned nodes
Date: Tue, 12 May 2015 20:47:41 +0000 [thread overview]
Message-ID: <CAAS2fgQZ9xNJ-Bz=k9ztHwqeOjjFbPsGAzReHmnUPYe0RYu+FA@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0O3fgmg4AFAM9+4RRkhSo8ekATs2Ks+Ry7ooQafjQ-4qw@mail.gmail.com>
On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> True. Part of the issue rests on the block sync horizon/cliff. There is a
> value X which is the average number of blocks the 90th percentile of nodes
> need in order to sync. It is sufficient for the [semi-]pruned nodes to keep
> X blocks, after which nodes must fall back to archive nodes for older data.
Prior discussion had things like "the definition of pruned means you
have and will serve at least the last 288 from your tip" (which is
what I put in the pruned service bip text); and another flag for "I
have at least the last 2016". (2016 should be reevaluated-- it was
just a round number near where sipa's old data showed the fetch
probability flatlined.
But that data was old, but what it showed that the probability of a
block being fetched vs depth looked like a exponential drop-off (I
think with a 50% at 3-ish days); plus a constant low probability.
Which is probably what we should have expected.
> There was even a more radical suggestion years ago - refuse to sync if too
> old (>2 weeks?), and force the user to download ancient data via torrent.
I'm not fond of this; it makes the system dependent on centralized
services (e.g. trackers and sources of torrents). A torrent also
cannot very efficiently handle fractional copies; cannot efficiently
grow over time. Bitcoin should be complete-- plus, many nodes already
have the data.
next prev parent reply other threads:[~2015-05-12 20:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANJO25J1WRHtfQLVXUB2s_sjj39pTPWmixAcXNJ3t-5os8RPmQ@mail.gmail.com>
2015-05-12 15:26 ` gabe appleton
2015-05-12 16:05 ` Jeff Garzik
2015-05-12 16:56 ` gabe appleton
2015-05-12 17:16 ` Peter Todd
2015-05-12 18:23 ` Tier Nolan
2015-05-12 19:03 ` Gregory Maxwell
2015-05-12 19:24 ` gabe appleton
2015-05-12 19:38 ` Jeff Garzik
2015-05-12 19:43 ` gabe appleton
2015-05-12 21:30 ` [Bitcoin-development] [Bulk] " gb
2015-05-12 20:02 ` [Bitcoin-development] " Gregory Maxwell
2015-05-12 20:10 ` Jeff Garzik
2015-05-12 20:41 ` gabe appleton
2015-05-12 20:47 ` Gregory Maxwell [this message]
[not found] ` <CAFVoEQTdmCSRAy3u26q5oHdfvFEytZDBfQb_fs_qttK15fiRmg@mail.gmail.com>
[not found] ` <CAJHLa0OxxxiVd3JOp8SDvbF8dHj6KHdUNGb9L_GvTe93z3Z8mg@mail.gmail.com>
[not found] ` <CAJHLa0MYSpVBD4VE65LVbADb2daOvE=N83G8F_zDSHy3AQ5DAQ@mail.gmail.com>
2015-05-12 21:17 ` [Bitcoin-development] Fwd: " Adam Weiss
2015-05-12 22:00 ` [Bitcoin-development] " Tier Nolan
2015-05-12 22:09 ` gabe appleton
2015-05-13 5:19 ` Daniel Kraft
2015-05-13 9:34 ` Tier Nolan
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='CAAS2fgQZ9xNJ-Bz=k9ztHwqeOjjFbPsGAzReHmnUPYe0RYu+FA@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/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