Encrypted message Warning: message cannot be decoded!

Tech Support
#1

Using NCC and NIS 0.6.79 I sent an encrypted message from NATKZH-OJROEA-MXZ3J4-AKZ5ET-IW5XWS-J7IZJW-ANTW to NDPH5N-FWDS67-JC5XYY-IW4ILD-GCTBAD-R3DMJ6-MLOX in a transaction with hash eee2a63d3ab6b0649bd57a7e83ea4f727bae8ab7cd6ea4b0029f797de3d4635b in block 762089.
After having sent the message I could see, read and verify the decrypted message in NCC.

Today, using NCC and NIS 0.6.82 I can still see the outgoing transaction in the sending account, but I can no longer see or read the decrypted message. Instead I get the text “Warning: message cannot be decoded!”.

Is this a problem of the new version not being reverse compatible or is this a bug?

#2

is the destination account inside your wallet?
as it seems to me public key of that account is unknown for the network…
if it’s unknown for the network and you don’t have it in the wallet you won’t be able to decode it

#3

That’s a correct analysis gimer.

I suppose the public key of the destination account is unknown because it did not sign an outgoing transaction yet…

Based on your remarks, I decided to do some tests. I created another wallet and imported both sender and destination accounts (it is an account i created myself and I had a backup of the private key!) and indeed then I can read the decrypted message again in the wallet with the two accounts.

I suppose once the destination has an outgoing transaction, it will have signed a transaction with its private key and then its public key will be known to the network. Once that condition is fulfilled, the message will be decrypted correctly in the sender’s wallet without the destination account being present in the same wallet.

So I did that test as well: I sent some xem to the destination account and returned som xem to the sender to create that outgoing transaction. Than I removed the destination account from the wallet, closed it and opened the sender’s wallet again and … The message was correctly decrypted.

I suppose it is useful to have this scenario documented here, in case somebody would encounter the same story.

Interesting stuff indeed, keep up the good work :wink: