Jeff found an issue on encrypted messaging, it works but can’t be decoded by recipient.
Bug is fixed in v1.0.6
2 Likes
jabo38 and Quantum_Mechanics,
I have a solution for the issue of importing an account with active remote harvesting. The solution should be included in Nano Wallet.
I’ll try to describe and document the solution. After that, I’ll come back to you. Now, I’m busy preparing some blockchain presentations and demo’s 
garrp
Hi garp, thanks for your interest
Cool 
Let us know when you can
Hi Garp, would love to hear about it.
Version 1.0.10
- Fix simple signature changes in edit multisignature contracts.
- Fix decryption of message for sender.
- Fix autodetection of remote account status (locked or unlocked) on harvesting node change.
- Better validation in namespace and mosaic modules.
- Add extra information about operations
- Minor design
What to do when importing an Account with Remote Harvesting active?
A user needs to create transactions to activate or deactivate remote harvesting. Therefore, all information about remote harvesting can be found in the transactions of the account on the blockchain. During the import process, these transactions can be retrieved from a NIS using the documented NIS API’s calls. By doing this, the client (NCC or nanowallet or any other client) can gather the information about the remote harvesting account in order to set the correct configuration of the imported account.
-
When importing an account, the user needs to provide the account address.
Get the info of the account to import, using the API call (this call is probably already used I suppose)
/account/get?address=…
Check If the response includes the following in the “meta” field: remoteStatus: “ACTIVE”
-
If remoteStatus: "ACTIVE" is present, then retrieve all outgoing transactions for the account using the API call documented in [http://bob.nem.ninja/docs/#requesting-transaction-data-for-an-account](http://bob.nem.ninja/docs/#requesting-transaction-data-for-an-account):
a. Call /account/transfers/outgoing?address=…
b. As long as 25 transactions are returned, call the same function with an additional parameter:
/account/transfers/outgoing?address=… &id=…
with the transcation id of the last returned transaction as id
c. Once all outging transactions are retrieved, they can be processed. Consider only transactions with TransactionType 2049 (ImportanceTransferTransaction) and Mode=” Activate”.
d. The last transaction, based on the timestamp of the transaction, that corresponds to the criteria above will contain the public key of last activated remoteAccount.
If I’m right, this should work for the nanowallet, it works for me
1 Like
Hi,
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
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
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
3 Likes
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
any news from nanowaller\t???
Version 1.1.0 coming soon
2 Likes