NEM Wallet Beta 2.4.4 - Bug bounty paid in XEM


The problem is that to lock or unlock delegated harvesting you’ll need the private key of the remote account (You send it to the node).

It is easy to get the remote public key to monitor harvesting with your way :wink:
But if you want to lock or unlock, you still need the NCC to generate the key pair.

We could do it “watch only” but at one time or another you might need to handle lock and unlock of your account.

Oh, I thought it was obvious so I forgot to mention it:
A user who wants to import an account with delegated harvesting active, should off course be able to provide the private key of the delegated account. If a user has activated delegated harvesting in another client, they should retrieve the private key of the delegated account in that other client. When they want to deactivate remote harvesting in the new client, you could ask them to provide that private key. That is possible and seems logical, no.

Doesn’t that solve the issue? I know it would be enough for me.

If after deactivating remote harvesting, one would like to reactivate remote harvesting again, then it is perfectly acceptable it would be another remote account, generated by the new client.

If you have access to the private key you can simply build a keypair object then, so there is no need to look into txes to find the delegated public as you can directly extract it from the object.

See Keypair in lightwallet

That is not to activate or deactivate, only the public key of the delegated account is needed for that and you can already use a custom one in Nano to do so.

Private key is needed to lock and unlock accounts harvesting (start/stop), which is not the same than activating and deactivating a remote (making an account your remote / de-attributing the remote).

I could ask users to provide the delegated private key if they import an account manually with remote harvesting active, will see what devs thinks about it, but I think the best solution would be to completely switch for a new remote. In the end it’ll be better.

There is now a 5,000 XEM bounty for issues reported to QM’s Github.

Nanowallet is the best NEM client :slight_smile:

And t is just getting started. This will lay the foundation for a lot of good things to come. I wish the first wallet would have been built like this in the first place, but we are catching back up now.

Version 1.0.13

  • Fix message fees (lower)
  • Fix private apostilles
  • Fix audit of private apostilles
  • Minor design

when might be out nanowallet?

Not sure, I’m going through everything and working on getting app ready for translators right now. I hope to finish that before the end of the week, there is a bit to do.

To go on Mainnet we need a bit more testers and feedback.

Until we get more testers, it is hard to confidently put it on the mainnet. It is more or less ready, but we really need some more testers. For instance I have found a couple of small bugs that if people were really testing, they should have found, yet nobody reported them on github. NEM is worth a lot of money. Wallets should be tested I think.

1 Like

why not release source code of nano

it is written in JavaScript, which is interpreted language There is only source code.

any news from nanowaller\t???

Version 1.1.0 coming soon


any news about nano wallet???

Version 1.1.3

  • Ready for translators (Full i18n)
  • Can sign multisignature aggregate modifications, namespace provision, mosaic definition and mosaic supply changes transactions.
  • Improvements on apostille HD accounts
  • Apostille certificates
  • Apostille explorer
  • Custom text apostilles
  • Balance of selected mosaic in transfer module
  • Changelly Instant Exchange module (Thanks to @ReverseCold)
  • Accounts label
  • Improved custom node handling
  • Improved all transaction types details design and data
  • Loading screen for computationnally intensive operations
  • Fix messages with unicode
  • Fix messages with carriage return and keep the formatting in transaction details
  • Fix harvesting with child accounts
  • FAQ module
  • Minor fixes
  • Minor design

Maybe I forgot a few little things, will update this post if I remember.

Important notes:

All old .nty files and apostilled files are now invalid because a few things changed in both.

You can consult and translate it if you want to add your own language. Please try to keep html tags if any, just translate between them. Of course you are free to move those tags in the sentence to arrange it as your language need.


Can anybody report if Apostille works in Chrome? I sometimes had problems downloading thebzipped file. And if so does the private version work?

DO make nano friendly for mobile explorer?

Some people have experimented with using Nano on Android, but it is definitely not a friendly UI. We have plans in the future to make a version that will be scaled properly to mobile size, but that will take a while. We are just trying to get regular Nano to work first.

Getting the private key for delegate accounts has also been added.

Known issues include problem signing multisig transactions if using a remote host. If using local host, it should be fine. There seems to be some problem with the websocket channel for signing unconfirmed channels but we need to check into it more.