None never reaches mining state

Yup, $9/node invest per node assuming dirt cheap Linux instances. Need 2 rewards to break even then 1 reward every month to not use your own capital. Either way, you have to pay for VPS rental out of pocket unless they accept NKN mainnet since transferring ERC20 has limited windows and fees likely as high as any rewards you gain in ~2 months. Not to be negative, but there is no way this makes any real money for an individual … a luck-based reward program is pure gambling. After my Vultr credits are burnt, I’ll kill the nodes and maybe offer the node wallets (Generated ID) for sale to others that want to play.

I setup 2 more Vultr servers (Windows) today (Toronto and Mexico City) since I won’t burn through the $100 credit in 14 days without more nodes. I already had extra NKN in my wallet due to ERC20 minimum transfer. Now I have 5 nodes and 25 NKN left of my initial $45 investment.

3 nodes in North America (Florida, Georgia, and Texas) running 224-243K/hour
Toronto is running 670K/hour
Mexico City is running 460K/hour

I might get one more Vultr node in Europe or Asia just to see what kind of relay rates it achieves.

All PoW blockchain network has “luck based mining reward”. They are statistically fair (all nodes have similar share of entire mining reward, averaged over large amount of nodes and over long period of time), but cannot guarantee 1 block per 45 days.

I wonder if it is possible to find out who uses this network to relay what.

My raspberry pi has been going for two days straight and shows a height in the low 300Ks … I see neighbor node reporting heights in the low 3 millions. Does it mean it will be syncing and pruning till it catches up with the neighbors? Like in 100s of years? Is there a way to catch up and start being eligible to earn?

Current height (at time of reply) is 3203285. If you are way below that, consider downloading a recent ChainDB. It will still have to sync to catchup, but will save you many days. There are several posts in the forum about getting TAR.GZ and putting it on a Linux node.

Thank you for that tip. I followed the tutorial and rebooted but when the node starts back up, pruning continues in the low 300K’s despite the new ChainDB folder having been properly created in the node folder. Is there a command to get the node to re-read the DB and not continue from where it left off?

A node always prunes when started. It is isn’t pruning at a new height, something was not done properly with the new ChainDB. Stop the node service, delete the contents of ChainDB, move the entire contents of TAR.GZ into ChainDB, chmod the files (644 I believe) and start the node service. I’ve done this on 2 Linux and 5 windows nodes without issue.

1 Like