So obviously you want to double your ROI, which means you have to take half of the MasterNodes out of commission. You don't want to take down all or even most of them, you just want the total number of MasterNodes reduces to 1000. So you do this through a variety of tactics:
1. Report US-based and/or US-owned MasterNodes to FinCEN, the FBI, and the SEC, assist them in shutting them down and seizing the coins held by their operators.
2. Repeatedly DDoS MasterNodes at a particular ISP datacenter until they change their ToS to not allow MasterNodes.
3. Hack into a portion of the remaining MasterNodes and install
a rootkit that watches for Darkcoin source code and modifies it when compiled (or just randomly crashes the daemon if they aren't compiling it themselves). This ensures that these daemons appear to be working to the operator, but they receive so few payments they may as well be offline.
This is all very surreptitious, because 1. looks like The Man has got it in for Darkcoin, 2. looks like the ISP is just being problematic, and 3. is mostly undetectable. You can keep doing this ad infinitum to keep half the MasterNodes offline, and nobody will realise what you're doing. It'll look like the sort of attacks the community expects to come, and they'll rationalise it for you by loudly claiming that 1000 MasterNodes is good enough.
At that stage, since you're earning so much you can begin to collude with a handful of other MasterNode holders to start attacking small blocks of the remaining 1000 MasterNodes, replacing them with nodes you control, so the number of MasterNodes doesn't drop below 1000. You can even setup sockpuppet accounts right now in preparation for this, so that there appears to be legitimacy to the ownership. Within a few years the entire MasterNode network can be controlled by a handful of operators who are profiteering from it. You can then relax on the beach whilst your paid staff reinforce propaganda that running a MasterNode is difficult and expensive, discouraging and attacking any new MN operators.
I'm not saying this is definitely how things will play out, but this is what I perceive will happen because of the balance of incentives.
OK I went to get some sleep, now I'm back, somewhat refreshed.
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.
Since this is an XMR vs DRK thread, does XMR not suffer from similar issues today thanks to centralised trusted web wallets?
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. What if the previous stable version is trivially exploitable, and the sporked code prevented that exploit? Or alternatively, what if the spork is on some key piece of functionality, and disabling it kills InstantX globally during a time when hundreds of thousands of people around the globe are reliant on it? I also think it encourages a "we test in production" attitude. Now, frankly, I am quite fond of the "release early, release often" strategy, also known as the "fail fast, fail often" approach, but only as respects general software projects. For a decentralised, trustless cryptocurrency where a broken change can literally cost user's privacy and money I think a LOT more care and consideration needs to be applied to changes, and they have to be thoroughly tested.
On Monero we have
extremely thorough test coverage, and yet still there are subsystems like RPC that have no unit tests at all! Test-driven development is hard to enforce, but our coverage is increasing over time. This is the didactic opposite of "just writing code" with the barest functional testing and then hoping it'll work in production.
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.
