An archiver node is a special kind of node:
when it sees a quorum (based on other basic/full validators on the network), it publishes to an archive.
Publishing is done every 64 ledgers if it's in sync with the network. You can read more about this in the history documentation
Im using the aws command line tool
For example to see the contents of the archive
aws s3 --no-sign-request ls s3://history.stellar.org/
Or to look at a specific folder in the testnet archives
aws s3 --no-sign-request ls s3://history.stellar.org/prd/core-testnet/core_testnet_001/transactions/00/60/a1/
Author of history & buckets subsystems here.
There are a few steps to work through in understanding the failure / parsing the logs, though if you want the TL;DR version you can cut to the final paragraph.
First, the failure that's occurring is a gunzip command, which usually means you've downloaded non-gzip data and labeled it something.gz, which ...
The answer is No.
You are correct: history archives are a required component for the network to function properly; without them you can't even join the network.
See this document for the reasons behind this.
Have you considered using the stellar-archivist tool?
The provided link shows an example of how to print a fetched archive file (ledger header, transactions, results, etc) as JSON in your terminal. Hope that helps!
I am not part of Stellar team, but was following Stellar since they forked from Ripple (and also Ripple until that point). My take on this is as follows:
Since the beginning, Stellar have a really cute comic to explain how it's consensus protocol works. The main point was derived from problem of what kind of interstellar blockchain is needed to work not ...
A and B cannot sync up with SCP. This is an invalid configuration. B is misconfigured, so should just dump its state and restart with better quorum slices.
SCP only guarantees agreement when there is quorum intersection. (This is one of the reasons stellar-core makes it hard to assign <= 66% threshold. In your example, B would have had to add the ...
Turns out I rediscovered the infamous Stellar inflation bug: https://github.com/stellar/stellar-core/blob/master/docs/software/security-protocol-release-notes.md#v061c-not-widely-released---2017-04-08
Ledger - security - merge account could be called on an account already merged in the same ledger, causing the Lumens balance of the doubly merged account to ...
In the most recent release of horizon; v0.15.* you can do: horizon db backfill N
where N is the number of missing ledgers you want added to your horizon history.
So in your case it will be horizon db backfill 1830025
Note that even if you have CATCHUP_COMPLETE=true, you might not have all the ledgers in the core database unless you have disabled ...
Typically this is the result of some sort of data corruption on the node's local storage system. Which version of stellar-core are you running? Why did it (re)-enter catchup after 2-3 days? Did the node crash by any chance, or just lose sync?
HISTORY-LABEL in your case is the local history archive name (for example, local). You need to define it in your stellar-core.cfg first (check config example here: https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg#L479). And then initialize using stellar-core new-hist local command.
I'd recommend to start with reading the ...
Answer from official doc:
Checkpoints are made once every 64 ledgers, at ledger sequence numbers that are one-less-than a multiple of 64.
Checkpoints are where a new ledger-headers file is born, at ledger seq # 63, 127, 191, ...
As the chain started from ledger #1, the first checkpoint wraps up only ledger #1 - #63.
stellar-core has few under documented (not mentioned in the documentation but mentioned in the help page of the binary) command line parameters. One of them called --cathup-at which does exactly what we wanted: From a new database (use --newdb first), it "jumps" to a given ledger number without "joining to SCP" and then exits. After this, one can query the ...
For reading, the preferred place to retrieve the SDF history archives is here:
These are mirrored from S3 and cached on Cloudflare. The directories do not allow listing, so to browse, begin ...
The best way to view archive data for Stellar is to run a Stellar Core node with CATCHUP_COMPLETE=true. This will pull in all the archive data. You can get all the options for the configuration file from here and a sample config file from here.
To easily view this data you can run a Horizon server on top of your stellar core instance and use the Horizon ...
You can find some information on current storage size here. As for the growth rate, nobody can predict how much transactions per second we can expect even in the next month. Number of accounts metric demonstrate steady growth.
We don't have any other official history archived besides history.stellar.org, although we do plan to add more at some point in the future.
We're also hoping others will step up and host history mirrors to better decentralize. In my non-company opinion, I'd prefer the network to be in a state such that the "official" history archives are not necessary.
In order to get the historical inflation votes data you need to run a Horizon node with CATCHUP_COMPLETE parameter set to true.
Once a fully synced instance is ready, you will be able to query history_effects table which contains all ledger effects. Inflation destination is set by SET_OPTIONS operation that yields SIGNER_UPDATED effect despite the fact ...