He had two choices : list the advantages of Monero over DASH/Darkcoin or fud/troll DASH/Darkcoin, seems that the latter is easier to do.
The first option would be off-topic, so thanks for the invitation to discuss the latter.
Let's start with Digitaltrash's trusted 2nd tier, aka PonziNodes or MadoffNodes.
Trusting 3rd parties defeats the point of Satoshi's proof of work breakthrough.
Trusted 3rd parties are a non-starter for anyone who takes security seriously. So is security through obfuscation, but we'll save that lecture for another day.
http://nakamotoinstitute.org/trusted-third-parties/Trusted Third Parties Are Security Holes
Nick Szabo
Originally published in 2001
Commercial security is a matter of solving the practical problems of business relationships such as privacy, integrity, protecting property, or detecting breach of contract. A security hole is any weakness that increases the risk of violating these goals. In this real world view of security, a problem does not dissapear because a designer assumes it away. The invocation or assumption in a security protocol design of a "trusted third party" (TTP) or a "trusted computing base" (TCB) controlled by a third party constitutes the introduction of a security hole into that design.
If the risks and costs of TTP institutional alternatives were not accounted for in the protocol design, the resulting protocol will in most cases be too costly or risky to be practical. If the protocol beats these odds and proves practical, it will only succeed after extensive effort has gone into plugging the TTP security hole(s). TTP assumptions cause most of the costs and risks in a security protocol, and plugging TTP security holes produces the most benefit and profit.
As a result, we propose a security protocol design methodology whereby the most risky and expensive part(s) of a security protocol, the trusted third partie(s), are designed in parallel with security protocol(s) using those parties. The objectives of cost and risk minimization are focused on the TTPs rather than the security protocols themselves, which should be designed to suit the cost and risk minimized TTPs.
[icebreaker notes Digitaltrash's Ponzinodes maximize rather than minimize the cost and risk of TPPs, flagrantly violated Prof. Szabo's instructions.]Many are the reasons why organizations may come to favor costly TTP based security over more efficient and effective security that minimizes the use of TTPs:
Limitations of imagination, effort, knowledge, or time amongst protocol designers it is far easier to design security protocols that rely on TTPs than those that do not (i.e. to fob off the problem rather than solve it). Naturally design costs are an important factor limiting progress towards minimizing TTPs in security protocols. A bigger factor is lack of awareness of the importance of the problem among many security architects, especially the corporate architects who draft Internet and wireless security standards.
The temptation to claim the "high ground" as a TTP of choice are great.
The ambition to become the next Visa or Verisign is a power trip that's hard to refuse. The barriers to actually building a successful TTP business are, however, often severe the startup costs are substantial, ongoing costs remain high, liability risks are great, and unless there is a substantial "first mover" advantage barriers to entry for competitors are few.
[icebreaker notes Digitaltrash's lack of first mover advantage and the presence of numerous TTP-free competitors]
Personal Property Has Not and Should Not Depend On TTPs For most of human history the dominant form of property has been personal property. The functionality of personal property has not under normal conditions ever depended on trusted third parties. Security properties of simple goods could be verified at sale or first use, and there was no need for continued interaction with the manufacturer or other third parties (other than on occasion repair personel after exceptional use and on a voluntary and temporary basis). Property rights for many kinds of chattel (portable property) were only minimally dependent on third parties the only problem where TTPs were neededwas to defend against the depredations of other third parties. The main security property of personal chattel was often not other TTPs as protectors but rather its portability and intimacy.
Here are some examples of the ubiquity of personal property in which there was a reality or at least a strong desire on the part of owners to be free of dependence on TTPs for functionality or security:
- Jewelry (far more often used for money in traditional cultures than coins, e.g. Northern Europe up to 1000 AD, and worn on the body for better property protection as well as decoration)
- Automobiles operated by and house doors opened by personal keys.
- Personal computers in the original visions of many personal computing pioneers (e.g. many members of the Homebrew Computer Club), the PC was intended as personal property the owner would have total control (and understanding) of the software running on the PC, including the ability to copy bits on the PC at will. Software complexity, Internet connectivity, and unresolved incentive mismatches between software publishers and users (PC owners) have substantially eroded the reality of the personal computer as personal property.
This desire is instinctive and remains today. It manifests in consumer resistance when they discover unexpected dependence on and vulnerability to third parties in the devices they use. Suggestions that the functionality of personal property be dependent on third parties, even agreed to ones under strict conditions such as creditors until a chattel loan is paid off (a smart lien) are met with strong resistance.
A good digital security protocol designer is not only an expert in computer science and cryptography, but also very knowledgeable about the traditional costly techniques of physical security, auditing, law, and the business relationships to be secured. This knowledge is not used to substitute these costly security methods for more cost effective digital security, but in order to minimize hidden dependence on costly methods for the real security. A good protocol designer also designs, rather than merely assumes, TTPs that work with minimal use of costly techniques
[icebreaker notes Digitaltrash's trusted 2nd tier maximizes vulnerability to all manner of physical security/auditing/legal/business costs. Have fun reporting every duff that passes through your Ponzi node to the IRS after correctly calculating your cost basis/profit/tax liablity.]Alan Karp, Mark Miller, and others have observed the confusion over words like "trust" and "trusted" as used in the security community, and proposed replacing the verb "trusts" with "is vulnerable to". This substitution is a great way to radically clarify security protocol designs. "Trusted third party" as used in this essay becomes "vulnerable to a third party", and the point of this paper, that this is a security hole, becomes obvious.
Conclusion
Traditional security is costly and risky. Digital security when designed well diminishes dramatically in cost over time. When a protocol designer invokes or assumes a TTP, (s)he is creating the need for a novel organization to try to solve an unsolved security problem via traditional security and control methods. Especially in a digital context these methods require continuing high expenditures by the TTP and the TTP creates a bottleneck which imposes continuing high costs and risks on the end user.
A far better methodology is to work starting from TTPs that either well known, or easy to characterize, and of minimal cost. The best "TTP" of all is one that does not exist, but the necessity for which has been eliminated by the protocol design, or which has been automated and distributed amongst the parties to a protocol. 