I have some questions regarding encrypted memo field:
I suppose I can use time-locked transactions as in bitcoin, right?
Can I use a time-lock also for private/shielded transactions?
Is the memo field content of a time-locked private transaction sealed (for recipient and everybody else) until it is actually added to the blockchain (time-lock passed)? Or can the recipient see the memo field content of a pending time-locked private transaction before time-lock is released?
There’s no such thing as time-locked shielded transactions at the moment, but I’ll add that as a potential security property to ticket 344. However, I don’t see how to implement it, since there’s no way for the sender to choose a key that will only be available after expiry of the time lock.
Thank you for your reply that makes it a bit clearer for me. I will follow your progress with issue #344.
Regarding 2/3. Your blog post The Encrypted Memo Field - Electric Coin Company mentions “transaction view keys”. If the transaction view key can only be used by a recipient when a shielded transaction is actually added to the blockchain, and not before when it is pending as a time-locked transaction, then time-delayed memo/secret sharing with the recipient should be possible. I guess I’m still missing something here…(and do not understand how you want to enable time-locked shielded transactions).
Where the blog post refers to a “transaction view key”, it means the ephemeral private key used by the sender to encrypt a note plaintext. The sender could hold onto this and reveal it at a later time, but there would be no mechanism to enforce when they reveal it. So that would not work for most uses of time-lock protocols where the sender is untrusted.
We’re currently focused on specifying and then implementing payment disclosure which will create a blob to decrypt individual payments to shielded addresses. The viewing key has a much larger scope (all transactions sent to shielded address) so implementing payment disclosure is safer to do first because of it’s added granularity. If a blob gets shared by accident, it only affects the transaction involved whereas a accidental sharing or viewing key affects the entire address.
On that note, I had previously done the same by importing the viewing key and running z_listreceivedbyaddress and then manually decoding the memo. One thing I didn’t understand was why the amount field contained a lot of different values. I assumed this was the fee but looking on zcha.in it seems the default fees were used. See this incoming transaction for example: