Won't be able to tell exact number, but this is not an issue.
Stellar has different levels of participation. Only archiver and full validator nodes publish archive and maintain full history.
Also this archive doesn't need to be stored on the server, it can be published to S3 bucket or any other cloud storage.
Nodes keep current state of the network and ...
It's explained well in ledger support center here
Launch the Ledger Manager (click to see how to install and use it if you don't have it installed yet)
Connect your Nano S, enter your PIN, and stay on the dashboard
On the ledger manager, scroll down and click on the green bottom arrow icon near the Stellar logo
Confirm the installation if ...
Unlike many blockchains, such as Bitcoin with its UTXO model, in Stellar every ledger includes a logical snapshot of the complete system state. This makes it possible to trim history while still having a working node.
That said, the consensus value actually contains a hash of the previous consensus value, as well as a skiplist to make it faster to search ...
It's neither the blockchain nor the block. The global ledger is close to the blockchain while the last closed ledger is the latest confirmed set of accounts, trustlines, data and offers, which is pretty much the last confirmed block of a blockchain.
Like a traditional ledger, the Stellar ledger records a list of all
the balances and transactions ...
Skip list are designed to speed up ledger chain validation as they allow to jump in the chain by up to 500000 ledgers (that's about a month worth of ledgers).
Use case is that even from thin client you can verify that a ledger that you are observing is indeed connected to genesis (going back from that ledger) and/or connected to the latest ledger from ...
The SQL database can be thought of as a simplified view of the ledger state stored in the bucket list. As such the only data that stellar core relies on is account based not transaction based.
Now there are a couple tables (txhistory and txfee) that contain transactions and their related metadata for the purpose of being exported to Horizon.
As you can ...
Yes, all nodes maintain the exact same ledger as a replicated state machine on top of the Stellar Consensus Protocol (SCP). It is a serious configuration error to have two disjoint quorums--such a configuration will cause serious problems for the network if the two quorums agree on different sets of transactions for a ledger. At that point people will have ...
Version 9.2 does not support version 10 of the protocol.
You can import a subset of the historical data (with command line catch-up), install the latest release candidate (10.0.0rc2 labeled "testing" in the quickstart image) or wait for a stable build (should be out in the next couple weeks).
Taking a look at this with the assumption that the attacker controls some validators (as it makes it easier to exploit).
So the way the network deals with transaction ordering is by making it as hard as it can to make it look random:
the apply order sorts by account id xored with the hash of the transaction set
the nomination protocol that gathers ...
There are two components involved in running a stellar backend. The one is stellar-core which manages peer to peer data propagation, the other one is stellar-horizon which gets and prepares that data from core for convenient access.
core_latest_ledger is the latest existing ledger that stellar-core is aware of (it's p2p, it might as well lag behind the ...
EDIT: They released the docs in v10.1.0 in metrics.md.
Unfortunately, there's not much about metrics anywhere in the official docs or repositories besides the GET metrics/ endpoint in the Horizon API.
I found an open issue in the repository regarding undocumented metrics values, with a proposed documentation in an open PR but it has not been merged yet. ...
I asked the same question earlier.
Jed mentioned that trades are applied in random (actually, pseudo-random) order, and transaction fees do not affect the order in which transactions are applied within the ledger. So larger fees do not prioritize trading operations, preventing Low Latency HFT manipulations.
(Detailed explanation of the tx ...
Since the computation of current hash does not depend on previous hash(...)
But if you read the documentation of Stellar, it says that the ledger depends on previous ledger:
This header has references to the actual data within the ledger as well as a reference to the previous ledger
All the transactions are encoded into XDR format (External Data Representation). Horizon decodes it and displays all the transactions in a readable format (JSON). In order to inspect the Stellar blockchain in a better visual experience, you must interact with Horizon, or use any Stellar block explorer that interacts with a Horizon server on the public ...
I have the same.
Update: Found the answer on a redit page: https://www.reddit.com/r/Stellar/comments/f47o07/ledger_nano_and_account_viewer_doesnt_show_balance/
The latest ledger update is to blame, they are working on it. Check your balance on the Stellar blockchain explorer : https://stellar.expert/explorer/public/
using your public key in the search at ...
The best-known way is to pull the latest source code from the repository and build it and the peer nodes then need to vote for the upgrade. The good news is that the upgrade doesn't affect your databases.
Experience now allows me to update this answer for googlers of the future. When running Stellar Core in Docker you must persist the following:
Set BUCKET_DIR_PATH in your stellar-core.cfg and persist this location outside of the container
If you put to a local history archive also ensure this location is persisted outside of the container
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 ...
To get a new address with the Ledger without doing custom work, you'll need to reset the ledger itself (which is probably not something you want to do).
When you reinstall apps, it will always generate that from some master private key that is used to regenerate same addresses for the different apps. Resetting the ledger will reset this master private key.
1) Do all nodes in stellar-network know about my transaction and decide whether to include it in the ledger or not? Or does the decision accept only the quorum to which I belong?
Yes, all nodes decide, or rather whatever nodes you submit it to. A malformed transaction or one on an invalid account won't get forwarded, while a valid transaction will. But ...
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 ...
You will need to start Horizon with the ingest flag enabled in order for Horizon to ingest data from stellar core. Quoting from the admin guide in the documentation:
To enable ingestion, you must either pass --ingest=true on the command
line or set the INGEST environment variable to "true".