The privKey has 128 characters. Just counted right in NCC.
There was a possibility to import a json File in earlier Version, is it still active? I can’t find it. That would be easier maybe.
So I finally found the Error: As you said the key should have 64 or 66 Characters and mine had 128, I had a look. And: Surprise! It’s written two times in NCC. So I deleted the double one and import worked fine. I just wonder how that could happen. I opened NCC several times the last weeks to resolve this issue and it was always that long…
1 Like
Hello!
I have just made a testnet transaction with an [automatic] XEM Amount of 1 (automatic because I am checking the box “Mosaic transfer”). Then I attached 9000000 nem:xem (9 XEM) and 100 of my mosaic as you can see here (first incoming transaction of this account… its the tx with data hash db1feb6fa6858b03af08b9817bfbf6e155fa4676cfc22f333ff4551f437e1227): http://bob.nem.ninja:7890//account/transfers/incoming?address=TBRA6PUMPOFLGJ27ZM5XY2FSO4ZN2HIZBARU47UQ
But as you can see on the screenshot, only 9 XEM got credited to the account, so where is this missing 1 XEM from the Amount field? When I select nem:xem mosaic to attach and set the amount to 9000000, the Levy field stays to “None” so I really don’t think I’m missing a fee or so.
My XEM address in case this bug is confirmed 
: NB72EM6TTSX72O47T3GQFL345AB5WYKIDODKPPYW
You are transferring mosaics using a V2 transaction (V2=Version 2).
Such a transaction has to interpreted in a different way than V1 transactions.
Basicly the amount field only says “1 times what you find in the attachments”. It doesn’t specify a xem amount.
if the amount field would be 5.000000 then 5 times the attachment would be transferred.
2 Likes
Hello, I found something else tonight!
My process:
- send XEM to a MultiSig account from a 3rd party account (account A sends to account MS)
- also logged in with account B which is cosignatory of acount MS (in another tab).
- when I send the transaction from account A, it appears in account B (probably because this one is a cosignatory of MS, and the money goes to MS).
- but after the transaction was confirmed (as show screenshots), the “MultiSig” tab in Send & Receive with account B, is not up to date with the Multi Sig Balance!
- when I logout account B, and log back in, I then don’t see MS’s transaction anymore! but the MultiSig tab in Send & Receive, this time, is up to date with the MultiSig balance. i confirm after writing this entry the transaction is still not appearing anymore as it did on account B.
Something is wrong and I think this can be 2 bugs:
- I’m not sure an incoming transaction is supposed to appear on dashboards of cosignatories? If it should appear, why doesn’t it appear anymore when I logout / login again.
- Then I also think the MultiSig tab in Send & Receive should update the Multisig’s balance anytime it is displayed in the Balance field.
Following is the scenario from above in screenshots :
-
Screenshot 1: This is taken from COSIGNATORY ACCOUNT (account B), not the one from the transaction, but the cosignatory of the recipient of this transaction.
-
Screenshot 2: Also taken with COSIGNATORY ACCOUNT (account B).
Edit: One more little typo bug discovered when my signature is “awaited” for a multisig account transaction i’m a consignatory of. In the following error message “signature” is missing :
Have a nice day!
Version 1.3.4
- New account safety measures at wallet creation
- Transaction details and multisignature dropdowns shows account label if present in address book
- Selected language stored in local storage
- Russian translation
- Minor fixes & improvements
4 Likes
Although it is a warning sentence for an additional English part, Japanese people ignore English and do not read, so do not you have time to translate for 30 minutes?
I made a Japanese version so I git pull it.
Probably the team already knows about is, but I made a wallet with a customized private key. After I had my 10k vested balance, it was impossible to start delegated harvesting because there was a bug in the system that my private key couldn’t communicate with my remote address. I guess that needs to be fixed also.
The team was unable to fix it for me so the only solution for me was to make a new wallet…
1 Like
Awesome stuff, thanks so much for your hard work on this Quantum_Mechanics!
Any time-lines on the Apostille certificate generation to be reduced in size and in PDF in future? That will be great 
that will definitely be on our list of things to do.
1 Like
Hi QM.
When setting 0-of-m using Edit a multisignature contract
This is a specification that will be m-of-m.
However, NanoWallet can not sign m-of-m.
Notice comes but all signatures can not be done
My address
NB2225-VL43PT-ZROTAE-IMVZFW-JK3CPE-7Y23OF-RTTO
sorry Poor English
…Can you understand that?
I am not good at English.
Hi,
Yes I understand 
Thanks for the report, will look into it for upcoming release
2 Likes
Hello there!
I have had a data update issue with the NanoWallet which I think is important. Following is the Scenario:
- I have a locally running NIS (in Node page, custom node 192.168.1.101)
- The local NIS needed about 10 - 15 minutes to synchronize with the blockchain this morning, that is ok.
- I went to my nanowallet and logged in with my account. I checked “Node” and it would say Error (only?), now that is not my problem because I understand that it means “Error NIS is synchronizing”. Nevertheless, the account show the correct balance non-zero in XEM.
- Now when my local NIS is done synchronizing I came back to the nanowallet tab and clicked on Dashboard.
- My balance was stating 0 XEM!
- I needed to sign out + sign back in for the changes to see my correct balance again
I believe there is a problem here as the Update should be done in background, and probably broke as states following screenshot:
NCK34K5LIXL4OMPDLVGPTWPZMGFTDRZQEBRS5Q2S
Take care!
I asked the same question before.
Again, I think that it is better to describe the final fee for the multi-sig account fee.
Some people have received opinions that Fee is different from some people.
I think that it is better to add the following items to the current Fee display.
… + (Min signatures - 1 (Isser)) × 6
Thank you for your consideration.
2 Likes
Hello @Quantum_Mechanics and community.
First of all, congratulations for the huge effort that you’re doing to maintain and grow NanoWallet.
As an improvement for future releases, I would like that the post includes the checksum to ensure the validity of the file. What do you think?
I leave here the sha256sum for future readers.
08d963a7a537dbb32ff5278c1958f56f1c2baa20b7a29e5c5e4e4f7e70b47ee5 NanoWallet-1.3.4 -- Apostille TX f9a506e3abfa225d60b4447017279a6af7561428e0f53839fb3bea92fe8c129d -- Date 2017-04-20.zip
Best,
Hi, checksum is now added to the op .
Yeah I think it could, will look into it for the next release
2 Likes
I don’t know if this is considered as a bug but i think it is a issue that could be approved. First time i created a wallet and logged into it the node was automatically chosen and active. The second time i logged in the node was not chosen automatically. And for a new person using the wallet it gave me almost a heart attack to not see my account balance. Could the wallet have maybe a text in dashboard to make it very clear when node is not selected? The text: nothing to show is pretty alerting :D.
Maybe something like: nothing to show here, select a node
Even adding a text that tells that the nodes are safe to connect would probably decrease problems with new account owners.
Another thing I noticed:
Updating the market information doesn’t seem to update the USD balance.
-J
ND6NJZ-AZLZS4-PWYMUH-4ERJNU-YIYZWO-FFKH2X-SLXK
