I need some help please.
I am pretty sure i know the answers to most of these, but id like as much feedback as possible. (a lot is answered here - https://electriccoin.co/blog/encrypted-memo-field/)
I am trying to work out extra messenger functionality and the implications of it.
I know some of these suggestions go against what a cryptocurrency is about. I am trying to explore the messenger side. It will probably have to be a sidechain.
as I have said before im working on some messenger stuff.
For me a very important part of hard encrypted messaging is plausible deniability. Something that is lacking from all modern messenger apps that I can find. They have workarounds, but they are not great.
An example of something I consider good, Pidgin + OTR
All of these features are key.
I cannot find a method for Forward secrecy and Deniability (although you could use the security by obscurity angle and say you cant prove i sent the message - although meta data leaks and correlation attacks will probably disagree and prove you are the sender)
If, for example, someone sends me a z2z transaction with “Thanks, please ship to xyz”
As a reciever of a z2z message:
- If I have to give the view key to the tax man will they also get the note? is there anyway I can stop this?
- If I move the funds, does the note ever get expired? (is it only checkpoints and upgrades?)
As a sender:
If I do not trust the receiver I would like to expire the message after a time delay
If I want to send the same message to a few people but not have one view key, i want them to have their own so the messages can expire on read.
the only ways i can see is to be able to do this is to disassociate the privkey but this could cause loss of funds. or to be able to overwrite the note part of the transaction with a subsequent note. (this second option actually gives a lot more usability to messaging.)
- If the network gets compromised are all notes exposable?
- Is the attack surface for this the same as to take over the network?
- What about forks, what is the risk here?
I have a few different approaches to solve this, but none are elegant and most are beyond my coding skill level. my current approach is to have a merge mined messenger only chain, but that has its own issues.
tagging @Shawn and @amiller - Who do I address questions to for the foundation as to future protocol development and if things can be on the roadmap? (like revocation certificates, overwriting old notes with new ones.)
And for those who dont care about the messenger aspect of it, 512bytes is long enough for a Key Exchange Key to set up secure communications devices/channels and solve some of the issues with D-H or PKI. You need the ability to disable the key should the device get compromised.