XMR vs DRK

[fluffypony]

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.

[1714506302]

1714506302

[1714506302]

1714506302

[1714506302]

1714506302

[1714506302]

1714506302

[Johnny Mnemonic]

Also, isn't the major uncertainty in XMR the fact that Zerocash is better?

1) As fluffypony already pointed out, Zerocash will most likely be better, when the tech is eventually polished. I doubt that will happen for quite a while.

2) Before that happens, we (cryptocurrency pioneers in general) have a responsibility to pave the landscape and make crypto accessible and approachable to common people. This means coming up with better ways of obtaining crypto with fiat (even coinbase is a huge pain in the ass), as well as products and services that will make people actually want to trade with it.

If we do our job correctly and create a world where crypto is ubiquitous and fiat exchange gates are non-existent, adoption of superior technologies (like Zerocash) can wash over the world like a tidal wave. At that point I wouldn't expect any single currency to have a very long lifespan, as improved, more appropriate technologies will always be emerging and entering the market.

[majamina]

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".

but with blinding there is no point in taking over the nodes because you can't spy on the transactions? what is the incentive?

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?

The conversation is about the status quo of each coin and vulnerabilities. You are critical of the DRK masternode network for various reasons. Surely a trusted, centralised wallet where everyone manages their funds is a vulnerability?

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.

This is interesting, thanks, nice to know you are working on a solution to the mining share issue. I, and others invested in DRK hope that Evan does the same.

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).

Fair points.

I suppose it comes down to an opinion on risks vs benefits of the temporary spork features. You guys hammer it as a risk, others support it as a benefit, including me presently....but I'm open-minded....

[Macno]

@majamina:

Just wanted to thank you for keeping the debate alive and "representing" the Dash case so well!
Also thanks to all the civilized XMR people!
It`s an interesting debate!

[megges]

but with blinding there is no point in taking over the nodes because you can't spy on the transactions? what is the incentive?

if i understand masternode blinding right, its more to protect IPs from darksend clients, so if you make a darksend it will be relayed trough the masternodes, and so the masternode couldn't tell which ip originally has participated.

So if you get access to the MN you can still spy the transactions.

at least thats how i understand it

[megges]

I must admit i have not read that wall of text.
And im not a math guru, but just by reading the following i have big questionmarks over my head. Perhaps someone can enlighten me.

the following text in the monero whitepaper:
"to succed in the attack, an event whose probability is considered to be neglible" - sry like said im not a math guru, perhaps im wrong, but how could that be something valid proven. dunno if it was you or smooth but someone of you moneroguys liked to say over and over again that the anonymity of darksend has not been proven.
But isn't that exactly the same like if calculations for example say that to deanomyze a darksend transaction the probability is 0.00000000x if you don't own x or all masternodes. So its probability of this is neglible also and so its proven as anonym?!

Cryptographic negligibility has a very specific meaning. Something like a one-way hash function can still be attacked (ie. the original value corresponding to the hashed value can be determined), but it would typically take more power than in the universe to brute-force it. We normally state negligibility on the basis of a computationally bounded adversary, that is to say an adversary who has access to a reasonable amount of processing power regardless of the cost or speciality of the equipment required.

Put more simply: if there is a 0.000000001 chance of deanonymising a transaction that is only around 2^-30. Comparatively, you have a 2^-256 chance of brute-forcing a single Monero output in a single transaction. 2^-30 is not computationally hard, would you trust a site storing your passwords with a 30-bit hash?

To make matters worse: as we get closer to more practical quantum computing we have to consider the effect they will have on cryptography. Anything that depends on discrete logarithm hardness (eg. RSA) is dead in the water, but symmetric encryption and hash resistance will only be weakened, not completely ground up. For symmetric encryption it's "double the speed", so searching through a 2²⁵⁶ keyspace could be done by a quantum computer in 2¹²⁸ time, so symmetric encryption strength would halve. For one-way hash functions (which cryptocurrencies are deeply reliant on) there's a similar speed up for hash preimage attacks (from 2ⁿ -> 2^n/2) and collision resistance (from 2^n/2 -> 2^n/3). So basically take your "possibility of success" and halve it.

thanks for that explanation.

[majamina]

@majamina:

Just wanted to thank you for keeping the debate alive and "representing" the Dash case so well!
Also thanks to all the civilized XMR people!
It`s an interesting debate!

edit: whoops quoted wrong post!

thanks....it would be nice if all the trolls and fanboys could fall back and we just talk about the issues constructively...unfortunately there's money at stake, and money talks

i know i've been a bit angry/provocative in a few posts, but will leave that behind now to concentrate on reasonable discussion.

[TrueCryptonaire]

The most important thing for a coin is a network-effect. Tech should work but it is kind of secondary. you can have a brilliant tech but without users it is pretty much worthless.
We have seen that many coins that are more sophisticated (for instance, worldcoin and other of those fast coins) than bitcoin have not been able to compete with btc because bitcoin has by far the largest userbase.
Bullish trendline helps creating the network effect.
On the other hand, if the trendline is too bullish, it might also distract some users who feel it is going to bubble. I am afraid Darkcoin has too high speed in rising. Look at Monero, it is rising much more steadily and it feels therefore it actually can last for years.
There is one altcoin that has also very slow rising trend and it very rarely dumps big time (Unobtanium). Sure the community is small but they are able to keep the coin price in bullish channel due to not pumping it too fast.
On the other hand, Monero is by no means not expensive coin - it is actually a bargain at this moment. Marketcap is only ~ 5 million usd and it is slowly rising (I remember it was close to 1.5-2 million usd at some point).

My advice for DRK holders is to diversify. Do not hold all eggs in the same basket. There are tons of risk factors in Dark (also Monero has risks). Be prudent and diversify. We welcome all the new guys from Dark Community to pariticipate Monero's community. Do it before it is too late and the dumping start - be smart.  

[fluffypony]

but with blinding there is no point in taking over the nodes because you can't spy on the transactions? what is the incentive?

There is - blinding just changes the weight of the MN network you need to monitor. You don't need to be able to observe the entire MN network, just enough of it that extrapolation is possible. This is somewhat similar to the cascading privacy failure described in MRL-0001 - since you've got an ongoing observance of transactions going through the MasterNodes you control you will be able to infer more and more information. The attack MRL-0001 describes is a little different, as it requires sufficient control over outputs (there are currently 12.44 million mixable outputs on the Monero blockchain) vs. sufficient control of ~2000 MasterNodes, but the principle of it cascading forward is the same.

The conversation is about the status quo of each coin and vulnerabilities. You are critical of the DRK masternode network for various reasons. Surely a trusted, centralised wallet where everyone manages their funds is a vulnerability?

MyMonero is only used by a portion of users. The majority of the users will use Monero Core or one of the alternative wallets: https://getmonero.org/getting-started/choose

Forgive me, but I'm still not fully understanding the thread model you're trying to describe. If an attacker took MyMonero offline all the users would still be able to import their MyMonero wallets into simplewallet just be restoring it from their seed (this is recent functionality not merged into master until we've cleaned it up, but the interoperability is there and could be finalised and merged in a couple of hours if MyMonero disappeared). If an attacker compromised MyMonero they could serve up malformed JavaScript to compromise all of the users, but they'd only be able to game a portion of the network. As more clients are created and released for Monero (eg. other web-based alternatives to MyMonero, other GUI clients besides MoneroX / lightWallet / MoneroQT, service-centric clients such as rpcwallet and so on) the risk reduces.

[majamina]

There is - blinding just changes the weight of the MN network you need to monitor. You don't need to be able to observe the entire MN network, just enough of it that extrapolation is possible. This is somewhat similar to the cascading privacy failure described in MRL-0001 - since you've got an ongoing observance of transactions going through the MasterNodes you control you will be able to infer more and more information. The attack MRL-0001 describes is a little different, as it requires sufficient control over outputs (there are currently 12.44 million mixable outputs on the Monero blockchain) vs. sufficient control of ~2000 MasterNodes, but the principle of it cascading forward is the same.

OK, people have been saying you'd need to control the entire network with blinding in place, or at least an unrealistic portion.

what weighting do you think is realistic to perform extrapolation and gain sufficient control?

Forgive me, but I'm still not fully understanding the thread model you're trying to describe. If an attacker took MyMonero offline all the users would still be able to import their MyMonero wallets into simplewallet just be restoring it from their seed (this is recent functionality not merged into master until we've cleaned it up, but the interoperability is there and could be finalised and merged in a couple of hours if MyMonero disappeared). If an attacker compromised MyMonero they could serve up malformed JavaScript to compromise all of the users, but they'd only be able to game a portion of the network. As more clients are created and released for Monero (eg. other web-based alternatives to MyMonero, other GUI clients besides MoneroX / lightWallet / MoneroQT, service-centric clients such as rpcwallet and so on) the risk reduces.

OK, well we are frequently hearing 'no GUI wallet for XMR is no problem because we have mymonero' yet this is centralised and subject to attack. That's all really, and if this is a temporary issue then fair enough.

[fluffypony]

OK, people have been saying you'd need to control the entire network with blinding in place, or at least an unrealistic portion.

what weighting do you think is realistic to perform extrapolation and gain sufficient control?

Unfortunately it's hard to quantify without a mathematical expression of the model, especially without a great deal of familiarity with the inner-workings of the system at present. It also stands to reason that the level of analysis required to properly document and model the system would require a very motivated (money, inclination, whatever) cryptographer, which I am not (as in not really a cryptographer, nor particularly inclined:) )

OK, well we are frequently hearing 'no GUI wallet for XMR is no problem because we have mymonero' yet this is centralised and subject to attack. That's all really, and if this is a temporary issue then fair enough.

Oh I totally get it now! Sure, as a stop-gap solution it presents a risk to a motivated attacker. To be honest, and this is not to be overly pragmatic, we haven't even implemented the changes recommended in MRL-0004 yet, so Monero isn't yet at a level where I would feel comfortable recommending it to someone who transactional privacy is a life-or-death scenario. Once we've implemented the MRL4 changes, and have our hybrid i2p/ip layer running, that will decrease the remaining risk areas (as we see them) to "negligible" levels. Although security and privacy is an ongoing process, so we're never going to stop researching and theorising attacks against Monero, and doing what is necessary to protect our users.

At some stage, when I get the time for it, I'm going to build a very aggressive and malicious Monero testnet node (ala Chaos Monkey), and permanently run an army of them on testnet, to force us to build more anti-fragility into Monero.

[BlockaFett]

OK, people have been saying you'd need to control the entire network with blinding in place, or at least an unrealistic portion.

what weighting do you think is realistic to perform extrapolation and gain sufficient control?

Unfortunately it's hard to quantify without a mathematical expression of the model, especially without a great deal of familiarity with the inner-workings of the system at present. It also stands to reason that the level of analysis required to properly document and model the system would require a very motivated (money, inclination, whatever) cryptographer, which I am not (as in not really a cryptographer, nor particularly inclined:) )

OK, well we are frequently hearing 'no GUI wallet for XMR is no problem because we have mymonero' yet this is centralised and subject to attack. That's all really, and if this is a temporary issue then fair enough.

Oh I totally get it now! Sure, as a stop-gap solution it presents a risk to a motivated attacker. To be honest, and this is not to be overly pragmatic, we haven't even implemented the changes recommended in MRL-0004 yet, so Monero isn't yet at a level where I would feel comfortable recommending it to someone who transactional privacy is a life-or-death scenario. Once we've implemented the MRL4 changes, and have our hybrid i2p/ip layer running, that will decrease the remaining risk areas (as we see them) to "negligible" levels. Although security and privacy is an ongoing process, so we're never going to stop researching and theorising attacks against Monero, and doing what is necessary to protect our users.

At some stage, when I get the time for it, I'm going to build a very aggressive and malicious Monero testnet node (ala Chaos Monkey), and permanently run an army of them on testnet, to force us to build more anti-fragility into Monero.

"Unfortunately it's hard to quantify without a mathematical expression of the model, especially without a great deal of familiarity with the inner-workings of the system at present"

So that' s a flowery way of saying you have no idea because you don't know how DRK works LOL.

Q: Why don't you write in plain English

A: Monero investors like to be baffled with BS like this before being puckered into the Polo trollbox and subsequent XMR buy

[majamina]

OK, people have been saying you'd need to control the entire network with blinding in place, or at least an unrealistic portion.

what weighting do you think is realistic to perform extrapolation and gain sufficient control?

Unfortunately it's hard to quantify without a mathematical expression of the model, especially without a great deal of familiarity with the inner-workings of the system at present. It also stands to reason that the level of analysis required to properly document and model the system would require a very motivated (money, inclination, whatever) cryptographer, which I am not (as in not really a cryptographer, nor particularly inclined:) )

OK, well we are frequently hearing 'no GUI wallet for XMR is no problem because we have mymonero' yet this is centralised and subject to attack. That's all really, and if this is a temporary issue then fair enough.

Oh I totally get it now! Sure, as a stop-gap solution it presents a risk to a motivated attacker. To be honest, and this is not to be overly pragmatic, we haven't even implemented the changes recommended in MRL-0004 yet, so Monero isn't yet at a level where I would feel comfortable recommending it to someone who transactional privacy is a life-or-death scenario. Once we've implemented the MRL4 changes, and have our hybrid i2p/ip layer running, that will decrease the remaining risk areas (as we see them) to "negligible" levels. Although security and privacy is an ongoing process, so we're never going to stop researching and theorising attacks against Monero, and doing what is necessary to protect our users.

At some stage, when I get the time for it, I'm going to build a very aggressive and malicious Monero testnet node (ala Chaos Monkey), and permanently run an army of them on testnet, to force us to build more anti-fragility into Monero.

Interesting responses, thank you.

It seems with XMR you are striving to build a super-robust anon coin, prioritising quality over time-to-market. Is that fair?

Meanwhile DRK seems to be focused on rapid development and implementation of headline-grabbing features with real-world utility. The privacy/anon falls short of XMR, but is it good enough? The masternode network presents an interesting attack surface, but are the security measures adequate versus realistic attacks?

Essentially, is DRK fit-for-purpose?

It's great if you can make a better coin, but if DRK gets over the line for the majority of real-world use-cases and gets to market first....know what I mean?

[othe]

Meanwhile DRK seems to be focused on rapid development and implementation of headline-grabbing features with real-world utility. The privacy/anon falls short of XMR, but is it good enough? The masternode network presents an interesting attack surface, but are the security measures adequate versus realistic attacks?

Can you send from a mobile phone with darksend? If not it's useless (the answer is: no). Meanwhile you can do that with Monero already.

So what are those real-world utility features?

[majamina]

So what are those real-world utility features?

i guess if we're talking 'right-now' utility, then the off-chain anon....some markets are accepting DRK and you can use Darksend to mix coins for whatever purpose.

instant transactions are working but need merchant adoption...depends how you define 'real-world' utility on that one. Instant TX obviously has plenty of utility, once adopted.

how do you see the features of DRK & XMR stacking up over time?

[TrueCryptonaire]

OK, people have been saying you'd need to control the entire network with blinding in place, or at least an unrealistic portion.

what weighting do you think is realistic to perform extrapolation and gain sufficient control?

Unfortunately......

OK, well we are frequentl....

Oh I totally get it ....

At some stage, when I ge

It seems with XMR you are striving to build a super-robust anon coin, prioritising quality over time-to-market. Is that fair?

Meanwhile DRK seems to be focused...

you admit xmr team is building rock solid stuff. I am suggesting for you now as drk prise has risen significiantly to cash some (not all) of your drk and diversifying into xmr. After all the crypto is like a raffle and it is good to have some variety in portfolio in case some coin rises significiantly.

[TrueCryptonaire]

I want to say my sincerest congratulations on drk community for orchestrating a massive pump. It was fast. Very good pick, man! However, the profits are not yours unless you do not succeed to sell at right time and buy something undervalued and build it up, too. I am suggesting Monero.

[fluffypony]

"Unfortunately it's hard to quantify without a mathematical expression of the model, especially without a great deal of familiarity with the inner-workings of the system at present"

So that' s a flowery way of saying you have no idea because you don't know how DRK works LOL.

Q: Why don't you write in plain English

A: Monero investors like to be baffled with BS like this before being puckered into the Polo trollbox and subsequent XMR buy

Not at all. Quantifying a threat model requires you have a model in the first place.

I have a reasonable idea of how Darksend works, both from what Kristov Atlas wrote when he was reviewing it and from subsequent replies and discussions. I have also read the whitepaper, although the current implementation is quite different from the whitepaper's. I have looked at the code in brief, but (again) I have neither the time nor the inclination to study and document the code, and from that produce a model that has quantifiable risk.

I'm not sure which words or phrases you're struggling with, but where a word has a specific meaning I do try and expound on it (eg. our discussion of cryptographic negligibleness earlier in this thread). I don't see a need to dumb down what I'm saying, unless you mean to imply that Darkcoin users are so dumb they can't understand what I'm saying...in which case I disagree with you, as thus far you're the only person to have an issue with it.

With regards to your final statement, I can only highlight some of the many instances where I've gone so far as to tell profit-seeking investors NOT to buy Monero: http://log.bitcoin-assets.com/?date=11-12-2014#951020 - it's not an investment vehicle, it's a cryptocurrency. Similarly, David Latapie and myself did a 3 hour, 45 minute, interview with Doged Radio, and even the host noticed that we didn't launch into a recommendation that anyone buy Monero. If you have some time it's worth a listen, even though it takes a little while to get going: https://www.mixcloud.com/dogedradio/monero-coin-interview/

[majamina]

you admit xmr team is building rock solid stuff. I am suggesting for you now as drk prise has risen significiantly to cash some (not all) of your drk and diversifying into xmr. After all the crypto is like a raffle and it is good to have some variety in portfolio in case some coin rises significiantly.

I do have an XMR position, but only like 10% of my DRK holdings so barely a hedge.

What I'm questioning about XMR is time-to-market and the real-world necessity of the ultra-robust tech. If DRK is fit-for-purpose in the majority of real-world use cases and gets over the line first in terms of adoption and scalability, where does that leave XMR?

[Macno]

you admit xmr team is building rock solid stuff. I am suggesting for you now as drk prise has risen significiantly to cash some (not all) of your drk and diversifying into xmr. After all the crypto is like a raffle and it is good to have some variety in portfolio in case some coin rises significiantly.

I do have an XMR position, but only like 10% of my DRK holdings so barely a hedge.

What I'm questioning about XMR is time-to-market and the real-world necessity of the ultra-robust tech. If DRK is fit-for-purpose in the majority of real-world use cases and gets over the line first in terms of adoption and scalability, where does that leave XMR?

For which real world cases is Darksend not secure enough?