So in other words, you've finally come to the same conclusion I've already expressed: everything hinges on the opsec of the MasterNode operators.
Nope, not at all....we went over all that.
It's the 'hardness' of the MN code that's important. How remotely exploitable it is, I would say.
edit: OK, giving this more consideration...remote exploitability of a given MN does have dependencies on Opsec. Let's assume what I think is fair to assume, that basic Opsec is in place similar to what we might expect on the BTC network....i.e MNs are at least behind a firewall and only listening on TCP/9999
Now you're getting it:)
The key difference there is that compromising a BTC node has no real knock-on effect for the network overall.
That question I asked yesterday appears to have gone unanswered, so I'll answer it: the number of honest BTC nodes any given BTC node needs to be connected to is 1. It can have 20 malicious peers all working together to lie to it and only 1 honest peer, and it will be able to determine which is the honest peer. The only way to truly disrupt its connection to the BTC network is to completely blackhole it.
In my opinion that has to be the baseline for comparison when designing a decentralised architecture. Without getting into a big discussion of decentralised vs. distributed architecture, this is the end-goal when you don't encourage decentralisation: http://www.newyorker.com/tech/elements/the-mission-to-decentralize-the-internet
So given the probabilities I listed above, how many DS nodes do we need to compromise, or make 'dishonest' to disrupt the MN network and break privacy? Enough to render the opsec issue negligible it seems.
Yes, I think a distributed vs decentralised debate could be had.
And a 'theoretically best design' debate.
But perhaps more importantly, a 'fit-for-purpose' debate.
