Can you disable my supernode 139.59.10.53.
I had to resize it as it was failing too much, just enrolled a new droplet in Toronto
done
I enrolled 159.203.19.124 yesterday, but havenât seen it show up in the supernode list?
Is there an issue with the node?
You used the same delegated public key for the new node that you had used for the other node. That canât be handled automatically.
I added it manually to the db:
Increase in the number of NEM supernodes:
- in the 0-th month - 144
- in the 1-st month - 68
- in the 2-nd month - 38
The trend is that in each subsequent month comes supernodes approximately 2 times less than before. Summing of 144, 72, 36, 18 ⌠(geom. progression), we get 288. That is, under the existing threshold of entry into supernodes there is quantity of supernodes in NEM network <300.
Are discussed lowering the threshold from 3M to 1M XEM for example?
i wait september
i think nem team will increased at least at 100.000 to 130.000 xem from 70.000 that is it today
Silver Coins for Distribution to Stakeholders 211,885,227.63 XEM
i prefer these coin to go for super nodes
these is the best idea for that one
Itâd be a good idea to move the silver coin funds to the Supernode program. As that would be no easy task to distribute physical coins to all stake holders.
But I think youâd just have supernode users vote yes, and most other stakeholders vote no âŚ
Why supernodes must said yes
What happen if they said yes ??
Good news for all owners of supernodes:
From September 1st on the daily payout for all supernodes will increase from 70k xem / day to 140k xem / day.
3 Likes
awesome!!!
That news made my day. 
I will voted yes thatâs make my day
Dev XEM is super
Does anyone have a competent answer?
The account the delegated key, the delegated account, never has any xem on it so there is nothing that can be stolen. They private key from the corresponding main account cannot be recovered from the private delegated key. Also, if you are harvesting with your delegated key, all harvested fees go directly to the corresponding main account.
Nevertheless you usually do not make the private delegated key public. The reason is that if someone knows many delegated keys with a cumulative importance of 50+%, then he can harvest a secret chain and fork the NEM mainnet.
@romawi:
The delegated Harvesting is explained on page eleven of the Tech Reference: http://nem.io/NEM_techRef.pdf
Section:4.2 Importance transfer transactions
Thanks for quick answer.To be sure:That means, if I instruct someone to setup for me a supernode on a server, it is no securityproblem to give him the delegate private key.
Right.
Check this out:
https://forum.nem.io/t/nem-supernode-rewards-program/1735/479
Although 3M XEM may be out of reach for most people, having a ~300 solid and (seriously) involved nodebase is something very few blockchains can say.
Furthermore, if you make the effort to own a supernode and it eventually became profitable without the fund to back it (just via fees and a high xem price), you would get a very nice and continuous return over investment.
Although I didnât own an initial stake myself, I am fully commited to this project and made a big investment to be able to participate. I am quite sure that even at a higher price many people will
Hey guys,
Yesterday I set up my supernode on Digital Ocean using the awesome https://github.com/rb2nem/nem-docker
After waiting for more than 6 rounds and reading this entire thread it still fails the tests:
http://supernodes.nem.io/details/327
AFAIK the versions should be fine (but they fail):
http://185.14.185.109:7890/node/extended-info
http://185.14.185.109:7880/nr/metaData
The droplet I am running is in Amsterdam:
2 GB Memory / 40 GB Disk / 3TB Transfer
I feel itâs using a lot more resources than when the NIS was standing on itâs own but I guess itâs normal because of the servant.
Any idea on how to make this right?
Thanks!
servant is passing tests, NIS fails because it has a wrong boot key. Please check that key, it should match the key used by the servant.