Got it! Thanks BR!!
Hello @BloodyRookie
Iâm using two additional accounts to harvest with my supernode account but Iâm not sure if they are harvesting correctly. This is due to only receiving zero blocks intermittently in all accounts. I would expect to see consistent periodic zero blocks. I havenât seen any zero blocks for 1.5 days for one account and 1 day for the others.
The supernode main accountâs private key is placed here in the âconfig-user.propertiesâ file:
nis.bootKey = privateKey1
I have configured the other two accounts (piped) in the supernode âconfig-user.propertiesâ file using the following parameter assignment:
nis.additionalHarvesterPrivateKeys = privateKey2|privateKey3
Delegated harvesting is active on all three accounts but turned OFF in their NCCâs (wallets) with the expectation that the supernode NIS would automatically harvest for all accounts. Before, I had delegated harvesting turned on for all accounts but I was getting no harvest blocks, not even zero blocks. So I thought it was conflicting with the supernode. When I turned delegated harvesting off, I got a harvesting reward but not the consistent zero blocks like I saw when using local harvesting.
Do you know what might be causing this seemingly intermittent behavior? Are there any lags between when delegated harvesting is turned on or off?
Thanks in advance.
Oh, and one more thing. FYI, I have the Host setting on the landing page set to the IP address of my supernode⌠if that matters.
@TheRealKnave: configuration approach looks good. To be sure that the node is really harvesting you could take a look at the NIS logs of your supernode. There should be messages like
â3 harvesters are attempting to harvest a new block.â
What do you mean with âzero blocksâ, no blocks harvested or all harvested blocks have zero fee?
Hello @BloodyRookie
By âzero blocksâ, I mean harvested blocks with zero fee.
I looked at two log files but neither had a âharvesters are attempting to harvest a new blockâ type of message. Here are the two directories I found logs in:
/nem/node-rewards/servant/logs
/nem/nis/logs
Do I need to turn on logging somewhere? I did get 9 XEM on one of the accounts today as well as a zero-fee harvested block. But the previous zero-fee block occurred 1.5 days prior.
Cheers.
@TheRealKnave: can you supply the most recent log from the /nem/nis/logs folder? Did you change anything in the logalpha.properties file?
Aside from that, it is pure luck whether the block contains transactions (and thus contains fees).
Hello @BloodyRookie
I tried attaching the most recent log in /nem/nis/logs to this message but I get a forum error message saying âSorry, new users can not upload attachmentsâ.
Thereâs an error message in the log regarding harvesting:
auto harvesting with âNCMMGLUHLA4Q3DR4QZTZSWWUEXKNOEM3NE6YAUNDâ -> âFAILURE_UNKNOWN_ACCOUNTâ
The above account is my supernode public remote account address.
Regarding the logalpha.properties, I havenât changed that file.
Cheers!
@TheRealKnave: you can upload the file on a file hoster and post a link here.
The above error message means something is wrong. Maybe you started NIS before the delegated harvesting was fully enabled?
Hello @BloodyRookie
Good idea. Hereâs a dropbox link:
Iâm pretty sure I rebooted the supernode server after delegated harvesting was enabled on all accounts. But I did stop delegated harvesting on the NCC after starting the supernode NIS because it seemed to conflict with supernode NIS harvesting.
Looks like you started NIS and synced from scratch. At the time NIS tried to start harvesting the chain was not downloaded yet and therefore the account was unknown and that lead to the node not harvesting. Since your node is synced now, try restarting NIS and see if it works now.
Hello @BloodyRookie
It looks like itâs been working all this time. I sent an old log file by mistake. The most recent shows successful harvesting attempts for all three accounts. So getting this type of message for all three:
**auto harvesting with â**delegated account public addressâ -> âSUCCESSâ
Thanks for all the help!!
So, did you successfully fixed this issue, BR ? It looks like, that delay is still remains â every round (normally in âsix-hours-rangeâ) is delayed around 1hrs (or a little more). So in fact it means, that daily reward, which is for âlast four roundsâ (and thus for ~ 24hrs/1 day) under âusual circumstancesâ, is now for 28-30 hours.
why did nit paid yet the 19 of these month?
Yes it is fixed. i will restart the master with the new version today.
I restarted the noderewards master. It will take a few rounds till all delay parameter have settled. It should converge to 6 hours per round.
Hi BR,
I hate to sound like a broken record, but youâve always maintain that you would like to see the SN payout at 400 a day. Currently its more likely to be 300 a day with the amount of SN coming online.
Will this we review anytime soon?
I have talked to the core team and there is no majority for changing anything as of now.
So things will stay like they are for some time.
hello i have some questions first of all i believe that xem per supernodes per day must double
the reason for that is a lot
first is that we have the funds for double again the xem per nodes
second is that xem is less profit than any other coins like dah dcr and more
third is that if we increased the xem per supernodes people will not sell his xem and will buy more xem to build extra supernodes so the price of xem will go up
so make the step ASAP and increased the supernodes
The supernode program was setup to guarantee a strong network. We have ~400 active supernodes so that is enough to guarantee that.
The higher the payout the more supernodes we will get. Even if we increase now, we will get to the same point again where people complain that the payout is not high enough. An increase thus will not solve anything long term.
The funds for the supernodes are limited and the more supernodes we have the more complicated it gets when we run out of funds. Also an increase means that we will run out of funds sooner.
So at least for now, there will be no increase in terms of payout.