Quote from: Conurtrol on August 10, 2014, 01:06:53 AM

Not using cryptonote and not hot air. Read the paper before commenting please.

I read the whitepaper, although I struggled to get through the ridiculous analogies that seem shoe-horned to fit with the "pirate" metaphor instead of being suited to task. Oh, and the lack of references by footnote is extremely frustrating (an appendix of reading material is not a footnote).

He acknowledges that the ring signature implementation in Monero "'is absolutely spectacular and the advances it offers groundbreaking". I do think he misses the point when he claims that "weak correlations are still possible", as ring signatures in Monero are combined with always-on stealth addresses. Thus, practically speaking, his example of 1.23 RingCoins if sent with a mixin of 15 would not actually just have 15 ring signatures. It would be 15 for each output, thus a total group for that transaction of 45 signatures, and unless you can crack the stealth addresses (ie. brute-force a 256-bit hash, which would take more energy than exists in the universe to crack just 1) for at least 42 of the signatures you simply have no way of knowing which of those signatures is real and which are fake. Even if you did know which was real by some miracle, you still only have the stealthed destination and not the actual address. Those outputs will be used in future both in ring signatures and in an actual transaction, but since there is no way of knowing if an output is real or not it will forever be considered unspent (spends at mixin=0 notwithstanding). Therefore, even weak correlations are not possible due to the combination of stealth addresses and ring signatures.

His main criticism of CryptoNote is that the blockchain bloat causes the Monero blockchain to be "an order of magnitude" larger than Bitcoin's. The first problem with the criticism is that it he uses completely incorrect numbers. He uses the actual Bitcoin blockchain data, but then for Monero he uses it's current on-disk size. Currently, the Monero blockchain is stored in an inefficient, duplicated, flat format. It is vaguely analogous to storing your holiday snaps in BMP instead of high quality JPG - the BMPs will take up a significantly larger amount of storage space for no appreciable advantage. We are moving Monero's blockchain to an embedded database precisely to solve this. If you use the actual blockchain data then you will find that, on average, excluding the dust transactions that came from pools earlier in Monero's history, the blockchain is 5.5x linearly larger than Bitcoin's (10x larger, or a single order of magnitude, only occurs if you include the early dust transactions). That means that in 3-5 years, ostensibly, if Monero has the same reach as Bitcoin and has achieved the same level of traction we should see the blockchain at around 110gb, hardly a figure to write home about when you consider that the majority of users will use web wallets and thin clients, and those that choose to run full nodes will most assuredly have 110gb of free space.

Beyond that, the lack of commonly accepted cryptographic terms makes it exceedingly difficult to understand what he's trying to achieve. There is no problem with making a term up, as long as it is thoroughly explained before use in the rest of the paper, but using the term "hyperspace" in a technical paper that has nothing to do with space travel just makes it illegible. Finally, anything that relies on "privacy servers" operated by ~~amateurs~~ volunteers will end up relying on a ridiculously small group of servers to not be compromised. That these servers are meant to be run by "anyone" on a VPS shows a distinct lack of understanding of the threat model. If Tor's exit nodes can be similarly attacked to find the location of SR's server (which they did, and then they compelled data centres in Latvia, Sweden, and Romania to hand over a copy of the data on the server - and since they had physical access to the server on-disk encryption would be irrelevant since they can just access data that is unencrypted in-memory) then you can bet that anything reliant on a group of servers for privacy is doomed to failure. Relying on a group of servers for convenience (eg. Electrum) is a vastly different exercise, this should never be relied upon for privacy.