OK I went to get some sleep, now I'm back, somewhat refreshed.
Morning:)
I think you describe an unlikely set of circumstances that would only play out well into the future of DRK, with features on the roadmap to mitigate such issues. OK this isn't a great argument against having an exploitable architecture, but it's a reasonable point since Evan proposes masternode blinding to counter your described risks - perhaps you could comment on this.
MasterNode blinding will mean you won't know which MasterNode was involved in a transaction, not that you won't know what he MasterNodes are. Evan has already indicated that his penchant is for
MasterNode operators to not be anonymous, and for their IP addresses to be known, under the auspice of it being necessary to make things "fast and robust".
Since this is an XMR vs DRK thread, does XMR not suffer from similar issues today thanks to centralised trusted web wallets?
I'm not sure I understand the question - there's only one web wallet for Monero right now, I'm not sure what the incentive would be for it to attack itself? I'm talking about a game theoretic prisoner's dilemma that exists with highly incentivised MasterNodes. Expressed theoretically: the only ways I can see for the MasterNode structure to achieve Nash equilibrium is to either lower the payout to such a point where any hope of ROI is measured in decades (thus the primary incentive to run a MasterNode is to own a long-term asset and assist the network, not to earn profit)
or to have the MN reward decrease if the number of MNs drops below a certain magic threshold (this latter approach suffers from various drawbacks I can think of off the top of my head, but it's at least an attempt).
Also, I have to bring up the mining share issue again. It's surely way easier for 'the man' or whoever else to subvert BTC (and DRK, XMR) by controlling the major mining pools? They only have to 'get to' the guys (or servers) that control (or host) 3 or 4 major pools to mount a 51% attack. OK so DRK faces both issues and has a larger attack surface, but that's not really the point. You seem to be arguing against DRK because it has an attack surface at all, when other POW coins do too.
It depends on the end-game. If it's LEA TLAs, then owning all of the mining pools for BTC or XMR or DRK will let them influence consensus, but they can't change the consensus rules without the rest of the full nodes rejecting their transactions blocks. Gaming MasterNodes, however, lets them deanonymise transactions. For my game theoretic prisoner's dilemma hypothesis there's no value to someone attacking a pool unless they can earn from its demise. Thus mining pools have some incentive to attack each other (and it's entirely possible that the massive and organised anti-ghash.io stuff on Reddit a few months back was spearheaded by a competitor, who knows). There are some good studies into this eventuality for Bitcoin (applies to DRK and XMR too) -
When Bitcoin Mining Pools Run Dry and
The Miner's Dilemma.
The way we combat this in Monero is through a feature we're
slowly working on called Smart Mining. This will be enabled by default when you go through the first-launch process in the various full-node GUI wallets, and also available via command-line flag within the Monero daemon. It's a little like Folding@Home used to be, in that it automatically mines to the dev donation address or to your address (up to a configurable CPU threshold, and/or on reduced cores if you have AES-NI support) when your computer is not on battery power and not in use. Because the Monero Proof of Work algorithm closes the performance gap between CPU, GPU, and ASIC mining, this means that we would only need a relatively small percentage of the (eventual) userbase to leave this enabled in order to ensure mining pools don't own the majority of the network.
There is some contradiction in your idea of a 'perfectly stable version which is trivially exploitable', although I appreciate your point. I wouldn't expect the spork to exist in its present form once there are hundreds of thousands of people reliant on Instant X. Evan has made it clear that he aims for a trustless release model, but has certain features in the early releases to aid rapid development. Your argument around broken changes could be made in favour of the spork, imo, but again I appreciate your point. I think in this case one has to judge Evan on delivery, which has been consistent, and his real world use of the spork, which has been sensible. Also I would say that at this point in cryptocurrency evolution the harsh reality is that any lead dev can pretty much break their coin if they want to, or get it broken through malpractice.
I agree with that last sentence of yours in part. However, I think there's a marked difference between us deciding to ship malicious code (for example), as that would get spotted and people would simply not upgrade to that version, vs. a key that, when broadcast, can actively degrade the functionality of the network (and thus ripe to be stolen by an attacker, or used when the developer gets pissy that the community disagrees with his autocratic decision).
If you want a practical example of the difference: when thankful_for_today, who created and launched Monero, wanted to add merged-mining with all the CryptoNote scamcoins at the time, he got a lot of pushback from the community. So he created a voting system where miners would tag each block with their vote and we'd tally it up. Except that he set the default to not be an abstain, but a vote for what he wanted. Even after changing the default to an abstain and the votes being tallied against him he still went ahead and started
shoving the merged-mining stuff in. The community rejected this autocratic approach, and we forked the project out from before the merged-mining stuff, and the Monero Core team was born out of that.
I can't help but wonder how that would've gone down if he'd had a remote trigger he could've used to regress functionality.
