Quote from: fluffypony on October 29, 2015, 11:25:02 PM

Quote from: salmion on October 29, 2015, 10:43:37 PM

We wouldn't if you didn't sometimes come across like such a Doos. Ek speel maar net.

lol, net 'n grappie, ne?

Quote from: salmion on October 29, 2015, 10:43:37 PM

That said what would be the benefit of Evan putting malicious code into his project? Or anyone else from the dev team? Also as they can be rolled back by other members of the team any such theoretical attack from within could hopefully be negated?

Speaking purely hypothetically? The benefit would be when he's cashing out and he needs one-last-pump.

Quote from: the-baker on October 29, 2015, 10:49:39 PM

BTW: the effects of the backdoor can be observed in both cases when it is used, and not any earlier. So there is really no difference in that regard. The forking is of course possible, but that is easily observable, too, or am I missing something?

Well, imagine he obfuscates the code such that it only activates on a successful deactivation of an existing spork. Then it lies dormant until he reaches out and touches every node with His Noodly Appendage.

Quote from: Macrochip on October 29, 2015, 10:56:43 PM

Wrong.

The spork is merely a secondary lever, not a magical "activate terrible code"-button. A malicious Monero developer for example could implement "underhanded code" into your official GUI-wallet release (you know, in 2045 or so when it's finished) with the simple instruction of having it activate when certain conditions are met, like a date, a block height, a difficulty level, even a certain transaction amount or a combination of any of these conditions. Heck, for all I care he could program his own spork as underhanded code into your release and create the same exact scenario you just tried to reduce onto DASH.

As you can see, your central argument has been easily refuted, making Dash just as vulnerable to that method as any other crypto. Not more, as you tried to construct. Nice try though.

The majority of those conditions (dates, block heights, difficulty levels, transaction amounts) would be easily visible even in heavily obfuscated code. Furthermore, activating at any of those junctures may be sub-optimal for our hypothetical malicious dev's needs. Being able to trigger at point-in-time is incredibly, incredibly powerful (in the negative sense).

Anyhow, this has been an interesting conversation, and I've appreciated the more mature responses from toknormal et al., but I think it's best to shake virtual hands and move on. Cheers:)

I'd like to thank you for your intelligent discussion and lack of trolliness. Those of us who believe in the future of Dash would be wise to remember that many of our most important features have come from Evan reading well-written critiques and making the necessary changes.

I'd like to ask a couple of questions of you:

a) Your point on obfuscated code is well-taken. I do understand the power of a "trigger" like the spork command and how the ability to perfectly time a hypothetical attack could be extremely useful. However, what prevents any cryptocurrency developer from putting secret/obfuscated spork-like code in their software? Couldn't Monero devs theoretically put a trigger command in their code and then hide it really well? Then when a dev sends a certain message the the network, the code would activate?

b) I know there have been crypto devs that have been caught with "secret" superblocks built into their currency. What is to prevent Monero from doing such a thing, only more cleverly? I realize that it would be harder to hide, but could it not be done?

c) I would like to point out that Dash underwent a security audit last year, and while much has changed since then, I feel certain that Kristov would have looked at the spork code. Though he is human and could have missed something, shouldn't that give a little extra reassurance versus a currency that has never been security-audited by a third party?

d) All software is a risk--many of us have been following the story of how Symantec managed to lose control of thousands of security certificates to employees who may have either been overzealous testers, or who may have been outright rogues. When we run any software, don't we accept those risks? Isn't an open source project like Dash significantly less risky than a closed source project like Windows?

e) Once the rapid development phase winds down, Evan will remove the spork and that risk will go away. If for some reason he was to refuse to remove the spork after rapid development, the project could be forked away from his control.

Frankly, I feel like a psychic. The instamine issue is just too unimportant for anyone to give a shit about. I had a feeling that the next "point of criticism" was going to be the spork code. Let's look at the history of criticism against Dash (I won't say trolling, because your posts very distinctly rise above that level):

1) Criticism: Darksend is based on CoinJoin, which has been shown to be weak.
*Corrective Action: Darksend has been improved drastically over the last year, with issues such as "dead change" resolved to everybody's satisfaction. Darksend has been security audited by Kristov Atlas and passed.

2) Criticism: Dash's masternodes are centralized.
*Corrective Action: The number of masternodes has increased from 600 to 3300; even a wealthy man like Otoh can't afford anything close to a majority of them.

3) Criticism: Evan runs a reference node to equalize masternode payment across the network. This is centralization.
*Corrective Action: The reference node was removed in v12. This really sent the trolls into a tailspin.

4) Criticism: Dash is instamined.
*Corrective Action: Evan has been very open and honest about those first few days, and the situation has been thoroughly explained. Honestly, most people don't really give a shit. All corporations endow their creators with equity, so if Evan got a few extra coins in the beginning, so much the better. The more Dash he holds, the greater his incentive to make his Dash move valuable by furthering development.

5) Criticism: The spork creates centralization risk.
*Corrective Action: A clear explanation of the what the spork does and does not do; an intelligent discussion about the risks inherent in any software, and how open-sourcing and security-auditing helps mitigate those risks.

The great thing is that every time critics bring up a problem, it gets fixed. Our critics in many ways are our greatest strength.

My wife really hates a particular store here in town. I kind of do too, although not quite as vehemently as she does. Let's say that she sees that store is doing something wrong, and so she complains about it. That's the worst possible thing she can do, if she wants this store to "suffer" in the long run. Why? Because by pointing out an organization's weaknesses, you give it a chance to improve itself.

For any true trolls out there who really want to see Dash fail, you should know that your constant discussion of Dash's weaknesses ultimately only strengthens the project.