📅 Original date posted:2015-05-12
📝 Original message:On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik <jgarzik at 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.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:35:02
in reply to nevent1q…ddl7
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:35:02Event JSON
{
"id": "dffcf53a90916f1cab32d86348fafa789f5595978ddb24fcdbac53b9fdd1ca3c",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686152102,
"kind": 1,
"tags": [
[
"e",
"7e36bd930e27f2bf6b132a282e9a03a5435c1a5498b7eb37778136da650227dc",
"",
"root"
],
[
"e",
"a1973ca1a89337c007ef22263bda572eb3829109bd477d26d87231e209907f37",
"",
"reply"
],
[
"p",
"4217f51173ea5a917808bbd7462fdc254558934c41df8d66a8b05d0556087bcd"
]
],
"content": "📅 Original date posted:2015-05-12\n📝 Original message:On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e True. Part of the issue rests on the block sync horizon/cliff. There is a\n\u003e value X which is the average number of blocks the 90th percentile of nodes\n\u003e need in order to sync. It is sufficient for the [semi-]pruned nodes to keep\n\u003e X blocks, after which nodes must fall back to archive nodes for older data.\n\n\nPrior discussion had things like \"the definition of pruned means you\nhave and will serve at least the last 288 from your tip\" (which is\nwhat I put in the pruned service bip text); and another flag for \"I\nhave at least the last 2016\". (2016 should be reevaluated-- it was\njust a round number near where sipa's old data showed the fetch\nprobability flatlined.\n\nBut that data was old, but what it showed that the probability of a\nblock being fetched vs depth looked like a exponential drop-off (I\nthink with a 50% at 3-ish days); plus a constant low probability.\nWhich is probably what we should have expected.\n\n\u003e There was even a more radical suggestion years ago - refuse to sync if too\n\u003e old (\u003e2 weeks?), and force the user to download ancient data via torrent.\n\nI'm not fond of this; it makes the system dependent on centralized\nservices (e.g. trackers and sources of torrents). A torrent also\ncannot very efficiently handle fractional copies; cannot efficiently\ngrow over time. Bitcoin should be complete-- plus, many nodes already\nhave the data.",
"sig": "c69f656cafe3b1fb29253393b0abae34006d2e2aea781eaf24fcf691690cf6e895a17d16f014688060f605d6b0a480fafce52cedb2fae5505dc479f4689d91c4"
}