Scaling "10 times better" is frankly pretty ridiculous.
It may be, on the lower side. It could be worse than 10x. What's your blockchain size right now? |
|
|
|
Monero is not anonymous when your metadata can be correlated. One example of metadata which unmasks your anonymity is your IP address. And no, Tor and I2P mixnets do not hide your IP address from the government, in fact they are thought to be Sybil attacked honeypots that not only tell the government your IP address but also alert the NSA et al that you should come under extra scrutiny.
... Additionally I have been making the point since the BCX incident that ring signatures can theoretically be unmasked by combinatorial analysis of the block chain. In the recent debate I had with Monero's cryptographer Shen-noether at Reddit about his white papers, I pointed out that his proposed solution to combinatorial unmasking was flawed. He and smooth did the usual ad hominem attack on my person, and then I rebutted them with logical facts and they were forced to finally put their tail between their legs.
Bullshit. So much bullshit in these discussions of cryptocurrency technology. Especially coming from all the Monero pumpers who haven't done their homework, because they are retarded, closed-minded, and boastfully so.
... Thus I have explained there is no Nash equilibrium in Monero's penalty feature (unlike for Satoshi's longest chain rule where there is indeed a Nash equilibrium because if miners don't converge on the longest chain then all their chains are invalid/orphans and worthless without consensus).
... Monero Review: Broken anonymity [ ✓] Broken scaling [ ✓] Broken game theory / Broken Nash Equilibrium [ ✓] Delusional, retarded and pumper-minded community [ ✓] Cryptographers with broken cryptographic ideas [ ✓] Broken de-centralization that will tend to centralization [ ✓] Congratulations. You passed your "broken crypto" review with flying colors. Monero #REKT  |
|
|
|
Now that you quoted the entire post, does it change the fact that he says BITCOIN IS A BROKEN DESIGN?
FTFY Now apologize for misreading and misquoting what was pretty obvious for anyone with high school reading skills. Yeah because if he considers bitcoin as "broken" due to its scaling which is 10 times better than monero, then monero ...isn't broken  Dat logic. And he also asserted time and time again (even two posts above) that the anonymity is broken against the state due to metadata correlation. Against the NSA yes I stand by the assertion that IP address correlation unmasks, overlapping rings unmask, etc. It all adds up if you are trying to hide from governments, then I don't trust Monero or any anonymous coin.
#badycrypto XMR People who love to be free from government oppression and used XMR = #REKT |
|
|
|
Now that you quoted the entire post, does it change the fact that he says MONERO IS A BROKEN DESIGN?
Not quite. I said Bitcoin is broken and both can't scale to million tx/s. I thought you were referring specifically to the bloat issue that affects monero's scaling way more than bitcoin since bitcoin doesn't suffer from the same problem. Regarding Monero's anonymity, do you stand by the statement you've expressed below in the past (regarding broken anonymity due to metadata correlation)? Cryptonote was created by anonymous people. Even Monero's cryptographer is anonymous. Who created this anonymity that is easily broken by meta-data. I don't know if that is circumspect or just the way the world turns.
As for scaling... well scaling is a complex equation involving time, technology available, proper use of the available technology and the ratio of centralization/decentralization that is "acceptable" at any given moment. We could say that everything can scale (if...) or everything can't scale (if....), or everything can scale in (x time), or under (z circumstances).... etc etc. The good thing with scaling is that unlike hardware and software progress, human tx needs are finite and thus the two trajectories (of increased tech progress vs finite human tx needs) will meet. If we currently, as a species, say, need 100k tx per second, there is a point where this will be feasible. And as time progresses we will be able to handle a million, ten millions, etc etc. But tx needs will still remain in a pattern of relative stability - slow growth. |
|
|
|
Ok found the problem... The profiler did it  I run the program through an indirect call: valgrind --tool=callgrind ./cpuminer -a x11 --benchmark and then exported the profile data to KCachegrind to get the graph. I don't know how running it indirectly can do that, except if it emulates another cpuid. Normal run is ok, it detects Q8200. |
|
|
|
Let me get this straight. You compiled with -march=native on a core2 that thinks it's a i5-670.
Yep... The compile succeeded and the miner ran ok. That's pretty special.
.16 was broken due to some errors (algogate? can't remember) which I removed manually from all the sources, but .18 runs ok. The CPU model and AES support comes directly from CPUID and has been reliable until now. Even the AMD guys haven't reported CPUID problems. Can you confirm CPUID is correct: cat /proc/cpuinfo |grep model cat /proc/cpuinfo |grep model model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz stepping : 7 microcode : 0x70a cpu MHz : 1754.042 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm bugs : bogomips : 3508.08 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: It would be interesting to see what the compiler thought: gcc -march=native -Q --help=target | fgrep march gcc -march=native -Q --help=target | fgrep march = -march= core2 Regarding echo512, yes you will get the slow version. Unfortunately I'm unaware of a SSE2 optimized
version and the AES version is already used by cpuminer-opt on capable CPUs.
In case when you need to see performances, or find sources: https://bench.cr.yp.to/primitives-sha3.html+ sources of every possible variant here: https://github.com/floodyberry/supercop/tree/master/crypto_hashI have yet to study your data in any detail but the following may put performance into perspective.
Echo512 and groestl have AES optimizations for most algos.
Cryptonight and hodl have their own unique AES optimizations.
The rest of the x11 chain, including groestl but excluding echo, have SSE2 optimized versions.
The algos in the longer X chains, as well as non-aes echo, are filled with slow SPH versions.
Yeah, lacking AES (and AVX) hurts a lot. |
|
|
|
|
Now that you quoted the entire post, does it change the fact that he says MONERO IS A BROKEN DESIGN?
|
|
|
|
Why would I want respect from the community of a coin with a broken design
....
Sorry when I build up Monero because I state facts that are true about it
Monero #REKT XMR #badcrypto #broken #veryREKT |
|
|
|
3.1.18 is kind'a buggy in cpu detection. In a Q8200 it says: Checking CPU capatibility... Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz CPU arch supports AES_NI...YES. SW built for AES_NI........NO. Algo supports AES_NI.......YES. CPU and algo support AES_NI, but SW build does not. Rebuild with "-march=native" for better performance. Starting mining without AES_NI optimizations... ...so naturally it thinks I have AES, even though the build is not for AES (-march=native / no AES in Intel quad core q8200). Anyway I did a profile run in x11 to check the slowdowns:  A couple of them, with echo512 being the biggest culprit, dominate the process in terms of time wasted. It seems there is a very optimized AES version for it: https://bench.cr.yp.to/impl-hash/echo512.html https://bench.cr.yp.to/impl-hash/echo512.htmlhttps://github.com/floodyberry/supercop/tree/master/crypto_hash/echo512/aes/aes64 |
|
|
|
Mixin 0 wasn't too scientific though, was it? 1. Who developed Cryptonote with unrestricted mix 0? 2. Who analyzed the issue and published the analysis of the problem (also with mix 1)? 3. Who developed and published a proposed fix prior to implementing and deploying it? 4. Who implemented and deployed a fix? There's your answer. My answers: 1. Cryptonote/Bytecoin 2. Monero 3. Monero 4. Monero, Boolberry (partially), and AEON Wait, you cloned Bytecoin, with all its flaws, without any due diligence, consequently had to face the problems of the cloning and start patching these problems as you went ahead, and that's a "feature" instead of "bad crypto"? |
|
|
|
Mixin 0 wasn't too scientific though, was it? |
|
|
|
|
Unlike people wasting their time on forums mudslinging, Evan uses his time to code the next features of DASH.
If he sits here debating all day then we'd hear: "doesn't he have anything better to do, like code?"
If he codes and doesn't debate endlessly the (self-defeating - from a game theory perspective) scenario of ...jamming an instantx transaction after acquiring a large number of masternodes => "he run away".
You can spin it any way you want really. It doesn't matter.
If you think mudslinging is a good tactic for promoting Monero, then be my guest. You'll be actively contributing to defining what bad crypto is: Crypto that wants to rise not by virtue of its better characteristics, but by throwing mud at their opponents.
This is now, what? The 10th thread or so of "Monerotards" attacking DASH? Get a life. Or a better coin. Then the market will appreciate it, if it becomes such. You won't get any value from the market without providing value to the coin. Even if DASH never existed, Monero would still be stuck. Contemplate that for a change.
|
|
|
|
|
So the errors or "errors" that TPTB indicate only ...matter depending the various time-space coordinates, and his likes, or dislikes, at any given point within that 4-dimensional array.
Sounds legit.
|
|
|
|
|
I've seen the discussion between Evan and TPTB_ which went something like "oh this could be lowered to 0.% of transactions even if the attacker held XXX masternodes", and then after some back and forth it degraded to "Oh the masternodes are illegal in the usa, the financial authorities this, and that" etc etc.
|
|
|
|
We are talking about ...jamming a transaction, after spending a shitload of money. And that's to jam 0.x% of instantx transactions that at worst will be confirmed 150seconds later per the casual block confirmation... that doesn't make any sense.
If it's a valid game theory scenario, and makes sense for the attacker, we'll see it happen. I don't see it happening.
I was talking about darksend spying, which you can't see happening, but is all but inevitable (and the only way out there is essentially an accidental miracle) given the incentives. Well, the more you mix, the lower the probabilities of bad actors affecting you. That's pretty much the same across the board, in all mixing scenarios, including Cryptonote mixin settings. I've already explained the critical difference between the two. One has an ongoing cost to bad actors, the other does not. You are leaving aside multiple costs for the bad actor. Devaluation for the coin by harming it, inflation costs for the holder (which are only partially mitigated by masternode rewards, yet maxcoins is >3x of current supply), mass acquiring costs that lead the price upwards (it's not the same, in terms of market-prices, buying 100 dash and 400.000 dash to buy 400MNs), etc. The lack of any quantifiable cost means is that attacks are plausibly unbounded. More mixing will not save you.
If you involve 1 MN for mixing, and 10% of them are crooked, you have 10% of being deanonymized by hitting the crooked MN. If you go in 2 rounds, with 2 different MNs, your chances go to 10% of 10%. In the third round you have 10% of 10% of 10% chance. ...etc etc. Multiple round mixing was designed specifically to address the bad actor scenario. Was there any peer review of the InstantX white paper whatsoever? Was TPTB the first one to catch the error 1+ years later?
The "error" involves broken game theory for the attack vector. If we are just trying to find theoretical "dangers" but ignoring the underlying game theory, then Bitcoin and all crypto are already dead. They aren't because they are based on game theory, costs and rewards for the attacker etc. |
|
|
|
We are talking about ...jamming a transaction, after spending a shitload of money. And that's to jam 0.x% of instantx transactions that at worst will be confirmed 150seconds later per the casual block confirmation... that doesn't make any sense.
If it's a valid game theory scenario, and makes sense for the attacker, we'll see it happen. I don't see it happening.
I was talking about darksend spying, which you can't see happening, but is all but inevitable (and the only way out there is essentially an accidental miracle) given the incentives. Well, the more you mix, the lower the probabilities of bad actors affecting you. That's pretty much the same across the board, in all mixing scenarios, including Cryptonote mixin settings. The OP however refers to the "highschool maths" from a TPTB post about InstantX. |
|
|
|
|
We are talking about ...jamming a transaction, after spending a shitload of money. And that's to jam 0.x% of instantx transactions that at worst will be confirmed 150seconds later per the casual block confirmation... that doesn't make any sense.
If it's a valid game theory scenario, and makes sense for the attacker, we'll see it happen. I don't see it happening.
|
|
|
|
"blockchain-contract"  |
|
|
|
|
These types of attacks where someone comes and buys all the coins are too theoretical for my preference.
|
|
|
|
|
Show Posts
