Hot answers tagged

31

I don't think there is a classic money reward, but you will have other kind of reward/benefit. I think you should run your own node if you created some service relying over stellar network. This way you will connect to your horizon instead of using other service. Furthermore you can configure your server to accept query only from your services. Benefits: ...


21

updated 2019-10-15 Public network: Current total ledgers count: 26315419 Core database size (fully synced): 657 GB Horizon database size (fully synced): 1.2 TB History archives: 175 GB


15

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 ...


12

Yes, it should be possible but I'm not aware of any tool/library that implements it. Thet idea is that you send a message of type GET_PEERS to a known stellar core instance, which in turn will reply with a PEERS message. Before being able to send the message you need to authenticate with the peer. By looking at the source, the connection process is as ...


10

We will be redesigning the Nodes section of the Dashboard really soon so it's very likely that the "verified node" will be gone. The reason we added a "verified node" badge was that we wanted to list both: the companies we work with (like IBM) nodes run by developers from our community (we often don't know outside our Slack). By adding a special badge to ...


10

If you look at the stellar dashboard there's a list of validators. You will see names like FairX, IBM, Tempo, SatoshiPay, StellarPort etc. These are all businesses that are invested in the success of Stellar. Since it's very cheap to run a validator (it's comparable to running an email server) you don't need big incentives to become one. Just an interest in ...


9

As some have noted in other answers, there is no direct monetary incentive in maintaining a node. This isn't necessarily bad news: if you look at Bitcoin's proof-of-work - and especially at how it became centralised over time - then it makes some sense NOT to have a monetary incentive, and thus avoid the problems it can cause.


6

Okay. So found the solution with help of @Bartek Nowotarski. My local horizon didn't have SSL certificate. So I had to either add SSL to the horizon Use it without SSL: var server = new StellarSdk.Server('http://127.0.0.1:8000', {allowHttp: true}); Not sure why this was not documented anywhere.


5

It depends what you want to do with those peers: if you're looking at ip+port addresses, you can simply get a list of known peers on the network by just leaving a stellar-core running for a while. This will build a list of peers in its "peers" table (an instance only connects to a small subset of that list). For this particular scenario you don't need to re-...


5

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 ...


4

The network passphrase hash is a component of the transaction hash data that is signed (example from the Java SDK). This means that transactions in one network are invalid in other networks.


4

The docs specify the hardware requirements, quoting (as off 5/7/2018): Stellar-Core Instances of Stellar-Core are part of the network as a node and therefore need to be large enough to support the volume on the network. Minimum CPU: 4-Core (8-Thread) Intel i7/Xeon or equivalent (c5.xlarge on AWS) RAM: 8GB DDR4 SSD: 64GB ...


4

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 ...


3

a) I guess the easiest way should be to run your testnet node in a non persistent ephemeral mode and simply restart the container. b) You could as well open a shell into your container and manually recreate everything similar to the package way. # open container shell docker ps docker exec -it [CONTAINER ID] /bin/bash # stop core + horizon supervisorctl ...


3

Nodes rely on the fact that SCP messages are broadcasted to all peers on the network (for the most part); the number of peer to peer connections just increases the chances that the network as a whole is strongly connected (it's mostly randomly connected) which in turn pretty much guarantees that messages eventually reach all peers on the network. Note that ...


3

If the node cannot catch up, it will fall behind in the ledger state. This is a problem for anyone who uses horizon on that node. However, it would only be a problem for consensus if other nodes placed the slow node in their quorum slices, which they are unlikely to do if you can't keep up with the network.


3

If you're running stellar-core take a look at list of commands available https://github.com/stellar/stellar-core/blob/master/docs/software/commands.md This command shows you overview of quorum for any node stellar-core -c 'quorum' stellar-core -c 'quorum?node=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' And this command gives you some info about all nodes ...


3

There is no clear cut specifications. Note that stellar core requires 64bit OS. If your small machine can afford running 64 bit, it should be more than powerful enough and there is no problem. Update 2018 Nov: Over 250GB storage used, for full-sync public network which has been up for several years. Note that the projected usage is likely ...


2

Just for anyone else having the same trouble - I was using a template with some old/expired validators in it. You can get other examples from the docs and from dashboard.stellar.org. Setting up for the first time can be tricky. This was a noob question. But the next will be less noob :)


2

You can check out the following "one-click" templates for deploying Stellar on AWS. The second one uses RDS for the database and EFS for local state. The templates are still under development so they are wired to connect to the test network for now, but the plan is to continue make them more robust and production ready so you can keep an eye on the project: ...


2

If you are using Amazon RDS already, Amazon EC2 instance is the best option. Amazon offers relatively cheap t2.small instances. If you are going to build some app that interacts with Stellar Core, consider using c5.* instances, which are better suited for applications with heavy CPU utilization. By the way, Linux provides much better performance on cheap ...


2

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. EDIT (Detailed explanation of the tx ...


2

Stellar has a fixed base fee. You can calculate the expected fee with this formula (# of operations × base fee) where base fee is 100 stroops. See the docs. Nobody can earns XLM from his validator because all fees goes into the fee pool, and then these lumens are distributed by inflation pools. inflation docs Stellar use a different consensus protocol, ...


2

The Secret seed is used to: encrypt outbound data (to be decrypted with Public value on the other end), and/or decrypt inbound data (encrypted with Public value on the other end). If you want this pair to remain the same throughout stellar-core restarts, use the config file as the previous answer suggests. Otherwise, stellar-core will create a new pair for ...


2

Yes, you should create a stellar keypair and define it in your stellar-core.cfg NODE_SEED="S..." NODE_IS_VALIDATOR=true You have to provide a history archive, here is a snippet from the example stellar-core.cfg: # Note: any archive you *put* to you must run `$ stellar-core --newhist <historyarchive>` # once before you start. # for ...


1

The protocol consists of exchanging digitally-signed messages bound to nodes' quorum slices. ( https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ ) The trusted nodeIds that you put in your quorum set VALIDATORS configuration are in fact public keys of the secret NODE_SEEDs from the opposing nodes.


1

It allways generates a new random seed and I guess it's just there to have a convenient way to generate one when you are setting up a stellar-core. Stellar-core itself generates a new random seed as nodeId on every restart, unless you define a fixed one in your config. # stellar-core.cfg # the corresponding public is your stellar-cores public key NODE_SEED=...


1

Dunno if that's helpful, here's something I wrote 1.5 years ago https://galactictalk.org/d/230-history-of-stellar-as-i-remember-it


1

After startup, your node should have established connection with your indicated peers. On the go, there's not much to do with after startup. The nodes just exchange data and run consensus algorithm. In stellar-core.config, there are several fields related to peers discovery (refer to example config here). NETWORK_PASSPHRASE="Public Global Stellar Network ...


1

A v-blocking set is a set of node that intersects with any quorum: you can think of that set as nodes that must be included (but not at the same time) in order to reach quorum. A simple example is that if you require 75% majority, any set that makes 30% of the population would be v-blocking as you cannot have any 75% majority without gaining support from ...


Only top voted, non community-wiki answers of a minimum length are eligible