NEM Wallet Beta 2.4.4 - Bug bounty paid in XEM

Please make it possible to select the camera device used for reading the QR code.

Thanks

I tested it with two cameras and there is a dropdown list to choose it. Or maybe it depends on some system settings?
Choosing the camera work only on my firefox, in chrome it’s set up by default.

1 Like

Environment:
OS: MacOS HighSierra
Browser: Google Chrome 67

Firefox comes up with options to start up the camera.
In Chrome, there was no choice and the default image input device was applied.
Currently, Chrome’s default image input device is changed to handle it.
It seems that it is a matter of my Chrome setting that there is no choice.

1 Like

Anyone facing the same issue? Is it happening when the namespace is already in use?

@joeseunghyuncho
Looks like error happens when you try renew namespace to early (it’s possible month before expiration date).

I see. I means someone has taken the same name already? I could create an another namespace under a new name after failing with one namespace’ name.

You can look at all registered namespaces here:
http://explorer.nemchina.com/#/namespacelist

Also it should be available when you click Explorer in top nanowallet navigation.

Thanks. Lots of interesting Namespaces registered!

Nano Wallet Bug - 2.3.0. the wallet is not able to show the full details of transaction date and time. and also need to the show the timezone.

for the usage in business environment. the full details of date, time need to be show in full format, with time zone.

same issue also in ver2.2.0

when i try to setup sub name space and leave some space in the name, the screen shows multiple warning message.

after i moving the mouse, looks some of them is disappear. The behavior looks pretty strange.

Hi
please tell me.
If the nodes to be connected are different, the displayed importance differs.
Is this a problem with Wallet’s display?
Or is there a problem with the PC’s cache?
Or is it a node or NIS API issue?

1 Like

@GodTanu could you send address (private message if you prefer)? I will check directly with API

1 Like

Hi, pawelm, that is actually my account, and GodTanu posted the issue on behalf of me.

I’ve already checked API and here’s the screenshots.

I’d kept a few hundred thousand XEM in this account until the end of June, sent most of it to another account (2.95XEM left), and haven’t touched it since then, for more than a month.

What else info can I tell you? Do you still want the address? I appreciate your help.

1 Like

@BloodyRookie importance shouldn’t be 0? Balance is below 3 XEM.

It must be, but connecting to the sixteen nodes of Nano Wallet 2.3.2, only four nodes below are showing importance 0, other eleven showing 0.1843 (can’t connect to alice3 now.)

san
hachi
jusan
alice2

After transferring the xem away from the account, the importance in not immediately zero. The importance flows slowly from the source to the destination account. To analyze in detail I would need the account’s address.
@lena: you can PM me the address if you don’t want it to be public.

@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.

4 Likes

@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?

  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).
2 Likes

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:)