NEM Supernode Rewards Program

Blog Posts
#895

You do not need to be enrolled as a supernode to be a node providing services.
You only have to enroll for a supernode if you want to receive the supernode rewards, if you do not enroll you will be a normal node. The only difference is the supernode test and the supernode reward (if you would pass the tests).

2 Likes
#896

You do contribute if you just let the node run in the network and if you turn harvesting on.

There is no disadvantage when you turn harvesting on. Just try with something like
Nis.unlockedLimit = 3
it should be ok.

1 Like
#897

Thank you meyns and BloodyRookie.

We did enroll because we can share more up-to-date data in supernode communication.
And it is also made public as NIS server list.

This time, I understood that it is possible to operate as a harvesting server even if XEM is missing.
Later, we will enable harvest on the server side.

Thank you very much.

#898

what do you mean with “more up-to-date data”?

True, but generally we want only supernodes to be in the supernode list.
Don’t get me wrong, i appreaciate your effort, but if we let node join the list that do not fulfill the needs of a supernode then everyone with a node running will add it to the supernodes list.

1 Like
#899

It means faster and more accurate.

Considering the original meaning, I understood that enrolling as a super node is wrong.
Present situation In Japan, many super nodes are operated by people who have no knowledge of UNIX at all.
In this case, I am actually doing it to build a super node with various OS and make detailed Japanese manual.
Finally, please tell me how to delete from super node list.

#900

A supernode does not distribute data faster just because it is in the supernodes program. Being a supernode simply means that the node is guaranteed to fulfill some requirements.
You are right in the sense that people can publicly see how good your node is if it is a supernode.

hmm…PM me maybe we can find a solution.

2 Likes
#901

Hello
I brought up an issue of my supernode registration on a Slack channel and was asked to report it on the forum.

BloodyRookie could you please make sure the node https://supernodes.nem.io/details/494 refers to this public key 041901e8e92c73802ad878416deb15e52574e3c5c16d25f981bf302fcc266586.

A person on the Slack suggested you could remove it and I would re-register it.

This is what extended-info says (I removed info on my IP for security reasons):

{“node”:{“metaData”:{“features”:1,“application”:null,“networkId”:104,“version”:“0.6.83-BETA”,“platform”:“Oracle Corporation (1.8.0_121) on Linux”},“endpoint”:{“protocol”:“http”,“port”:7890,“host”:""},“identity”:{“name”:“your.NEM.WORLD”,“public-key”:“041901e8e92c73802ad878416deb15e52574e3c5c16d25f981bf302fcc266586”}},“nisInfo”:{“currentTime”:60009596,“application”:“NEM Deploy”,“startTime”:59499908,“version”:“0.6.83-BETA”,“signer”:null}}

#902

i disabled the old registration and added a new one with the changed public key:

https://supernodes.nem.io/details/512

#904

Sorry I don’t know what I’m doing wrong but it doesn’t work again.

At least it shows the balance is right while the rest is completely FAIL.

I registered the supernode again but on the same day I had to create a new OS. So downloaded nanowallet, imported keys and noticed my delegated public and private keys have changed. I made changes on the remote server and sent registration transaction once more… and all it show is again fail fail fail.

Please help.

{“node”:{“metaData”:{“features”:1,“application”:null,“networkId”:104,“version”:“0.6.83-BETA”,“platform”:“Oracle Corporation (1.8.0_121) on Linux”},“endpoint”:{“protocol”:“http”,“port”:7890,“host”:“138.201.247.32”},“identity”:{“name”:“your.NEM.WORLD”,“public-key”:“09479ee7396da9f1035fd9a379e7c077e6717852022bfefb7b4a52987676abea”}},“nisInfo”:{“currentTime”:60217291,“application”:“NEM Deploy”,“startTime”:60059053,“version”:“0.6.83-BETA”,“signer”:null}}

#905

I had this problem in the past.
Problem is your original private key is still linked to the old delegated account. Even if you make a new wallet and import the private key, it will generate e new delegated account, but the private key is still linked to the old delegated account for harvesting.
Your delegated keys will change if you make a new wallet with the original private key, the delegated account is not generated from the private key, but randomly generated when making a wallet even if you use the original private key.
And if you activated delegated harvesting with your old delegated keys, you will only be able to use the old delegated keys. If you want to use the new delegated keys, you will have to reactivate delegated harvesting with the new delegated keys.
Other option is if you still have the old delegated private key is to still use that in the supernode, your original private key is still linked to the old delegated account.

#906

Thank you for this explanation.
Unfortunately I haven’t got the old delegated key any more, I thought it was redundant and never made a note of it, so it’s gone.
Regarding reactivation of delegated harvesting, I deactivated it using ‘Importance transfer transaction’ and waited for the Remote Status to turn to inactive, then I sent another Activation message and waited for it to turn Active. Now I selected the IP of my node from the list, typed a passphrase and clicked on start delegated harvesting. I should be able to see the result in three to two hours time. I hope that will work, fingers crossed.

#907

Last two measuring rounds, both of my nodes failed to Height/Chain Part. Has somebody the same experience? I did upgrade from 0.6.82 to 0.6.83, but not these two round ago, but several days (means at least 10-12 rounds) ago. So this is not the case, probably.

#908

The network is experiencing some problems, we will inform about details once we know more.

#909

In my opinion, nodes forking occurred around 3 pm on the 24th (UTC).
A node that does not capture the block observed that it occurred on a server with up time of 6 days or less when the cause occurred.

#910

(Super)nodes measuring failing again and again, now, beside the Height/Chain Part, with the Balance item too. Do we already know, why this is occured and why it’s still happening ?

#911

Height / Chain Part yes.

The balance is not affected. Maybe someone change his Balance of xem. It´s only one SN.

Date Sun Feb 26 2017 02:50:30 GMT+0000
Expected Min Balance 3000000
Reported Balance 2999912

#912

Well, but do we know, why there is still fork (or some outage) in the network? When I’m connected with my local NCC to my supernode, it’s still writes: “NIS is synchronizing. At block 997307, est. 1 day behind. (at block 997307)” … it looks quite the same as yesterday. Restart of supernode didn’t change anything.

#913

We should wait until the developers found the reason.
Just keep your SN running. I’ll do the same.
It may be something of the reward lost, but that is ok( I think ).

#914

NIS version 0.6.84 is available

This upgrade is mandatory!

Please upgrade till next sunday, i will upgrade the referende NIS on monday

1 Like
#915

Hi,

I updated to last one version and everything is fine, but still get fail results (Height, Chain part and Version)

ip - 13.113.99.29

https://supernodes.nem.io/details/515

Could you please help to fix it?

Thanks in advance