"Note that you don’t need to be the owner of a masternode to see these logs. Most of the masternodes are hosted on cloudhosting services. If a government demands access to these logs, they will probably get it. It’s entirely possible that right now the NSA is spying on the majority of masternodes without the owners even knowing their masternodes are being spied upon."Just one of many grave examples that eliminate from the competition. Good reading (and viewing).
Thanks for everything you guys have shared.
When it sounds too good to be true . . . when it's touted as everyone's nirvana . . .
. . . it's probably pie in the sky.
(Wonder if this quote and opinion/conclusion will get me put on the almighty ignore list. Hey guys, chill a bit. It's only one person's analysis. If your product really is what you say it is, you should welcome comments like this since they give you an opportunity to shine by showing how wrong the analysis is - hopefully with reasonably intelligent arguments as I'd be the first to happily admit I'm wrong if you can objectively refute the scam accusations made against you.)
Sure to get me ignored.
Thank you for posting those crucial links again. That is all MUST READ INFO for noobs as well as existing Dash bagholders.
Here are some more important Dash Facts.
1. Darkcoin had a problematic launch: 2 million Darkcoin were mined in the first day (incidentally, there are around 2 800 Darkcoin emitted daily right now, so that should give some level of contrast). This may not seem to relate to your question, but it is important to establish the legitimacy and technical competency of the developer. The fact that the block reward does not match either of the three block reward formulae published by the developer is worrying. This points to an outright scam at worst, pure incompetence at best.
2. When dealing with a cryptocurrency you need to be able to cryptographically and mathematically prove a particular claim. So in the original Bitcoin whitepaper Satoshi was able to mathematically prove the validity of the longest chain rule. The rest of his cryptographic claims were backed by the papers he quotes (Adam Back's Hashcash paper in particular). Darkcoin has no cryptographic proofs of their claims. This is important, because a cryptocurrency is a manifestation of cryptographic theory, not the other way around. If you try and shoe-horn it the other way around you'll likely find your model unsafe under the most basic of assumptions.
3. The developer seems to eschew well-defined, anti-fragile, and proven Bitcoin concepts (eg. building a model based on paying for services via micropayment channels) for bizarre models that are poorly implemented and fragile (eg. payments based on uptime make a MasterNode a ripe target for DDoS attacks null-routing that IP).
4. I have seen no evidence that InstantX transactions are not susceptible to malleability. This means that it is trivially easy to disrupt every InstantX transaction, and the network will fall back to processing them as "normal" transactions.
5. This malleability approach also allows for easy forking of the network if you own a subset of MasterNodes, whereby your malicious MasterNodes vote for both of your transactions and feed those votes to two groups of miners. The claim made in the InstantX "whitepaper" is that the conflicting messages will "cancel each other out", but once the network is forked that isn't the case, as half the conflicting messages won't even be received by the one part of the forked network. By continuing to run this group of malicious nodes, feeding sets of InstantX transactions that appear to be voted in as valid, you can keep the network split indefinitely.
6. The entire basis for "anonymising" transactions is based on clients being online at a given point in time, which means that those clients are also open to leaking information via temporal association.
7. The developer seems to have a grave lack of understanding when it comes to the danger of incentives. The clearest example of this is this table of MasterNode ROI. As you can clearly see, a MasterNode's ROI is substantially higher when there are fewer MasterNodes. Thus there is clear incentive for a MasterNode operator to systematically attack and destroy other MasterNodes, but not so much that the network ceases to exist. Just enough to double or triple his ROI. Incidentally, this is a self-fulfilling prophecy, as in a hypothetical future where Darkcoin is processing thousands of transactions an hour it will require quite a hefty server to act as a MasterNode. The fewer MasterNodes there are, the more work individual MasterNodes will have to do, which means that those run by non-technical people or on cheap VPS's will be the first to go, eventually leaving a group of big boys with big guns operating the remaining MasterNodes.
8. We've already seen ample evidence of law enforcement turning seemingly anonymous people into informants (eg. Sabu), hacking servers, and infiltrating systems in other ways. It is safe to say that LEA could also outrightly purchase large portions of the MasterNode network. It is impossible to tell which MasterNodes are real and which are owned by LEA (in perpetuity). Unfortunately it appears that the developer's line of reasoning, with respects to "how much" privacy Darkcoin gives you, started with the assumption that a supermajority of the MasterNodes are honest / not being watched / not infiltrated by LEA. This leaves open a huge, gaping hole whereby all of the "mixing" MasterNodes are involved in can be revealed by an owned / compromised majority. I can guarantee that the bulk of all MasterNode operators do not know even the first piece of opsec required to keep from your tin from being tampered with.
9. MasterNodes can be tricked into believing they can no longer accept new connections, simply by filling up all their file descriptors. It is somewhat trivial to force new connections to a group of MasterNodes under your control.
10. The developer has no clue how dangerous and stupid it is to chain hashing algorithms, as you open them up to pre-image attacks among other things. As a security researcher who discovered a flaw in chained hashing algorithms in PHP concluded: "The underlying problem is that combining cryptographic operators that weren't designed to be combined can be disastrous. Is it possible to do so safely? Yes. Is it a good idea to do it? No. This particular case is just one example where combining operations can be exceedingly dangerous. But the bottom line: never roll your own crypto. It can have fatal consequences."