BR thank you for pointing out. I was just about the raise the question.
Will the payout still happen for those nodes which did not pass the version test ?
no, sorry
Will there be payout for 9/11/2017?
As usual there is payout for the nodes that passed the tests.
Hi BloodyRookie,
I kwow you are managing the supernodes program and it is good to see you are still changing and improving the system.
However, having a domain was mentioned in the beginning as possible, and having the domain name in the NIS config was not needed, was not a criterium and was not mentioned as mandatory. So It was not mentioned having the ip in the NIS config was going to be an unexpected config or a config that was not going to be accepted for those servers.
Off course Iām one of them, but Iām not alone since from basic calculations i conclude there are some 75 nodes in this situation.
Anyway, not paying out for two rounds is an unfair punishment for those 75 servers configured this way. I know the 280.000 for those two rounds are paid to others and therefore the budget for those two rounds is already spent. But I would like to propose and ask to consider compensating the loss for those servers from additional budget. It does not have to be the 340 and 338 paid to the other servers for those two rounds, but for example the usual 290 paid during the last week. This would require 2 x 75 x 290 = 43.500
Can you please ask the other core members if they would agree with such additional budget as it would be a fair solution? At least I would consider that to be a fair solution, since those who manage such servers are not responsible for the missed payouts.
I also would like to know if we can prevent such events to happen again by changing the config. I guess it is not needed since you mention you resolved the issue, but can you please confirm we can leave the config as it is, or not?
Thanks for your continued efforts,
garp
@garp:
Collecting those 75 supernodes, then check for each which failed which round and then sending 75 transactions manually is a lot of work. My time is limited, so i would prefer not to do so.
You canāt prevent human failure in the future, so it will happen again but i try to minimize those failures.
The config is ok as is, no need to change. But generally i recommend to use the same approach in the config and the enroll message when setting up a new supernode.
From another point of view. Because it is similar, write one thing I thought.
I think that it is desirable to use IP as much as possible as long as it is a fixed IP.
That is because it does not depend on DNS failure.
If IP changes at home server etc., you will have to use DDNS.
I think it is best to use FQDN as a means of such a case.
thanks
lol @ that satoshi pic, leave the poor guy alone ha
@BloodyRookie
So spending the additional budget is acceptable, but spending the additional time isnāt? Thatās not reflecting the usual spirit found in the NEM project and community.
I can imagine it would be a considerable effort. But those efforts should be made in an attempt to resolve the complete issue. Changing the code is not the only element of resolving a shortcoming. Rectifying temporary negative effects of a shortcoming should be part of the fix as well. Itās normal practice in software development and bugfixing.
In an attempt to save you the time, I can give you the amount of rounds i have missed and an account number in e PM, so you can execute a transfer of the missed payouts.
On the other hand, i would like to propose supernodes based on a domain name to be rewarded with a higher or an additional amount since they provide additional security for the community and the users. Thatās why I have used domain names. Why shouldnāt the additional security of domain names be used as an optional criteria for a domain supernode, which could be rewarded with a higher payout?
So maybe you want to do it as you are part of the community. For every node affected collect all data in a spreadsheet, double check everything and then send out the xem for each node?
In what way is it more secure? Resolving a domain name to an ip is an additional step which could fail. I donāt see an improvement using a domain name. But please elaborate.
2 Likes
Please remove this supernode. I have sent message to NAFUNDBUKIOSTMD4BNXL7ZFE735QHN7A3FBS6CMY
Name: Tiger_WI
IP: 159.203.34.58
Thank you
Ok, Iāll see what data I can collect.
In case I manage to collect all information needed to execute the transfers, do you want me to share the info with you so you can execute the transfers or do you prefer to transfer the total amount to me so I can execute the transfers to individual accounts?
The current nem.io website and marketing efforts are more and more focused on blockchain offerings and applications for enterprise solutions. Enterprises can be expected to prefer dealing with identifiable persons, companies and organizations as opposed to dealing with an anonymous entity. Hence the creation of the nem.io foundation last year.
For enterprise solutions, companies can be expected to prefer connecting to supernodes they know are hosted and maintained by and identifiable person or company. This can be guaranteed by a domain supernode, as anybody can use the popular whois services to verify who owns a specific domain. Even if such services do not deirectly point to the supernode owner, at least they provide the info of the ISP or the provider who has a contract with and the identification of the owner.
Iāve managed to write some code to collect the needed data and verified manually afterwards.
It turns out 73 different domain supernodes have missed 145 payouts last week.
Using 290 as the proposed compensation amount, this correction would cost 145 x 290 + 73 = 42123 XEM.
If this amount is transferred to the account I registered as founding member of the nem.io foundation (NCF25P-QZI2PN-PMGXDM-QG2ZES-4VABR4-LB4GCP-GARP), Iām willing to do the effort to execute the 73 transfers.
Happy to help,
garp
I have updated ip address for a supernode, but after 3 days it is still showing old ip address in supernodes.nem.io
###REMOVED the details###
I shall try to re-enroll as a new supernode
Hope one day I can finally run a supernode 
i sent 42200 XEM to that account. Thanks for helping.
I think private companies will not use the public network for their activity at least if it is a major company.
Not sure how much value a domain name gives, but maybe others can comment on that.
Aside from that i am not eager to make any changes to the supernodes master since this could cause downtime again.
Is this still a problem or was it resolved meanwhile?