Topic: XMR vs DRK - page 58. (Read 69755 times)

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


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?


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.



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

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.

Morning:)


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


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


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.


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.

Maybe some people were too lazy to answer or simply do not get it. Emission is not just important regarding fairness, but has serious implications regarding economic mechanisms: the problem with instamines or also proof of stake is that certain qualities of money like commodities do not work: economic network effects as well as power law do not work properly when the initial distribution is set in stone, or quasi set in stone.
with the inflation hefty emission of monero you at least open the possibility for these mechanism - you have to make sure that your cryptocurrency project does not become a club good

Interesting comments and very honest, thanks...

I spoke to that on Reddit yesterday, so I'll just cut-and-paste -

ZeroCash is amazing, cutting-edge research. In the far future I fully expect it will make Monero and Bitcoin obsolete.

However, it is somewhat unworkable right now. Firstly, it has a trusted accumulator problem that remains unsolved at this stage (although they posit solving this through an RSA UFO). Even if that is solved there is still the very real danger of it being impossible to see exploits in an absolutely opaque blockchain with relatively new and untested cryptography (ie. an exploit that lets an attacker create, say, 2 000 000 ZeroCash in a single day will go unnoticed). Finally, even with their newer ZKP schemes there is still a significant size impact for each transaction, and absolutely no way you'd be able to run SPV-style wallets or perform blockchain pruning.

Once the cryptography has been more thoroughly tested, corner cases have been solved, and technology is at a point where the size impact is negligible, then I would imagine some future iteration of ZeroCash will become the dominant form for cryptocurrency payments.

It absolutely is - if you control over 51% of the network you can solve a block twice that spends outputs twice (ie. in the normal course, whichever block is received last would fail key image verification) and send one block to one half of the network, the other block to the other half. Practically speaking you wouldn't be able to keep this up (unless you owned 100% of the mining power), and this would be resolved network-wide within a handful of blocks when the balance of the mining network solves a longer chain than you can maintain. So you would have 2, maybe 4 blocks at most, to abuse your double-spend power.

Exchanges won't let you trade deposited coins with only 4 confirms, and I can't foresee merchants packing and shipping an order you've purchased in the space of <5 minutes, so the only real way you can exploit it is to use the double-spend to purchase multiple digital goods simultaneously, and download them before the reorg makes one of your transactions invalid.

Do you run Bitcoin Core?

Or do you run Electrum? Blockchain.info? Armory? BreadWallet? MultiBit? GreenAddress? Hive? Mycelium? Circle? Coinkite? Coinapult? Xapo? BitGo? CoinBase? AirBitz?

Nearly nobody runs the Bitcoin Core GUI. They use third-party wallets.

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.

I agree that XMR is theoretically a better anon implementation, but I prefer DRK because it seems to be working in the real world and has a better chance of  mass-adoption due to BTC compatibility.

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


I think DRK is shooting for real-world utility and innovative features rather than being an investment vehicle.

Fair enough, you just don't give much impression of 'business smarts', which is perhaps intentional.

I'm not sure you're helping your project much with some of your conduct on these forums.

i2p is designed to be low-latency, but it would be extremely poor performance for miners.

A bit of both:)

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.

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'm actually quite impressed with the somewhat civilized discussion in the last page or two.

My on-topic response: this discussion illustrates that DRK has a number of uncertainties in its design that aren't present in Monero. This is a large part of why I prefer XMR.

I also agree with previous posters that DRK and XMR seem to have different goals, as DRK appears to be transforming more into an investment vehicle within our crypto space. XMR's direction, on the other hand, is admittedly less serving to its traders, but that sacrifice comes with the opportunity for a more robust and decentralized long-term trading solution.

Maybe. Though as I said it would be a delicate course to navigate.
If you did it now, overnight, it would I think, whilst if you wait then it could stymie the whole process. The transition would involve some timing to say the least IMHO

Heh, exactly.

In any legal case there are two parties and two lawyers; three of them always win.

Smooth's lawyer would say there was no threat and your's would say there was I imagine, but that's their job.

This is also possible. Quoting myself above and leaving out the incendiary P-word


Now we see another answer to the question of how honest masternodes might not be profitable (see bold in first quote above).

I'm pretty sure there are other possible outcomes, a list that does not include one where people successfully get a 10% risk free return.

If you adjust the colleteral from 1000 to 100 DASH per MN, in my oppinion that wouldn't lead to "freed" coins, they will just x10 there masternodes, and nothing changes for them (we have 10 times more masternodes but everyone gets paid a tenth of it also, so if you just use the 1000 drk to open 10 MN nothing realy changes.)