NEM Wallet Beta 2.4.2 - Bug bounty paid in XEM


#347

@lena:
The importance of the account is 0. The reason why nodes like hugealice show a non-zero importance is as follows:

  1. When a node is configured with default configuration, after restart of the node and chain loading the poi importance is calculated with current height that the node’s chain has. Since the account did not have a balance that makes it eligible for importance calculation, the importance of the account is not set which means it has 0 importance.
  2. If a node is configured with the historical account data flag set (like the hugealice node), then upon restart and chain loading the poi calculation is done every 359 blocks and since the account in question once had a balance that made it eligible for importance calculation, it receives importance values during chain loading. At a later point, when you transferred the balance to another account, the account is not eligible for importance calculation any more. But the old importance is not zeroed out and the /account/get request just returns the last non-zero importance it had (that is for a height of ~1690000).

So that explains the different values seen in the request. Now you might ask, if the account can harvest since some nodes have a non-zero importance for the account in the request. The answer is *no. The non-zero importance seen in the response is for a very old height and when NIS internally queries the importance, it sees zero for the account at current height (no matter how the node is configured) and therefore does not let the account harvest.


#348

@BloodyRookie
Thank you for the explanation, please let me ask three more questions:

  1. A node is configured with default configuration, or with the historical account data flag set. Is it set so permanently? e.g. are the hugealice nodes always the latter?

  2. Will the /account/get request continue to return the last non-zero importance? Or it returns the correct importance 0 someday?

  3. ”(that is for a height of ~1690000)” Did things change after that?


#349
  1. You can configure that in the file config.properties. Upon startup, NIS configures as stated in that file.
  2. As long as NIS is configured to expose historical account data, the wrong (non-zero) importance will will be shown in response to the request.
  3. At some point you transferred the balance to another account, so the importance was not calculated any more (meaning it has 0 importance).

#350

Understand. I’ve been just a XEM user and haven’t been much conscious of how the nodes are working.
It’s a good chance to learn, and I’m excited to know more about NEM. Thank you for your kind support:)


#351

Even though it’s configurable, it is called a display bug.
A general user will judge as such.

Is this phenomenon improved after catapult?
If this phenomenon does not occur after the catapult, I will not worry.


#352

Catapult server has a different approach and there is no config for historical account data in that form. If historical account data is supported, it will be correct.


#353

Hi, I think I have found a bug in “Explorer” section in nanowallet.
I had some xems in my account, then transfered them, and the balance is showing a different value than the “Your mosaics (nem:xem)” in the “Explorer” section.

An screenshoot is attached.


#354

@xrltechcorner please report bugs here -> http://github.com/NemProject/NanoWallet/issues


#355

Done.


#356

Version 2.4.2

  • Updated Voting module
  • Added NEMonster collection game (by aenima86)
  • Fixed Changelly widget
  • Renamed to NEM Wallet
  • Minor fixes and improvements

The Chrome builds are not included in this release due to dependency issue.