You've brought some valuable insight here, and while I prefer brevity where possible, you have forced me into a situation where it makes sense to have an additional column for
masternodes which are purely protection based. Please have a look and let me know what you think.
It makes no sense now to have a Masternodes column under Security. Get your head out of the privacy/masternodes box and think of what security means at the software and hardware levels in the real-world where transactions need to be hacker-proof. You use TLS everyday on the web for vulnerable transactions (e.g. https).
Mixing is a privacy feature. Masternodes is just one of many ways to accomplish that. So Masternodes with that feature is but a subset or a type under the mixing category.
Traffic encryption is a security feature. TLS is just one of many way to accomplish that. So TLS is also a subset or a type under the security category.
This is my third time attempting to explain, so if you still don't get it, aargh!
Okay
I'm doing my best to work with you on this. I certainly don't know everything. You bring up a lot of great points but I need to ask that you consider there may be more than one perspective on it.
Mixing: Is it an Anonymity feature or a Privacy feature? There is no perfect answer. If implemented as intended, I have opted for "Anonymous" because the information on the transaction is actually (or is intended to be) Lost to the world, with the exception of the Sender and Receiver (who also have very limited info on it). The information is, ideally, even lost to the network itself, and cannot be retrieved. The theoretical loss of this transactional information....is why I put it as "Anonymous". Now, I understand your perspective that the above explanation may or may not be entirely mathematically sound, and thus you see it more as obfusciation. And you have a point, but it is clearly doing more at a practical level than just putting up a wall that can be taken down with the right credentials.
I will leave mixing as "Anonymous"
for now with consideration to the blur and feedback from others.
Masternodes: Ok, so I will take masternodes out of security because I never entirely liked it there either. It was only there because you insisted it was a form of "protection". The problem with categorizing masternodes is that they can serve more than one purpose, depending on their implementation.
I need to make one thing clear on here though, so there is no confusion: Most masternodes have security as an objective, which is accomplished both by strengthening the network, and by mixing. Zencash/Zclassic are actually perfect examples of this. Their entire networks were both brought down to their knees earlier this year by a replay attack, which could have easily been prevented by the simplest of mixing techniques. I might suggest that the general attitude of "zerocash solves everything" likely led to this security vulnerability. I will say that both communities responded professionally, with updates, and affected investors were compensated for their losses. Thus being listed on Bittrex.
So while I will take masternodes out of the security category, I do so making it clear that this is still a major purpose of most said implementations (although perhaps less relevant to this particular topic).
"Traffic Encryption": That would be a pretty good column....the only problem is that all cryptocurrency has some form of this. I certainly like the TLS approach, to be honest.
-------------------
So, this is a complicated reply. But I need to keep that matrix as simple as possible. So here's what I'll propose:
- We both agree that masternodes don't really belong in Security, even if most implementations do provide that. So that column is gone.
- Mixing to stay as "Anonymous" for now, but I remain open to alternatives and recognise in this thread that this is very debatable.
- TLS, and Traffic Encryption: For now, since all coins have this, I'm not creating a separate column because I want this to be simple, and quite frankly encryption methods aren't that.
I WILL give ZenCash a "Yes" for Masternodes, and describe their implementation as "
TLS Non-Mix".
While I doubt you will be entirely happy with this, I do believe it is at least an improvement on properly describing Zencash's implementation.
Colored green to emphasize that the TLS may be arguably equivalent, and/or better, than true mixing. And Zencash would know, after its replay attack
It's not a perfect solution but it's an honest effort. I know you see it differently, but I guarantee you if I did it exactly like you wanted there would be three times as many offended community members on here from coins that Haven't had replay attacks and have stood the test of time, and I'm not convinced the matrix would be any more accurate.